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!

Space Junk - PostMortem

Background Information

I've already talked about the nature of the capstone project in a previous post, so I will skip all of that here and get straight into the details on our game, Space Junk, starting with the team formation.

The original idea behind Space Junk belongs to two of my eventual team mates - Jessica Dungca, who gave the pitch and acted as team lead during formation, and Erica Lee, who Jessica credits as the originator of the basic premise during brainstorming. I knew immediately upon hearing the words "raccoon-ing junk and building a space ship" that a) my own pitch was bad and I wanted to work on this game instead and b) this needed to be about actual raccoons gathering actual junk.

After being very insistent with Jessica that I would be a good addition to the team and being generally excited, we ended up with the following:

  • Jessica Dungca - art, design
  • Erica Lee - general support, menu design, market research, sound asset gatherer
  • Jordan Hamann - art, animation
  • Michael Biggers - programming
  • Me (Bobby Brace) - programming, production, design

After much discussion, we settled on the following design: the game, Space Junk, would be a very laid-back, cooperative adventure with two players and two stages. Stage one would be the assembly phase, where the two raccoons run around and gather garbage and place it on a rocket-shaped grid, one piece of junk per square. After completing this task, the players would transition to an auto-scrolling space adventure game where the two players would work together to control their garbage rocket, dodging and destroying space debris, before making it to the moon where they would have a picnic. With this in mind, I set up a SCRUM board with all the tasks we could conceive of to meet minimum standards of completion (many more were added later). I decided to put our game's tagline above it which Michael had come up with as a joke but we all loved, "We are all trash held together by friendship." And with that we got to work.

What went wrong

Problems came at me real fast when I hit my first major hurdle on the first night - Windows Updates. Unbeknownst to me, it had been so long since I had used my laptop that I had a major patch to install, which began downloading in the background and hogging all of my hard drive I/O capability. Thankfully I was able to mostly overcome this by letting it run all night and waking up early to make sure the updates installed. Then I disabled Windows Updates for the rest of the project.

The much worse hurdle was setting up GitHub. We decided early on that only Michael and I would be using the repository to mitigate conflicts as much as possible. I also went about setting up a .gitignore file using an existing template. Of course none of that worked the way we expected and we spent roughly two hours being crippled by some cursed conflicts in the meta files (which we learned to ignore) and again with our different interface set ups (which we learned to accept). We did work through these kinks, but between that and my computer issues, I think I lost about 3 hours of working time which is pretty rough.

The biggest problem that we had was, of course, time. The three lost hours cost us a few things - more animations, sound and music, an annoying bug in the controls of stage one, and getting the grid system working in that first stage. That last one was pretty big - we didn't have the level fully running until about 90 minutes before submission and it was then found that the system built to check the contents of each individual box in the grid didn't work and we really didn't have time to fix it, so Michael hacked it apart and just checked the entire grid as a whole for the 15 pieces of garbage we were using. I also lament the loss of Jordan's beautiful explosion animation that they made for the space debris in stage two, as well as all the sound effects that Erica acquired early on in the project. I only had time to hook up one sound, so I chose the firing sound during the second phase which I figured provided some of the highest player feedback.

What went well

I think the first thing that anyone would notice went well is that the art is phenomenal. Jessica and Jordan both did a fantastic job bringing this game to life. Jessica alone managed to churn out 15 individual pieces of garbage in beautiful bright colors as well as the background for stage one. Jordan created two separate animations for the two raccoon heroes (top view and side view) as well as the space debris, can projectiles,  and background for stage two. As mentioned above, there was also an explosion animation that didn't make it in, due to me running out of time to hook it up.

It seems like patting myself on the back, but overall I think our organization as a team also went well. We took the time at the start of the project to clearly mark out what needed doing and verified that it was doable by at least one person on the team. As people finished work, they just needed to walk up to the task board, put their name on a card, and move it on to In Progress. By the end of the 43 hours there were only a couple of To-Do items left, neither of which was actually vital. The project started well-scoped, even for having two completely different play modes which may be considered a bit much for a game jam, and at no point were we struggling with scope creep. If we hadn't lost those few hours, I have no doubt that our problem would've become figuring out what else to add. But most the most important thing is that we completed the project and submitted on time.

