We're back today to continue our series on our Shoplifter Shuffle Postmortem! If you haven’t already, check out our Part 1 of the series from yesterday, as we discussed our breakdown of what went well when creating our game. And now, for the not-so-perfect part, read on to discover some of the things we learned that didn’t go so well, and our final takeaways from our game development experience.
What Didn’t Go Well
1.The musician wasn’t on-site
Gary, our musician, had all his recording equipment at his own home and he decided to work remotely. Since he wasn’t physically in the same room as the rest of the team, communication was infrequent and minor tweaks to sounds often took more time than it should.
For example, the first time he sent over the theme song, the volume was far too low and we couldn’t hear a single thing. We asked him to make it louder and the second file ended up being slightly louder, but also too low that the words sounded like muttering. We asked him to make it even louder and he took that to mean that we wanted our ears to be blown out. The third file was SO incredibly loud that we put it in the game and played it at 1% volume. We didn’t bother to ask for a fourth version.
Another problem was that Gary was pretty much working in a bubble, going off verbal descriptions of the game and written descriptions of how we wanted the in-game music to feel like. It would’ve taken us too much time to upload a build for his own eyes to see.
2.Not testing the demo device earlier
From the very start, we knew we were going to demo the game using the artist’s laptop, since he had the biggest monitor. We built the aspect ratio of our game to match the laptop’s screen. What we didn’t take into account was that he was using a four-year-old machine.
When we finished development, we put the game on the artist’s computer and set it to fullscreen. Unfortunately, all the vector graphics had to scale up more than twice its original size. Tons of vector scaling plus a four-year-old processor meant an input lag that was about two seconds long. That may not seem like a lot, but one major element in our game is the ability to watch the shoplifter’s fingers and try to map it to an onscreen character. The two-second lag made it almost impossible to match key presses to character animations, since a character would often keep scurrying along after the player stopped pressing any keys.
We ended up having to optimize the code and convert a bunch of vector art to bitmaps, which only helped the problem a little. (C’mon, who optimizes during a game jam?) Thankfully, we lowered the computer’s resolution so that the game only scaled up by a factor of 1.2, which mostly got rid of the input lag problem.
3.Not enough playtesting
Since the game is a battle of deduction and observation between two asymmetrical players, the balance between the shoplifter and the security guard had to be fine-tuned. If it was too easy or too hard for the shoplifter to blend in with the crowd, the game wouldn’t be fun for either player.
We needed extensive playtesting to reach this balance, but unfortunately we lacked both time and available testers. As a result, the game tends to become lopsided after a few rounds of practice: a well-played shoplifter can be almost undetectable, making the security guard’s job too difficult. While we had plans for a few subtle “tells” that could help the guard identify the shoplifter, we didn’t have time to implement them.
Our Final Takeaways
This year, we experimented with a minimalist version of the game jam: a lower-stress, less time-consuming experience that still produced a fun and innovative game. Even better, we all had a lot of fun making our game and are looking forward to doing it again! Remember that the game jam experience is all about you – the game developer – so you have the freedom to approach it in whatever way works best for you.
We’re planning to reassemble some of our team for a few other local game jams later this month, so look forward to more postmortems soon!