Postmortem: Embrace

The last course of the semester for first-year students at Futuregames in Stockholm Sweden was a seven week game project. In just seven weeks the students were to develop a game from start to finish with only two restrictions. One being that they had to create the game using the Unity3D game engine, and the second being that they had to adopt the agile development method called Scrum. This postmortem regards the game Embrace and development team that made it. Starting with a brief description of the game itself, we brings the ups and downs of the end result to light with a final conclusion at the end. We would like to warn about major spoilers in this document!

The Game
Four 3D artists and three game designers were merged together by the school to form the group that came to create Embrace. Very early on an idea spawned to make an interactive story, with heavy emphasis on ambiance, immersion and a kind of meditative, philosophical setting. Embrace is a third person game about a young character, who lives in a very small village in the middle of a huge forest. It starts off with the character waking up in a clearing, finding their spear and seeing the village from a distance. The game quickly comes to its state of letting the player tell his or her own story, however it is in fact a fairly linear game with a beginning and an end. How the player makes it to the end is different, and even the ending can differ from one experience to another. The game is similar to a sandbox game in the sense that it provides the player with an open world, and a lot of freedom with different possibilities of action. By doing any of these actions the player will progress. The different actions that exist are however unknown to the player, and he or she will never be given a certain quest to complete, or a fixed thing to do. Embrace puts the story entirely in the hands of the player, and it expects the player to create his or her own story around this character, the village and the forest with its wild boars, berries and mushrooms, and apply their own meaning to it all. The player might travel into the forest to kill a boar, pick some berries or stay inside the village and hug or kick its inhabitants. Whatever the player does, the game will progress. After a while the very forest will change, making it a more linear experience with specific goals we expect the player to reach. A pillar of light will appear in the forest, guiding the player to a mysterious empty cave. Upon exiting this cave, the player will find the camp-fire smoke theyre used to having for navigation changed, now rendered with a tone of red. Hoping that this catches the curiosity of the player, upon reaching the small village, they will find it deserted and slightly demolished, with purple goo on the ground. The light pillar which lead the player to the cave will now have changed to a dark purple, leading the player to the conclusion that they need to head back to see what has changed. In this cave the player will find the villagers huddled around a small fire, with a purple creature watching over them. Treading forth, the purple creature will get startled and eventually begin attacking the player. This is where all the features in the game are tied together, into a rather traditional boss-fight, with multiple possible endings. Embrace is a game that has no rights nor wrongs, and therefore it isnt considered better to kill the creature than to be killed by it. The player will be left with a feeling, and that is exactly what we as a development team wanted to reach.

1. What went right

1.1 Quick start and frequent iterations In the first two days the whole concept was outlined. The basic gameplay ideas were put to paper and we all had quite a good idea of the entire game. This was great for multiple reasons. We could all unite in an art style pretty quickly, and by doing so begin to mock up quick concept-art for props and characters. We all agreed that in this short amount of time, we couldnt waste too much time on nailing the perfect concept for every single detail. It was better to just start creating 3D-models in Maya as fast as possible, so that the animator could start rigging, and the game designers could set the world scale and other necessities into place. Working using Scrum as our development method the focus lies in iterations, which means that youre supposed to lay down these quick mock-ups at an early stage, and work your way towards better versions from there. The idea is to quickly catch if something seems to be going in the wrong direction and rapidly fix it. Having such a quick start this came easy and almost naturally even though only one member of the group had worked with the Scrum method before.

1.2 The courage to follow our vision Embrace is quite an experimental game. Some have said that it is not even a game. Hearing this we dont exactly get defensive, but rather nod and smile. While it contains many typically gamey elements to guide the player in the world we created, we consider it more of an interactive story. Weve had multiple inputs from end users and other game developers saying that we should implement a HUD, a life-bar and an inventory for the items the character might pick up. We never implemented any of this, Embrace intentionally lacks all of them. When creating Embrace we wanted the player to feel like he or she actually was this little character, and not so much playing a game about a child in a forest. This might seem a little bit far fetched, but in order to create the mentioned feeling within the player we didnt want to implement any standardized elements such as achievements, collectibles, a HUD or life-bar as these could easily distract from the idea of this being the players story. The player is supposed to create their own sense of achievement depending on what they want to do. What you see in the game is what you get, so to speak.