I would also say that actually coding the game went well once we got going. With two programmers on the team and two stages to complete, the obvious thing to do was to each take one. Michael handled everything the garbage collection game in stage one (which I wasn't confident I could handle at all) and I handled everything in stage two. My work there actually ended up being far easier than I anticipated and only took me about 4-6 hours to complete. I spent the rest of my time hooking up the animations, handling the sprites, hating the input manager, putting the menus together with the images that Erica handed me, handling all code merges, and eventually performing the actual final build.

What I learned

Make sure your machines are updated before bringing them to a time-sensitive event. Have a backup plan in case of hardware failure. Also, Windows Updates can be completely disabled, so maybe just do that for the time that you need to make sure you have no interruptions. I can't stress enough how annoyed I was with that entire experience.

Know how you're going to handle code at the beginning before you start actually coding. If you're using a system that your unfamiliar with, read up on it ahead of time. For me that would be learning how Unity interacts with GitHub, which honestly is still a bit of a mystery to me. I may try a different management system in my next attempt or, ideally, let someone more experienced handle it and ask them to teach me what they're doing.

Effective time and project management is vital to the success of a project. This is something I already knew, to be fair, but seeing how well everything came together really reinforced this idea. In previous game jams I had used a purely digital SCRUM board that really only I was looking at. I much preferred the method used this time around - index cards taped to a white board. I may endeavor to use a physical board from now on.

Market research is cool, actually. The presentation that we had to give was put together by Jessica and Erica (though we all spoke) and it contained a market/competitive analysis for our game. Honestly, from what we eventually found, child-friendly cooperative games turns out to be a starving market and it's maybe not a bad idea to get in on that. Will we do so with Space Junk? Maybe. But not right away.

 

Thanks for sticking around this long! I hope you enjoyed reading my thoughts. You can check out the game in the Games section of my site here if you're curious. Also feel free to leave a comment here or shoot me an email. I'd love to hear more from the community. I do plan to write one of these up whenever I finish a new project, so you can look forward to a lot more of this in the near future.

Space Junk - Background Information

As mentioned in my previous post, I have just recently completed a program called Immersion through a local organization, GLITCH. Because most of the people that I assume would read this are likely already familiar with GLITCH I won't get into their mission or what they do, but Immersion is a program they run that puts small cohorts of about 15 people through a series of after-hour and weekend lectures, workshops, and a couple of industry visits all about the games industry. In it we learned the development process, a crash course in programming with emphasis on Unity scripting, game art, game design, writing and narrative design, project management with Agile, and marketing. I believe, from my experience, that the primary goal of these courses was to open doors and show us all the things that are available and necessary in the industry. We learned that there is much to learn. This is something I think think I knew but I have a better handle now on which things that I don't know, and that is valuable.

This program ended with a capstone project that took the form of a sort of game jam. There were some key differences between this project and other game jams, which I will detail in this post before doing an actual Post Mortem in the next. The three key differences were the pitching process and team formation, the market and competitive analysis requirement, and presentations.

The pitch process was just slightly different from what I was used to, but was good in what it accomplished. We were given the theme, Voyage, and broke off into groups to discuss possible concepts based on that theme. We were then given 15 minutes alone to draft a pitch and another 15 minutes to give those pitches. Everyone was expected to pitch. The twist to this is that the two heads of the program, Evva and Nic, then went into a meeting room and decided which three pitches would be made into prototypes. We were not privy to the selection process, but my first guess would be they wanted to make sure that the three projects selected would be feasible in the 43 hours we would have to complete it.

Ultimately the three projects chosen were Dungeon Mapper - a game where a pacifist player character enters a dungeon to draw the map for future adventurers; Mountaineer - a claustrophobic mountain climbing simulator starring a person with two broken legs; and the project I worked on, Space Junk - a cooperative adventure starring two raccoons building a spaceship out of garbage.

Part of the rubric we were given for the project contained a market and competitive analysis component. As a part of our development, it was expected that we would also determine how to sell our game. This isn't usually a consideration for a game jam so it struck me as odd, but ultimately I would say that this is a vital part of the project and it gave practical experience on this kind of research that first-time developers might overlook. I believe all of this was handled for our project by my teammate, Erica Lee, who did a great job. I enjoyed going over her findings.

The last difference was in the presentations at the end of the project, which took place just a few hours after the submission deadline. We traveled to an off-site location, Twin Cities Public Television in downtown St. Paul, and gave presentations on the stage there with slides that needed to be also made during the project timeline. Our presentation was mostly put together by Erica and another teammate, Jessica Dungca, though all of us spoke on the stage to different aspects of the project. The turnout was unfortunately low, probably due to the snowstorm that was going on at the same time, but plenty of people showed up and my team did an excellent job of presenting and then demoing Space Junk.

Alright, I think that's enough background information. A Post Mortem of the project itself will be up later today and I will also fill in more information on the game page.