David McDonough, Jack Cooke, and I polished off a 1st place win at Rosetta Stone’s first annual 36 hour game jam in Harrisonburg Virginia on Saturday.
The requirements for the game were given out beforehand, and were very open-ended: make a game that “teaches.” Coming from Firaxis, we decided to make a strategy game, and settled on a “virus” theme. We liked the idea of a virus strategy game because we could abstract things visually (simple shapes with cool shaders – no characters to animate). The simulation aspect of the game play could also be very simple, and amounted to little more than three numbers driving a physics-based steering system (like this).
Each of us had some basic knowledge about how vira spread in the body, and we really didn’t go out of our way to do any additional research. One of Sid Meier’s 10 Rules of Game Design (we’re not really sure which one this is – he changes the order all the time) is to “make the game first, then do the research.” This may sound a bit strange at first, but it makes sense. If the game isn’t fun, it doesn’t engage the player and loses the ability to teach. If the simulation is to detailed or esoteric, the player can’t easily grok it, and you lose them. Civilization is a great example of this. It is built from the assumed historical knowledge of the average gamer (unless you fire up the Civilpedia). The game doesn’t teach by relaying historical facts, rather it does so by allowing the player to engage in a simulation that, while not historically accurate, illustrates very clearly the dynamics of industry, diplomacy, war, and culture.
The game we ended up with at the end of the day is called Pathogen. It features game play that is very similar to Phil Hassey’s Galcon with a 3D play surface. You move your swarm of vira from cell to cell, expanding your population and avoiding autoimmune cells as you go. Before each level, you load out with three “mutation cards” which give you power-ups as you hit certain population milestones. The game is very simple, but illustrates well the balancing act a virus must perform when successfully infecting it’s host.
What Went Right:
We knew the prompt for the game jam ahead of time, so we had quite a bit of time to plan for what we were going to make. When we got there, we had a very clear development schedule and asset list, so there weren’t any surprises. David, who is a producer at Firaxis, was very on top of things as per usual. He broke down the game into manageable hunks – usually punctuated by a meal, which served as an excellent motivator. The only thing missing was Hansoft.
You never really finish a game at a game jam – there’s always something more you want to do, but we scoped our game very well and stayed true to it. Again, good planning ahead of time and real world game production experience helped us stay true to our original goals.
The Unity Engine played a huge part in our success. The engine made it very easy to prototype and iterate quickly. Unity virtually eliminated the need for an asset conditioning pipeline – regardless of what we threw at it, Unity just worked. With Unity, there was also never a “make a build” step to our design process. The game was always live, and we could see changes we made instantly. While we probably would have created an awesome game without it, it certainly could not have been the game we made with it.
For a 36 hour competition, it was tempting to go in thinking we would stay up for the whole thing. We had the foresight, however, to work sleep into our schedule. Even short naps did wonders for productivity. We knew we were going to have to pull a very long night to get the game done, and we opted to do it later in the project rather than burn out with a long stretch at the very beginning. We worked four hours the first night, slept for six, then worked until the end of the jam, taking naps occasionally. We all got extremely tired at times, but it wasn’t as bad as it could have been. We really should have brought pillows though. Sleeping on the floor was not fun.
What Went Wrong
One of the down sides of using Unity, and there aren’t many, is that the indie version does not support source control – no Perforce or Subversion. With two people coding at the same time, the project would inevitably start to branch, and we would periodically have to manually merge all of the changes. Unity projects don’t like to be moved around – especially from PC to Mac, so often a merge wasn’t just merging source files, it was reconstructing whole levels and prefabs. In the future, it might make sense to at the very least source control the code (I think you can do this) to make merging prefabs and levels in Unity easier, and perform the merges more often. OR Unity could include source control support in the indie version. Preferably the latter.
The game shipped with three complete levels, which was great, but we didn’t really have time to balance and test them. As a result, the game is almost impossible to lose. This is probably better than a game that’s impossible to win, but because the levels were so easy, some of the cool systems we put in to progress and upgrade the player (like virus mutation) weren’t really needed to win.
It was loud. Really really loud. Lucky for him, he won a new one!
Overall, there was very little negative to say about our experience. Rosetta Stone did an awesome job putting this game jam on. The accommodations were great. There were volunteers to answer questions or get something for you if you needed it, and there was food and drink available pretty much all the time. Everyone we met was really cool, too, and we hope to see them again next year!
Also, we were on TV!