Get Well Soon! – Post-mortem

Posted by (twitter: @gsm_productions)
August 31st, 2013 6:40 am

Hey there, GSM Productions here! Figured we might do a little (?) post-mortem about our game, Get Well Soon!, which you can play and rate here (as the ‘our’ makes apparent, it is a jam entry). We will start by quickly describing our idea, then we will do the regular “what went right/wrong” thingy.

The idea

With the theme announced, we started bouncing ideas around. One thing that was quickly apparent from the discussion was that we wanted to make a horror/spooky game. We thought about various way to incorporate the theme into our game, and tried to come up with something less common than making your flashlight after 10 seconds, or making a game you had to complete in 10 seconds or something. Not that we thought those were bad ideas, but in the past we have struggled to come up with somewhat innovative ideas, and we wanted to change that.

When someone in the team said : “Hey, maybe we can have the player move for 10 seconds, and then the monster for 10 seconds”, we knew this was it. We were going to make a turn-based survival-horror, without combat. There were still much to be figured out, but the core concept we wanted to put forward was there.

If you want to see the game in action before reading the proper post-mortem, one of our team members recorded a video commentary of the whole thing, embedded below!

The execution

What went right

  • Unity3D – For the first time, we decided to use Unity3D. And what a good decision that was. I do not think I have to explain to most of you why Unity was a good fit, but let us simply say that it was a real game changer for us, even if we were not too familiar with it. Before, we were using various Python libraries to code our games, and besides packaging and distribution which is a breeze in Unity, we could make use of the powerful capabilities of the engine without having to reinvent the wheel at every turn. This resulted in a massive boost of productivity, and while our devs missed coding in Python, it was worth it.
  • Mood – The final product we submitted nails, in our opinion, the mood we were going for. Everything works as intended to create the creepy mood the story requires. We will go in more details in the following points, but this needed to go near the top of our “went right” list since this is what we were mainly going for, and were so happy with at the end.
  • Audio – The audio work we put into the game is one of the thing that makes it stand out. We managed to include voice acting for the introduction sequence and the ending, and had a couple of ambience tracks to play during the game. We had more content recorded and planned, but you know how game jams go… More on that below. In any case, the time spent on making the audio sound good paid off tremendously, especially for this type of short horror game based on its story.
  • Coding – Even though we had not much experience in both C# and Unity3D, the coding part went very well (but for a big exception detailed below) went very well. The very way Unity is structured helps you make cleaner, more compartalised code. Which led to much less debugging that usual. It was a relief, and helped us push a lot of content into the game with little fuss.
  • Getting everything in the game – Well, kinda. The core experience planned on Saturday morning definitely is in the game. The environment is almost as big as we envisioned, we got a good intro (plus several lines of dialogues post-intro), an ending and the behaviour of our monsters is even a bit more complex than simply following the player around. They roam the level until they see the player, then if they lose sight of said player, they try to investigate the vicinity of the last point they saw him. The environment is full of many objects and details, and we even managed to add an inventory with descriptions and everything. So not only is the game finished from a gameplay standpoint, it is also the fullest game we ever made, period.
  • Executing a vision – Kinda like what we said above, but really, the fact that we had an initial vision, and that we could execute it without really making any compromise on that initial vision feels significant. Either we are getting better at scoping, or we are getting more efficient.

What went wrong

  • Too much content – Simply put, we produced too much content : too many lines of dialogue, too many models… Many of those meant an increased time for something else too, like laying out the levels or putting special triggers in place or something else. While the scope of the game was right, we did too much without knowing yet if we could use everything, and without enough testing to see if everything was working as intended.
  • Git – While we were almost all familiar with Git, its combination with Unity was not as smooth as we had hoped. Even with the new functionality added to Unity free, we still had many, many conflicts and unwanted rollbacks, so much so that one of the devs managed to lose almost all the work he did on Saturday, putting him in a bad mood for quite a while. This is really the main point we need to improve for next time. Without all the fuss created by having to solve conflicts and keep everyone in sync, we could have given more time to…
  • Polish and testing – While we think the game has good production values, it is still very rough along the edges. It really came together quite late, so there are objects without collision geometry, some textures that did not appear, a lack of explanations of the main mechanic, no way to skip the intro cutscene, a bug in the main menu, a game over screen that is way too long… All kinds of things that detract from the experience and that could have been solved without next to no effort if we had juste a bit more time. The game is also pretty random, and the balance would have greatly benefited from even a little bit of testing and tweaking. But again, time was short, and we only had the complete game before us right when exporting it for submission. That ties with too much content, but we needed to set aside some time for testing, which we could not. Again something we should be wary of.


All in all, the game far exceeded our hopes by matching the idea we had of it. Usually, we end the Ludum Dare with that strange sentiment that yes, it is awesome that you made a game, but how great would it have been to add this or that… Here, we are fully satisfied with the result, and the comments we are currently getting (thanks for playing everyone!) seem to confirm that. And this feeling, no matter the final placement of our little game, is something priceless. We feel proud of having played to our strengths and to have come out of top, for the first time really. As a team, we think it shows that we are maturing, and starting to know how to work together better. Hopefully to your enjoyment!

That is it, we are out, and if have a handful of minutes to spare, please try and rate our game and leave us a comment telling us how you felt about it! Take care!

Contact us

Send us an email at or visit !

Leave a Reply

You must be logged in to post a comment.

[cache: storing page]