was lucky enough to have the opportunity to participate in my second Global Game Jam this past weekend, and I came away from the experience exhausted but very proud to have had a part in creating A Matter of Fact. (we even won an award!) Although pride and exhaustion are the two biggest takeaways that come to mind right now, the team (and certainly I as an individual) learned a lot about fast prototyping and the constrained type of development process implicit to a game jam. This post is going to act as something of a postmortem to our design and development process, in order to highlight some of the high-level lessons that we learned -- oftentimes the hard way -- over the course of the weekend.
Lesson 1: Scope not only your ambitions, but your genre too
A Matter of Fact was originally conceived as a response to the Jam theme of "waves;" with the inauguration and its implications for the flow of information and news in the US fresh in our minds, we came up with the idea of a strategy game where two players have to position transmission arrays to win the hearts and minds of the people. However, we also wanted to incorporate the idea of propaganda and fake news into this concept; players should shoot for maximum dispersal of their message, rather than (perish the thought!) truth or objectivity. While I'm still intensely proud of the fact that we were able to unite these two disparate gameplay mechanics in a way that feels mostly cohesive, even just the act of describing them in writing makes apparent to me how susceptible the act of uniting the two concepts is to overblown scope and feature creep. Knowing that we were hoping to make a large-scale strategy game should have been a key tip-off for us that our game would need to be as mechanically simple as possible so as to afford us enough time to conduct the requisite balancing and playtesting time. Though playtesting is key to the success of any game, our choice of genre means that we would ideally need more effort on this front than, say, a platformer or a shooter. We really weren't able to put the time towards this though, as much of our design and development time was dedicated to creating and uniting these two concepts. As a result, the game isn't as balanced as I would like it to be; a hard-won design and production lesson to take with me to future jams.
Lesson 2: Take breaks when brainstorming, but decide fast
Thankfully, this lesson comes from one of our successes at the jam. After about half an hour of brainstorming, we broke to go get dinner. On reconvening, we were immediately able to not only come up with the idea that would become A Matter of Fact, but also decide on its overarching design principles and purpose. When all's said and done, our ideation phase lasted only about an hour, leaving us the remaining forty-seven to actually create the game. I personally attribute a great deal of the success here to resisting the urge to immediately sit in a circle discussing ideas for hours after receiving the theme. By conducting a more informal and active brainstorming session (team members would tag in and out to write ideas on the whiteboard or go get food), we were able to find our idea quickly and devote more time to development. This is in direct contrast to my brainstorming experience at my first game jam, where my team and I spent five hours sitting around a table in a boring white room discussing what our game wouldn't be. The distinction between these two methods and their impact on their respective games is obvious, and definitely informs the brainstorming approach I intend to take in future.
Lesson 3: Once you've started, take the time to stop
An issue we had once we were fully locked into our development process was one of inertia. As we got closer and closer to the weekend's deadline, we found it harder and harder to stop and reconvene to make sure we were actually doing the right thing. As a result, we ran into some miscommunication and scoping issues at the very end of the Jam, resulting in some far far too eleventh-hour feature implementations that could have been avoided with some scheduling effort. Because this endgame cram is predictable, we might have preemptively scheduled checkpoint meetings to discuss delegation, the direction of the game, and what we need to do next.
Lesson 4: Be careful with random generation