1.3 Focused development and dedication to Scrum When creating Embrace we as a team were united in our vision of the end result. The communication within the team was excellent, which we have Scrum to thank for to an extent. Every morning at nine we had a meeting in which we individually explained to the group what our goals for the day were, if we had any obstacles we needed help overcoming and what we had done the day before. Since we work in the same premises just desks apart, wed talk throughout the day to keep track of what everyone was doing, and in which direction the game was heading. Working using Scrum requires you as a team to have clear goals each week called sprint goals. Our team was outstanding in keeping our goals reachable. When saying this were not saying that we were working insanely fast and productive - were rather saying that we were great at killing our darlings and decimating the workload to a graspable one.

1.4 Sharing the workload and working distributed

This fourth and final point in this chapter is in regard to the one above. Working closely in the same premises gave us the opportunity to have great insight in each team-members work. This brought a sense of collaborative work to our project. One would start creating a 3D-model, later a second would pick it up and put the texture on, while a third rigged and animated it. This work-flow worked very well for us as wed produce content very fast, and we could start new tasks before e.g. one character was fully complete. The second part of this point regards our ability to work distributed. Formerly weve said that we worked in the same premises, and while this is true, the work didn't end at the end of the schooldays. We who had the ability to work from home did so during the evenings or weekends when the workload was heavy, or sometimes because were just that passionate about making games. It worked flawlessly to communicate using Skype(www.skype.com) and we used Dropbox(www.dropbox.com) to share the project files. We rarely had confusion regarding which files were the last ones to have been updated, or which build of the game that was the latest one.

2. What went wrong

2.1 Guidance When creating this game we all wanted one thing - the player should be able to tell his or her own story about this little character in the enormous forest, without interruption from the game itself. This was much easier said than done. How would we communicate feelings from the villagers when the character hugs or kicks them so that the player gets the feedback he or she wants in her own saga? All the actions made by the player drives the story forward towards the end of the game, so a kick had to be as good as a hug, and vice versa. This was a problem, feedback had to be given to the player to make the game interesting, and we couldnt make it so that kicking is less good than hugging as we mentioned above. The player might want to tell a story about a boy who kicks everyone, and everyone perhaps likes it? We never actually figured out a perfect way to create this, so upon kicking a villager now, it will just look sad for a while, and then return to its previous state. Therefor there is no long term aggression or love towards a player like there are in other role playing games, so the end user might feel like it doesnt really matter what he or she does, the game will just progress in the same manner anyway. This overall lead to many players not feeling like theres any point to doing anything, and ultimately not even reaching the end scene in the game.

2.2 Vague affordances and lack of consistency Embrace is similar to a sandbox game since the player can interact with objects in the forest and people in the village and so forth. However, some of the objects that might seem to be interactive are not, and this is confusing. The flowers outside the village for example cant be picked even though berries in the forest can. If the player has for example picked a mushroom for instance and decides to throw it away, it cant be picked up again, even though the spear can be thrown and picked up from the ground again. Players didnt always understand what they were doing, such as picking up berries was sometimes confused as to hugging the bush much like you could hug trees. Few also understood that berries and mushrooms could be given to the villagers. These are issues we intended to look into, and are in some cases actually not that hard to fix, but seven weeks passed way to quickly. This shouldnt be taken as an excuse, but as an explanation.

The lesson to be learned here is that a feature, how good it may be, must make sense in all situations. Especially when creating a simulation game / interactive story.

2.3 Lack of gameplay elements creating confusion Our vision was to make a game - without making a game. This backfired to some extent as some of the end users didnt understand why there was no HUD or an inventory. Our motive for not having these elements are mentioned above in point 1.2 but we failed to explain to the player that these features actually arent needed. Weve had end users requesting a life bar, which we never even considered since you die/faint from one blow if hit by a wild boar or the cave creature. It has been requested anyways, which really is something to investigate. The problem is not the lacking life bar, the problem is that we as developers failed to communicate that it isnt needed. An inventory wasnt implemented with the same motives as the life bar, we simply didnt see the reason as all items you are able to pick up work the same way. In hindsight we should have implemented something along those lines. It might not be good letting the player pick things up but not letting the player see what their character is carrying before it gets thrown out or given to villagers. This becomes even more important in combination with the characters inability to pick things back which have been thrown away as mentioned in 2.2.

3. Conclusion
We shouldt have made this game - but we are glad we did! Why? Well, setting out to create a sandbox game in just seven weeks is in retrospect quite insane. We didnt fail however, we managed to pull it off, with the end result being quite similar to our initial idea. We are extremely proud that we all stuck it out to the end seeing our vision through.

The Embrace team are:

3D, art and animation: Jesper Jder, Malin Lindgren, Patrik Robertsson, Carlos Lundhall, Game Design, sounds and coding: Jesper Engstrm, Marko Permanto, Andreas Hll-Penninger