Designer Post Mortem

Share this post:

To start, I'd like to thank my team for the heart they put into our project, and our producer Preston, for making the game I envisioned possible. We ran into all sorts of difficulties these past 4 months, but by running into these problems, we learned by solving them, and are stronger for it.

Players really liked our core mechanic of being able to grab and throw each other to damage enemies in co-op. Our core progression system, unlocking increasingly ridiculous special moves overtime, was also very popular. Our level pathing turned out intuitive, and players rarely got lost even in early iterations. Our environment pieces interact well with each other to create satisfying chain reactions that respond to the players' attacks through physics and sound. While originally a bug, thrown furniture launching other furniture it hits, works so well with the game, that we kept it in. It really creates the feeling of storming the place that I originally intended for the game to have.

By some freak accident, of all the things that made it into the game, we kept the dab button in. See, dabbing was the only mechanic in the game meant to heal the players other than reviving each other. You would dab on enemies after staggering them with a heavy attack instead of grabbing them for a small health boost. The point was to encourage the players to "bad manner" the enemies. When playtesters asked for a way to restore their health, this was the only existing feature documentation that could solve the problem. I ended up removing the healing effect from the dab since players were dabbing way too much, and instead, scaled back the enemies, resized their hitboxes, and set checkpoints to heal when they are first set as the respawn point. But for a hot second, the meta of this game was to weave dabs into your combos to steadily regenerate health. While it was really funny, it was very clunky, and didn't work as well as what we have now in part because it was only a bandaid that hid other problems. Still, I'm happy that of all things we have an emote. A lot of people like to spam emotes in multiplayer games like this as a form of nonverbal humor with their friends, so it's a good feature to have for our intended audience. I only wish we had time to fill in all 4 face buttons with dumb emotes like I originally wanted, but the dab was the best one by far, so it worked out.

But not everything went right for us. I pitched this game having had only 2 hours of pre-production, so many things needed to be ironed out immediately once it was picked. The feature documents needed to go through a revision process, but we didn't have time for that; there were only 4 days between the pitch being picked and the first sprint, and our producer needed as much of those 4 days as possible to work on the backlog. This caused us to run into unexpected problems we would have foreseen if I had a prototype before we started. We needed an ALR to know what our scope could be, but couldn't make one without detailed, finalized pre-production. Features would have to be scoped out of the game, but without knowing our scope, I had no way of knowing exactly which or how many while the main features themselves would all be affected by any of them being removed. This would inevitably lead to features that were not cut being changed to fill in the gaps: most notably the scroll system for unlocking moves having to replace bosses which were part of the game's core loop.

Because we were unable to fit bosses into the game's scope, the level objective had to be changed halfway through development, and the level designers never got the climactic end pieces they were promised. Instead, they had to improvise with special enemies later in development in rooms not meant to be the climax of their levels. Our hybrid, animator 2D artist, Canyon, made some hybrid animated 2D art to show players how to use the special moves in absence of the "first hand experience" the bosses would have given. I was still worried players may not understand the utility of these moves without seeing the moves be used (on them) by the bosses, but after seeing playtesters actively look for special moves they may not know about yet before they were progression locked, that worry dissipated.

Creating the tutorial level halfway through development made it hard to get relevant playtest data on the controls and the combat. The difference in skill between players who played the tutorial and those who didn't was leagues apart, so balance was borderline impossible to figure out until we had a tutorial. This is in part because the control scheme is so unconventional, so the tutorial is more important for picking up our game than it is for most. Feedback features were implemented too late in development which made it difficult to tell what was intuitive to playtesters early on. I didn't learn until later that the condition for grabbing enemies was too specific which made our core mechanic difficult to engage with. It wasn't until a lot of these mechanics were stripped away that players started to consistently have fun with our game.

The chaotic room system made it inherently difficult to plan the location of enemy encounters. When a player breaks down a door from a distance, enemies end up running out of the room they were placed in, and straight towards the players: leading to inconsistency in how the levels are experienced. While this was somewhat the point, making an amount of unpredictability, this is a step further than I expected. Every enemy encounter can be triggered from long or short range like this. The two tools for the level design team to minimize this and to have more control over encounters, durable doors, and invisible encounter triggers, didn't make it into scope. Because of this, our levels are missing a layer of polish they otherwise would have gotten.

The level design kit was not completely implemented until late in development. The special enemies, which were core to the game from the beginning, were not created early enough which required a total overhaul of enemy placement halfway through production. While the level designers were made aware that they would eventually get new enemies to work with early in production, and to not spend too much time working on the basic enemy placement, none of us were expecting it to take until sprint 5 for them to get their hands on a core part of their kit. Pathing tools like ledges, breakable walls, and locked doors were also delayed which made it difficult to get an accurate picture of how levels would navigate for most of production.

When creating directions, I learned that for programmers, I need to be very specific about what values need to be easily adjustable for the design team. Early in production, I frequently had to ask the programmers to go back and serialize certain values. For animators, I learned I need very specific instructions on limb position and timing for each part of an attack they're animating. We ran into an issue where different punches in the combo were landing in different spots which required the animators to go back and fix them.

I learned more than halfway through development that everyone presses shoulder buttons differently. Our game binds everything to the shoulders, so this was a big issue. I designed the control scheme with the way I hold a controller in mind. If I had known that most people hit both the bumper and the trigger with their index finger (like a crazy person), instead of hitting the trigger with their middle finger (like me), I never would've picked that control scheme. By the time I learned this, it was too late to do anything about it.