Goon Game: Spring 5 Retrospective.

So, originally, this was going to be a much larger piece, as I wanted to talk about an interesting design challenge I encountered while testing. However, after an hour of getting my initial thoughts onto the page, I not only had no idea where I was going with that, but I may have changed my mind midway through, and I’m not sure I agree with my new opinion. That piece has been taken out to cook some more while we focus on what happened last sprint. Yet I bring all this up because the two spring from the same seed: addressing the game balance.

With this last round of testing, a whole host of tweaks and adjustments have arisen. Some simple number changes, others a complete retooling of an entire kit. However, while these changes will be critical to the game’s success, the baseline design of the concept appears to be working. Players are still encouraged not to engage directly with enemies, players are punished for not taking advantage of every unit, and even when they think they have an advantage, one bad roll can spiral things down quickly if they have not prepared for failure. Going forward, that should be the focus: giving the player the tools to plan for failure. In other words, make kits proactive, not reactive.

For example, the Schemer’s Kit is one of two kits that needs to be reworked. Only one of its two abilities (not including its basic attack) is useful at any given time. Recover Ray is dependent on an ally taking damage. However, testing has shown that, at these early stages of the game, turtling strategies don’t work. The player units are too squishy or weak to form a proper tortoise formation. Having a support function to negate damage could still be helpful, but it needs to be more in line with Skill Nullifier in Epic Seven, a buff that flat-out prevents all incoming damage for a single hit. That way, the player has a safety net if a Hammer Goon Misses a 90% hit chance and alerts the target but only draws a single Cop. Funny enough, you don’t think 10% is that high of a percentage until it happens at least once in every test you run.

However, I would have never reached these conclusions if I hadn’t swapped goals mid-sprint. A risky move on my part, and thankfully, I’m the only one on the project, so no one else was confused by the new direction. But it was a kick in the head that showed me that planning and documentation are handy, but if you spend 90% of your time thinking about the game and not playing it, you’re not really developing it. Games need to be tested, ideas must be put to practice, and scripts must be drafted. Hence, going into this next sprint, I want to start cracking the main story script again. The outline has definitely helped, and while it could still use some tweaking, futzing with it anymore isn’t going to get me to the breakthrough I need -writing the damn thing will.

I plan to start small, focusing on the main throughline from which everything branches. That is more or less the baseline for the story, and while there are segments on that line that require flags that I’m not going to be writing next sprint, it does allow me to get a liner script started with a set of characters that I know will be in each scene. Because that throughline story is about Zolo, Doc, and Zolo’s patron establishing the universe's status quo and setting up Zolo’s arc for the rest of the game. This is where the most information (in the first half of the game) will be introduced to the player, and the player will be trained to see Optional Objectives as mechanically rewarding so they can push themselves to achieve them later on.

That’s the plan moving forward: test frequently to gather more actionable changes for new iterations. With this, I hope to avoid the long stretches of just doc work I fell into for the past four and a half sprints. Vigilance will be essential, however, as those documents will change as more and more information comes to light and things within the game change. Hell, I’ve been thinking that I may have to redo sections of the Art Direction Doc for consistency and clarity. However, said changes can no longer be the goal of the sprint. The goal is to test, gather data, and make meaningful, visible changes to the prototype. Through that, a better game will emerge.