Game Retrospective

This is cross-posted from my personal blog.

Over the weekend, I participated in the GMTK 2019 game jam. The challenge of the jam was to create a game featuring "only one" of something that is normally plentiful in other games - in a 48 hours or less. The game I created for the jam is Single Sighted, a game where you only see one pixel (at a time). If you have the time, I'd appreciate it if you played the game and let me know your thoughts.

The remainder of this post will be my retrospective thoughts about making the game and participating in the jam generally. The content will probably make more sense if you play the game first.

What Went Right

Early in the jam, I pivoted several times, and benefited from each one. Initially, I dismissed the idea of "only one pixel" as being too difficult to implement and too esoteric of an idea to be appealing to players. Instead, I spent about an hour working on a shmup with "only one bomb" before realizing that the jam was bound to be filled with "only one projectile" action games. That led me to pivot to "only one pixel," specifically because it would be difficult and esoteric.

Another important pivot happened while working on the movement for "Single Sighted:" I began by implementing a simple grid-based movement system, but after completing it realized that being able to rotate in space was a critical part of locating the source of a sound. As such, I rewrote the movement system so that left/right turned the character 90 degrees, and up/down moved the character forward or backward. Focusing on 90 degree turns allowed me to continue using the grid system, while still being more immersive than the grid movement.

Working under the constraints of the Jam have improved my skills immensely. I have very little skill with audio, but having my game theme virtually eliminate visuals meant that the game forced me to learn to use my audio well. One particularly useful skill I had to learn was how to quickly and efficiently find and edit public domain audio: having limited time meant I couldn't waste time struggling to make my own, which ultimately benefited both the game and myself.

Another skill I developed was how to adjust Unity's 3D sound settings to find the right balance of being able to locate the sound in 3D space versus having a pleasing/realistic balance of audio panning. While there is probably a lot more room for improvement here, I started with absolutely no knowledge of 3D sound, so everything I achieved was the product of learning during the jam.

Staying on schedule worked really well. Specifically, I was able to achieve all but one of the milestones that I set for myself. In large part, I think this is due to setting each milestone from the vantage point of hitting the previous milestone. By limiting how far ahead I would look, I was able to keep things realistic and keep mistakes, issues, and pivots from causing slippage across the whole project. As a quick summary, these milestones were:

1. ~2 hours: Pick an idea
2. ~5 hours: Commit to idea
3. end of day 1: working vertical slice
4. ~1 more hour: get playtester feedback
5. sleep
6. morning day2: generate ideas
7. early day 2: implement the cat
8. (the monster and cave ideas were discarded at this point because the cat was a good enough idea on its own)
9. mid-day 2: implement victory condition - this is the one milestone that slipped
10. final hours day 2: get playtester feedback on whole game
11. sleep
12. final day: resolve remaining issues

Carrying the cat is immensely satisfying. I'd love to say this is by design, but it was really a lot of lucky things all overlapping. Merely including the cat was luck: my wife and I often joke that adding a kitten to anything makes it better, but for some reason when she made that joke about the game, I instantly realized it could be turned into actionable advice. When it came to working on the audio itself, I found, to my delight, the cat purring sounded even better in-game than it did during editing. Additionally, since the design of the game focuses the player on the soundscape, the player is primed to pay close attention to the purr, and the use of 2D sound instead of 3D allows the cat to feel as though it occupies the same space as the player, effectively simulating holding the cat. Looking back on it, it's easy to see how the design and sound worked together, but during development I was only focused on the issue in front of me: "the player might not realize they still have the cat, so it should make a continuous sound."

Lastly, although I hadn't expected to collaborate going into the game jam, by the end my wife was so involved in the project that I think it's only fair to describe it as collaboration. From feedback on ideas to playtesting in odd hours, to even composing and recording the ending theme, my wife invested significant time and effort into the jam. I think we are both happy with how it turned out, but going into future game jams, it will be good to keep this in mind: we very well might collaborate again, regardless of whether or not that is our intent.

What Went Wrong

The game is very unapproachable - I knew that would be an issue going into the idea, but I didn't put anything in the game itself to mitigate it. In particular, I was unable to reconcile the constraint of only one pixel with any form of explanation, so a player who tries to play without sound or expects a more traditional kind of game will likely put it down immediately. The one slight workaround I implemented was using a small viewport on the itch.io page: I kept the description short so that the controls and warning about requiring audio should be visible at all times while playing. I expect many players still won't read this, but I hope that it at least helps someone. While this could have been avoided by picking a less out-there theme (or breaking the "one pixel" rule by including in-game explanation) I am happy with the choice I made given the constraints and circumstances.

Very little time was spent QAing the game. Mostly this worked out ok, both because the scope was tiny and also because I have a tendency to search for and fix bugs as I develop. There was one issue, however, that likely impaired playtesting and was only detected in the final hours before submission. Specifically, it was an issue related to movement - under certain circumstances the character would play the turning sound, but didn't actually turn. While I was able to detect and resolve the issue before submitting the game to the jam, I am guessing some of the poor user experience reported during playtesting may have been caused by that bug.

I had very little interaction with other jammers. While I did join the discord and spend time on the forums, I didn't do much to demonstrate my participation. Going into it, I didn't have any specific social goals in mind regarding my social interactions, but as I look back on it now, I feel that I could have done more to reach out to others, either to get help or to provide help to others. Going forward, I expect that I can get better results if I choose jams that are less crowded and set clear goals to push myself to interact (such as "help at least one person.")

Summary

Overall, I feel that this has been an extremely successful game jam. I really grew as a developer, and I am quite pleased with the game I made. I also have plenty of lessons learned that I can apply to future jams, and I plan to continue to participate, both in GMTK and in other game jams, in the future.