The game Year Walk (Simogo) is a point and touch adventure game initially published for iOS devices on February 21^st, 2013. It would then be published through Steam on March of the same year and Nintendo’s WiiU in September. The game put the player in the shoes of Daniel Svensson who, after finding out his lover was to marry a suitor picked by her parents, decides to go about the process of arsgang, otherwise known as “year walking,” to see what the future holds in store for them. On his journey, he meets, and is tested by, several creatures from Swedish folklore that lead him to a devastating truth. The story for Year Walk was originally supposed to be a short film written by Simon Flesser, but after deciding that the act of year walking was a perfect fit for video games, he partnered up with Simogo games to develop the haunting adventure game. For the purposes of assessment, I will do my own take on developing year walk and then going through the steps to publish the game on the PlayStation store.

Prototype

For a game like Year Walk, which takes on the form of interactive picture for the most part, storyboarding is essential to the process. Making sure that each image is set up so that the puzzles work will allow for coding and interaction to go well when moving onto the actual development process.

 

While the images in the game seem static, a simple swipe or touch of the screen will cause something to happen on the screen. Swiping or touching the faint arrows on screen would navigate to new areas, while touching something will either activate a puzzle or simply give a reaction to the player. This game could simply use paper prototypes in order to give a breakdown of screens. I imagine that setting up a wall with “rooms” set up in the directions they are oriented with other pieces of paper depicting how puzzles will act. Add to that an almost cliché amount of string and pins showing what keys go to what areas and you’ll have the basic idea of how Year Walk would look for the player. Seeing as this is a paper prototype, testing and dissemination would occur as more of a group brainstorm rather than a testing. People in every role of the development process can voice concerns about scope and other hang-ups.

 

Game Mechanics

To make Year Walk live up to its full potential in my hands, I’m going to use Unity3d in order to make sure I can handle the mechanics; this proves fruitful in that Simogo chose to use the same engine when making the original game. While an engine like Unreal could probably take the game’s graphics and improve upon them, and Construct 2 could help me make the game faster, I feel that choosing the indie company engine of choice would ensure that I could handle a project as beautiful as this. Seeing as the game was originally able to be played on a handheld device, the technologies needed for its mechanics are simplistic and can be played and developed on anything if the graphics driver is on par with or greater than an Apple A5 chip.

When it comes to input devices, for our purposes the PlayStation 3 & 4 controllers are what need to be tested. Since the game was originally touch-based and eventually evolved to use point and click when it came to Steam, we must ensure that there is no lag between the input of the controller and a reticle on screen. The PC release of the game had a small circle reticle with the W/A/S/D and directional keys used to navigate left and right and the different fields of depth. While the joysticks could be used to do the same navigation, the concern of gameplay becoming jerky is present. One option is to have the two sticks handle different types of direction (The left stick would handle left and right while the right stick handle the depth of field), but this again causes concern when needing to use the reticle to interact with objects. The other would to have the player only use the D-pad for navigation, while using one of the joysticks to manipulate the reticle. This would be something that would be discerned after playtesting, more on that below. Finally, the X button on the PlayStation controller would be used to interacted with objects indicated by the reticle.

 

Game Dynamics: Whatever that means.

The game mechanics of pointing, clicking, and solving puzzles all work together to allow the player to progress through the story. Seeing as this game’s focus is on the story that is unfurled by the music and art, there aren’t many systems that make up a grand scheme for this game. The player gets to explore a winter nightscape, and through that they can learn the story of Peter’s year walk. The only thing of note that could possibly considered a game dynamic is the glossary of folklore that is part of the game. During exploration, the player can often see marks etched into the trees and buildings. These marking can be deciphered via an in-game notebook that will tell the player about different characters from the folklore. This foreshadows what the player will later face in an area and could give some idea of how the puzzles in that area. This journal also becomes integral to getting the good ending of the game, so making sure that the player is encouraged to explore the journal and the lore needs to be done from the outset.

Content and Assets

While the game in many ways is simplistic, there is a lot of creative content needed to make it the beautiful experience that it is. There is already a strong base when it comes to writing, Flesser came to Simogo with a strong story and specific characters that they then adapted to make the game. Since we went through storyboarding the game during the prototype phase of the game while discussing it with all team members, the art team should have a good idea of how the game should look. The art is going to be a particularly unique experience in that there are many layers to the game; since there is a depth of field that can send the player forward and backward in the scene. There must be quite a bit of environment art that can still look good when obstructed. There is also the obvious need for character art.

 

 

 

The art is very stylized; while it looks like papercraft it also has a glow and translucency that creates the haunting atmosphere. The characters must be able to move slightly (like paper puppets) so sprite sheets will be used for these minor undulations.

The music and Foley is so essential to creating the mood for this game. Simogo was very particular in using electro-folk music to bring out the atmosphere, and it is so subtly put in the background to make it all feel like a distant dream. There are also quite a few moments and puzzles in the game that use the chimes and tunes of old music boxes that I feel are essential to the game. Many of the puzzles in the game revolve around children and young women (for example the above picture shows the brook horse that lures women and children to the water to drown along with millings, or the ghosts of children) so these music box songs only add to the story. Other than the distant music, music box, and audio cues made by certain puzzles, silence is another essential piece of audio. The player must walk through a snowy landscape in order to complete the game, so at times the silence must be deafening to indicate that the player is truly alone. Save for the cold winds that can blow and the crunch of snow under foot, the music can sound far off and muted, making the player strain to hear.

As for how these assets are integrated, that is quite simple. Most of the game art and music will be activated upon enter or with a trigger. Whenever a player moves step sound effects will activate and play. When they interact with something it will trigger the appropriate noises. These sounds and aren’t don’t need any type of manager to store them as they will be stored in the scenes themselves. The game will also use particle effects to simulate snow with an almost bohkeh effect. Messing with the alpha will also help with some of the characters meant to look like ghosts.

 

Testing and Data Collection

I’m lucky in that unity has enhanced their engine a great deal since Simogo made their game. Now that unity analytics are available for free, I will easily be able to check for specific events that happen in the game. If I set up several debug logs, and add specific scripting to track the event I will be able to see if there are any things that need to immediately be debugged. This is an example of how the scripting would work (from the unity documentation site):

using System;

using System.Collections.Generic;

using UnityEngine;

using UnityEngine.Analytics;

public class GameLoginMonoBehaviour : MonoBehaviour

{

public void OnGameOver()

{

int totalPotions = 5;

int totalCoins = 100;

Analytics.CustomEvent(“gameOver”, new Dictionary<string, object>

{

{ “potions”, totalPotions },

{ “coins”, totalCoins }

});

}

}

Analytics can handle several things, in that depending on how you script your 1000 events and set up funnels, you can easily track retention rate and the time it took to solve certain aspects of the game, as well as whether the player is utilizing all the tools in the game. This gives me the possibility of getting beta testers from around the globe to play the game knowing I can get quality testing without having to meet in person. I would also have the option of private tester forums and direct lines of contact so that if their any odd game breaks that I didn’t think to monitor for, I could still gather that information.

Distribution

To publish on PlayStation 4, you must be first approved for their publishing program. This involves proving that you are a game company working in North America, applying/agreeing to become a PlayStation partner, and then letting this information be known to Unity. After that, you will receive a unity plug in that allows you to create a build specifically for the PlayStation platform. This, by far, is the easiest part of the game development process (if you don’t count the crippling fear of approval).