Design Post-Mortem: Tetramayhem

Around eighteen months ago, I had the opportunity to work on an XNA game we called Tetramayhem. It was my second games project of any real scope (the first being the puzzle-platformer Mirrorrim) and the first one to be based on a concept that was primarily of my own devising. We had four team members and eight weeks of class time to bring the concept — a 2D, physics-based, four-player cooperative action-arcade game with light puzzle and construction elements — to life. For the most part, we succeeded, and two hectic months later we had a functional, clean looking, and fantastic sounding arcade game to show for it. Once we had an opportunity to sit back and invest some real playtime into the game that our frenzied programming and content jams had created, however, it was apparent that there were some very serious problems eating away at the very heart of the design — my design. You might have guessed some of them when you read that tortured, ambiguous description of it three sentences ago. In this post-mortem, I’ll be going into exactly what flaws I now see in that original design and what I think we could have changed to mitigate them. To prevent this from seeming entirely negative, I’ll also cover what we did right during Tetramayhem’s development, which are lessons that I think most amateur and student development teams could do worse than to follow.

What’s happening? I’m scared.

To start off, though, let me dive into exactly what kind of game Tetramayhem is — I’m all too aware that that high-level overview is about as intelligible as a zombie with no tongue and half a jaw trying to tell you what he had for breakfast (brains). In Tetramayhem, up to four players control a post-apocalyptic clean-up crew in a variety of side-scrolling, single-screen arenas. Using traditional platformer controls and a twin-stick aiming mechanic, the players have to cooperate to survive waves of incoming pollution mutants. Pretty standard stuff, when you get down to it.

However, the game is balanced such that, when on an even playing field with their enemies, the players will find themselves quickly overrun. To combat this, players are tasked with constructing their own high ground and defenses from which to rain down death. Functionally, this means that one player is tasked with controlling a hovering Block Dropper in addition to their hero avatar. This device launches physics-enabled tetramino blocks at the playfield, forming fortifications and crushing enemies. Oh, and to make things more interesting, the blocks are also color-coded, playing into a match-3 mechanic that allows players to sacrifice their defenses in exchange for valuable power-ups. Simple, right?

If that explanation still left you (understandably) in the dark as to what the hell is actually going on in Tetramayhem, you can check out the game’s tutorial below:

The problem here.

Some of the issues with this design should be clear by now, but allow me to boil them all down to one key fact: the Block Dropper, as implemented, was a broken concept. It was my baby, but I’ll be the first to say that it was an ugly, needy child, destined for a college career of abrasive dorm room braggadocio and a life of making things difficult for its coworkers in middle management. Allow me to elaborate:

We set out to design a genre mash-up, but ended up confusing “elegantly integrated puzzle mechanics” with “mandatory bewildered multitasking”. Because there was no separation between when the players were building fortifications and when they were battling enemies, it was normal for players to either completely forget to use the Block Dropper or to allow their avatar to die in order to focus on it entirely. Switching between the two control styles and mindsets mid-round was essentially impossible, and the most effective players would inevitably utilize questionably strategies such as completely encasing their avatar in blocks to protect them from the approaching enemies while they focused on the Block Dropper — not exactly behavior we wanted to encourage. We attempted to avoid the multitasking issue to a degree by splitting enemy spawns into timed waves separated by periods of relative peace during which players could build, but as these cease-fires were never explicitly pointed out to the players, they were never taken advantage of to any real degree. There were elements of the real-time mash-up that we liked — crushing an oncoming Smasher enemy with a well-placed tetramino was always satisfying — but ultimately we should have known to kill our baby and split the survival action and block construction into entirely separate periods of gameplay.

Another issue with the implementation of the Block Dropper was that it created an imbalance between the players — only one player could be in command of it at any one time. There was a system in place where a player could claim control of the Dropper with a press of the Y button, but coordinating who should be running the Dropper at any point was neither intuitive or tactically interesting for the players. This is another problem that could and should have been solved by separating the Block Dropper segments from the action gameplay — giving players a brief respite from battle during which they could all be dropping blocks and designing a fort together would have cleaned up the interface, promoted discussion among players, and evened out the balance of power and responsibility among the players.

