Goon Game: Sprint 7 Retrospective
- Trainer 117

- May 6, 2024
- 4 min read
Another week: another reaffirmation of something I was told in college.
This last sprint was interesting – to say the least. Beginning with a loss of three days due to injury and ending with the realization that we need to return to basics again. However, this sprint can be considered a success despite its hairpin turns and dangling threads. Those turns led me somewhere important, and those threads aren’t in need of tying anytime soon.
I began this sprint with the goal of better understanding the advanced game by testing the Advanced Cops to see how well they would match up with the player units; what I found about halfway through was a significant power imbalance. I’ve spoken before about how the balancing act between keeping the player at a manageable disadvantage is a key part of the overall design philosophy for this project, so I’ll keep this brief. If the enemies can do 5-6 things with their kit, then I want the player to be able to do 4-5 things; currently, player units average around 5 while enemy units range between 4 and 7. So the problem became players quickly steamrolling their opponents or getting steamrolled themselves because they lacked potent enough tools to counter specific units.
So, pivoting from testing to retooling, almost every player unit got a rework to their basic kit with plans to revamp their progression. The focus was not on bringing them on par with more challenging enemies but instead on giving them a more refined kit that fit their role and game. The largest change, in my opinion, was Schemers: going from a rather lukewarm unit with some practical de-buff skills but lacking any real reactive potential to being able to lay down and maintain status effects and conditions on enemy units. This also led to the creation of several new status conditions like Blind, Drowsy, Sleep, and Blackout, tools for the player to remove threats without knocking out an enemy unit and potentially starting the Hero countdown. This line of thinking will permeate into sprint eight as I focus on fleshing out these new kits and adding more ways for players to interact with obstacles outside of the traditional bonk-it-on-the-head method.
However, I had to leave behind story iterations in pursuing this path. A sacrifice I am willing to make (for now) for the following reasons. To start: The game is still in flux. The best actors and the greatest writers can’t save a play that has no stage to act upon, so before I go writing scenes and crafting arcs, I need to build the foundation on which those elements will dance. Second, the ludo narrative is off; the only way to fix that is by addressing the game's mechanics, not the written story. Going along with the play metaphor, when a scene feels off, you rewrite the scene, and you change the structure of the scene by rewriting dialogue, changing settings, mixing up the wants of your characters, etc. But with games, if something feels off, it's probably because your written story and your game story are at odds with one another, and you need to get them into sync. In my case, the written story is about a crew of C-list supervillains narrowly escaping failure and coping with lose-lose situations to the point where they can build up a power base to be a real threat. But in this current iteration, the game story makes everyone competent to sell the C-list image of the written story. Failure is always looming; players need to know that and plan accordingly.
In writing that previous sentence, I realized how apt it is in describing this project and game design in general. I’ve been aware of the mantra ‘fail faster’ in games for some time now, possibly since I first heard it back when I was 16. However, I’m finally getting around to what that phrase actually means. Designing games is hard, thankless work, as is all art, and to make something exceptional, you need to try, fail, try again, fail again, repeat. Taking into the next attempt the lessons and mistakes of the previous effort paves the road to success by ensuring that you understand the project a little better each time and can account for hindrances you may encounter. For me, it has been that testing one week iterate the next is not conducive to a productive or healthy head space. It creates doubt gaps; cracks in the foundation that grow and grow the longer they are left unaddressed. Failure is part of the process, but allowing it to take center stage robs the creator of the lessons it brings to focus on the problem itself and not the solution. It puts you in the now and blinds you to the path forward, and the only way to see that path is to see what isn’t working, try to fix it, and chart your own way out.



Comments