Signal - PostMortem

Background Information

Signal was a game made by me and a small team of three other people as a part of this year's Global Game Jam. To this date, I believe this was the most successful game jam project that I've been a part of and I couldn't be prouder of what we accomplished. We had a good vision, a decent idea with an interesting primary mechanic, and a balanced team. I will speak first on those points before diving into my analysis.

I went into this game jam with no team, no preconceptions, and no plan aside from completing a game over the weekend. I chatted with a few friends that I saw there and ended up spending more time with Jaremie, who I'd met a couple times before at local Independent Game Developer Association events. After the theme was announced, the two of us began talking over very basic concepts while eating and also talked it over with the two other people, Erik and Zach, that sat near us. The four of us, since we were all sitting there talking, decided to make a team of ourselves and so our team was born (of laziness).

  • Jaremie Romers - Programming, Art
  • Zach Chapman - Art, Animation
  • Erik Raymakers - Sound, Writing
  • Me - Programming, Production

Nailing down a game design to finish in 48 hours (really, 45) is not easy. The four of us went through many different ideas based on the theme, which was Transmission. Here is the list that I have written down in my notes:

  1. Space flight simulation with terrible controls - Transmission is out, controlled by 2 players?
  2. A flight control tower at a space station || Star Gate control tower - bureaucracy simulation and problem solving
  3. Something about decoding alien message - puzzle decoder game
  4. Controlling some space rover with a time delay
  5. Something to do with STIs - Who Gave Me Space Herpes?: a logic puzzle game about calling various sexual partners and attempting to discover where your space herpes came from
  6. The Chinese Room simulation

Our actual design ended up being mostly focused on #3, but with a twist. Instead of simply decoding a message, you can also send messages back. And instead of focusing on aliens in the sky, we decided turn our attention down below the sea, listening to a Signal from the deep. Our major inspirations were Lovecraft and MYST.

What Went Wrong

Feeling very good about how the project went doesn't preclude anything from having gone wrong. While many things did go right, we had a few slip-ups as well. It's also possible that there is more wrong than we realized, because the first major thing that I would say went wrong is that we went too long without all the major systems in place, and so never actually had it fully play tested.

The game design was very much dependent on journal entries that contain puzzles and clues to help the player figure out what the incoming signals mean and how to respond to them. Without those puzzles done, we didn't really have a means of having someone try them. And because we waited until they were done to actually implement the journal system, even if we had sat someone in front of the game there would've been nothing to do aside from tapping on the radio to see what happens. As of this moment, I don't believe anyone on the team has fully gone through the game to make sure the puzzles make sense and can be solved. Also I believe that I'm the only one that stepped through the communication system to make all the calls and responses went as I had in my notes. I wouldn't call this ideal.

Please play our game and tell me what I did wrong so I can fix it? Cool.

I think another major pain point was, surprise, dealing with source control. We did not use git this time around (more on that in the next section), but we still ran into a few issues due to Unity's new Collaboration tool. I will make a list of some important notes based on this particular experience in the "What I Learned" section, but suffice to say at this point that I definitely lost a few hours managing the various conflicts and hacking together a Frankenstein monster of committed assets. But hey, it's alive!

Another repeated enemy showed up again - time. Although this game went relatively smoothly, there is always more polish to add. We have roughly twenty minutes of recorded voice acting for the journal entries waiting to be added. I think the work to implement them would take about an hour or so, but that was an hour we didn't have. I'm hoping to take that time and add them before we present our project to the local community at a party in a couple of weeks. Also the time to play test would have been nice, though with the amount of time our game is likely to take for completion, I doubt anyone else had time for that either.

What Went Well

Most of it! After team formation (which ended with us not attracting anyone else), we discussed our design for about another hour or so figuring out exactly what we needed to hit our minimum viable product for upload. I captured and was tracking those items on a Trello board, which ended up really being for my own benefit for keeping myself on track. We rounded up a few times to discuss what needed doing and to assign marching orders. For the most part, this went as well as could've been expected. With minor hiccups, everyone finished what they set out to do.

It looks and sounds gorgeous. Zach and Jaremie both did a great job with all the art pieces. I am a huge fan of Zach's work on the boat-rocking animation and the piece of the finale. Jaremie did a fantastic job both with the radio ticker and the journal interface. It was a sheer joy to see all the debug junk I had built for myself slowly get replaced by real professional-quality work. The sounds that Erik crafted (and found for a few) add so much to the scene as well. To sell the intended ambience, we needed the visuals and the sound to be on point and I think the team really pulled it off. I am incredibly happy with they pulled off and I am excited to have been a part of it.

Despite also putting it in the "What Went Wrong" section, I'd say that using Unity's Collaboration system was super beneficial to our team. In previous projects I've always used git, but anyone that has read my previous post mortem will remember that it doesn't not work particularly well with Unity. Collaboration, though, solves the majority of those headaches and is super easy to set up. There was the downside of a team for a "free" organization being limited to three team members, but we just asked Erik to drop his assets elsewhere for us to digest and that seemed to work fine. Compared to previous projects, I believe this was the most painless experience I've had with source control.

What I Learned

Personally I learned a lot. I had never worked on a 3D project before, so there were some things to get used to on that end. I decided that it's not terribly different from working on a 2D project in Unity, but I also didn't have to deal with the lighting. I'd also never worked too much with sound in Unity, other than playing a sound or two as a OneShot for various player interactions. The sound in this game was much more complex. I used multiple audio sources, as well as stored and dynamically shifted multiple sounds in my code, setting timers and loops that were modified by listening to player input. It was a lot of fun and I'd relish the opportunity to do even more complex work with audio in the future.

I think the most important things I learned were the lessons from some hiccups with Unity Collaboration. I will list them here for convenience.

  • If you are working within an instance of a prefab and you add an object to it as a child, you need to add the child to the prefab asset as well. If a team member makes a modification to the prefab asset, you will lose your unsaved children when you sync the changes.
  • If possible, don't group too many objects that people are working on within the same prefab asset. We ran into a pretty serious issue on Sunday morning where two different versions of our primary prefab asset were basically irreconcilable. We managed to work it out, but it made me panic a bit and we could've avoided most of it if we had a sturdier architecture in the first place.
  • As with all source control, it is important to commit, push, and pull often. It is much easier to manage issues when there are only one or two of them at any given time. You're also less likely to see strange duplicates if everything is kept basically up to date all the time.

Sleeping more makes you better at work! I know, novel thought - but I slept about 6-7 hours on the second night and I was definitely far more productive on Sunday than I was on Saturday, for which I'd only had five hours of sleep. I'd also add that a team break can be real nice. We had a pleasant dinner together on Saturday night and had a very good plan for going forward after that.


Alright, I think that about covers it! If you'd like to check out our game, head over to my Games page (which I will be added later if you're getting here early) or go directly to our Game Jam submission page and download the .zip file. Please, feel free to reach out to me via the comments or my email if you have any questions, comments, or just want to talk!