Then there was the problem with the blocks themselves — while I still think there is something to be said for combining the positional challenges of match-3 colored blocks with the geometric idiosyncrasies of tetraminoes, I will never again make the mistake of attempting to build a block puzzle game that uses per-pixel, physics-enabled components. I can’t stress how poorly this worked — previously matched pairs of blocks would fall apart, building a stable tower while under time pressure was essentially impossible, and the angular designs of tetraminoes require a grid-based system in order fit together consistently or effectively. If nothing else, the Xbox processor simply wasn’t powerful enough to run the physics calculations on all of those blocks at once, and a large enough force applied to one side of a fort could bring the framerate to a crawl. Again, we were so focused on a couple of facets of the physics gameplay that we liked — navigating poorly-stacked blocks that shifted haphazardly underfoot, the ramshackle, wobbling structures that could be built with liberal use of the gravity-defying Glue block — that we failed to see that the system had ruined the big-picture playability of the construction gameplay.

What went right?

Firstly, the core design, convoluted as it is, was actually scoped fairly well. Tetramayhem was envisioned around a single image I had in my head — four players standing atop of a ramshackle tower of junk, firing away as the pile of slain monsters grew into a great slope around their fortress. Like with most simple visions, I immediately got carried away coming up with ideas to build around it, and the original design bloated into something far more complex than the final game would be — maps were going to be larger, players would have to scavenge building blocks from the fortifications of AI rivals, blocks could be used to craft turrets and other defenses, and enemies were to leave behind persistent, physics-enabled corpses that would stack around the player’s defenses and alter the geometry of the level. We were even planning to have a system where players could purchase new costumes that would alter various probabilities and statistics in gameplay.

However, we made it a priority that we would limit our scope to only the core features required to bring that original vision to life, and so right from the start we were taking the knife to extraneous features. Out were the human enemies and their procedural fortresses. Gone was the ability for players to carry blocks (which we felt was opening a nasty can of physics engine worms), replaced by seemingly simpler Block Dropper mechanic. Slashed was the crafting system, and the costume store was given the pink slip. Other features were removed for more pragmatic reasons — early tests in Farseer Physics showed that the towers of dead enemies were an impossibile task for the Xbox CPU, and the element was lamentably dropped.

Due to this proactive limiting of scope, however, we were actually able to complete development to our satisfaction within the time allotted. When other students were struggling to tie together to disparate elements of games they had only half-implemented, we were playtesting and doing what we could to polish our game to the best of our abilities.

Similarly, we made sure to scope content production early and according to the abilities of our team. We were lucky in that we had a good balance of artistic and auditory talent among our members, but even then, we made sure to have a concrete, actionable list of all required assets within the early days of development. While obviously it is important to focus on prototyping and design over content production when starting out a games project, when you are working within such tight time constraints as we were, is is just as important to make sure that your creative talent knows exactly what they need to do from the word “go”. I am certain that, had we had not had that asset list, by the end of the project we would have been scrapping near-completed features from our design, not because they were ill-planned or hurt the gameplay, but because our content priorities had been in in the wrong places. When your scope and timeline are as limited as ours were, you really cannot afford to

Finally, we learned the importance of being able to roll with outside demands and influence and to thrive within the bounds of restriction. A good way into the prototyping and concept phases, we learned from our professor that the game, previously pitched as a pure, bloody mutant kill-em-up, would need some kind of positive message. Putting our heads together, we came up with the idea that the game’s heroes would be engaged in a literal fight against pollution, and we were instantly far more inspired as to the style and feel of the game. Without that mandate, it is doubtful that Tetramayhem would feel anywhere near as upbeat and unique. It was a real lesson in the fact that, as Orson Welles put it, “the enemy of art is the absence of limitations.”

Eighteen months on

Looking back, I’m still proud of what we accomplished with Tetramayhem. It’s a pretty good looking game with some unique mechanics that are a lot of fun when you can get four friends crowded around a single monitor. I definitely think there are some things we should have done differently — I’d really love to see how the game would play if I went back and took out the physics component and restricted construction to a pre-battle phase that takes place entirely on a more traditional Tetris grid. I think the result would be a lot more tactical and cooperative, elements that we wanted to emphasize but ended up losing to the hectic mish-mash of gameplay styles that is the Tetramayhem of today. Perhaps one day I’ll sit down and actually make those changes. Until then, I’ll just have to invite my friends over, crack open some beers, load up Tetramayhem on my PC, and be prepared to explain the rules to them — very, very slowly.

If you’re interested in trying Tetramayhem for yourself, you can download it from my games page.

Jon Gill