Postmortem: Balance This Game!

About the Game

This is a postmortem about Balance This Game!, the whimsical strategic sim about balancing an MMORPG as a summer intern. You can read more about it or play it here. Otherwise, I won’t spend much time talking about what the game is so I can focus on lessons learned that might help others.

Takeaways Up Front

Since postmortems are really about what other devs can learn from this project, here’s your generalized takeaways. If you’re curious about any of them, read on for the unpacked explanations. The postmortem is divided into 6 mini-stories, so you can read any of them and in any order.

1. Games don’t design themselves, you’re making many micro-decisions at every step and acknowledging that fact can help you see bias
2. Give time and space for reflection; catch your tunnel vision early
3. Scope early and re-evaluate scope often
4. Playtest early and often, but beware of using up your playtest pool
5. Game development uses more skills than you realize
6. Don’t underestimate emotional impact

Games don’t design themselves

At the moment-to-moment level, making BTG felt like a linear journey: a problem came in, I reacted to it, and the solution felt natural. But in reality, problem-solving passed through the filter of my being and how I solve problems. I was actually making hundreds if not thousands of micro-decisions along the way that made the game what it is. Things like:

• What should be the minimum and maximum values for each adjustable stat? In what step sizes can these values be changed?
• What does the pop-in / pop-out animation look like for bringing up a UI panel, if one exists at all? Does it change scale, does it rotate, does it change color or create particle effects or make a squish noise?
• And so much more

Whether I acknowledged it or not, I was making game design decisions while programming, while creating art assets, while choosing SFX and BGMs… every step of development was designing and shaping the game. Although noticing this doesn’t directly change my development process, I think it does help me see the bigger picture a bit better. My biases are going into the game with everything I do, and recognizing that can help me recognize what those biases are.

For example, maybe BTG became a whimsical game because I use humor to mask my incompetencies. Why do the sprites not have a consistent art style? Not because I was grabbing free assets and mangling them together, but because it’s funnier that way! Why are there so few enemy types? Not because I can’t draw, but because the devs keep reusing monster skins! With this approach, my flaws can be played off as contributing to the ridiculous premise. But ultimately, this was a design choice that came from me.

My original design draft on Miro had shops spawning from towns which sold items to the players.

Giving time and space for reflection

One of the benefits of working nights and weekends on this project meant that I had periods of downtime when I wasn’t thinking about the game. This was helpful not only to give my playtesters time to play and give feedback, but also to give my brain time to rest and process. In addition to managing burnout, breaking up work into smaller sessions meant that I had time to think about the big picture. I could mull over code problems and potential debugging strategies, I could think about player feedback and how to address it, I could refine my ideas and come up with new ones before diving back into the grind.

The most salient example of this was when I was working on the title screen. Before I even had a title screen, I was working on an animated intro to the title screen. In hindsight, yeah, that was dumb. But I got it into my brain that it needed a really funny animation to introduce the game: some epic music and some RPG title coming up, and then that title gets bounced away with the logo pieces for “Balance This Game!” coming in. I tried animating the widgets in Unity, and when that wasn’t working I started looking into 2D animation software. I spent two or three hours on this, but then I had a chance to take a break and realize — wait, why do I need an animation to have a title screen? I could just make the title screen and then add the animation if there’s time. So I did, and there wasn’t. But at least I made a title screen. I wasted a couple of hours, but if I hadn’t been giving myself time to reflect on my development approach, I could have easily wasted a dozen or more.

My original design draft on Miro had enemies dropping items in addition to gold which could be sold or equipped.

On scope

I planned to (and did) make this game in 6 weeks, so scope was always on my mind. I found that it was helpful to define how much time I’d be spending on the project ahead of time. It’s very possible that if I never defined a deadline, I’d be working on this game on and off for the next five years and never publish it. So I’m glad that I set a tight deadline and I’m glad I finished something, even if it’s not perfect.

Quite early on, I also defined my features using the MoSCoW method. Using this prioritization, I started working on the must-haves before the should-haves and could-haves. I think this really helped get the core together. In the end, I actually ended up implementing some version of all of the must-haves and should-haves (or moving them into the could-haves). Looking back on my GDD actually, it seems like I also added a priority between should and could called “would be nice.” For the curious, here are some things that would have been nice:

• Draggable UI elements snap to the edges of the screen
• Different players have player types or personalities
• Shops that sell weapons and gear to players
• The ability to rename enemies, dungeons, and towns (type in a new name)
• A title animation showing the logo bouncing into place to create the title screen

But as these things go, a lot of features got scrapped for the sake of time. In fact, the code actually defines weapon types having different attack speeds, base damages, and attribute scaling for attributes like strength, dexterity, and charisma. But I knew that if I worked on adding different weapons, I wouldn’t have time to polish the core gameplay loop.

In practice, once I had my MoSCoW defined, I worked in patches. Over the 6 weeks of development, the game went through 12 major versions. For each version, I wrote three lists of things to do: bug fixes, gameplay updates, and aesthetic updates. From there, any new to-do got bubble sorted into either the current patch, the next one, or the “would be nice” pile.

I approached development in this way for a few reasons. First, the bubble sort kept me focusing on the most pressing things. If there was a game-breaking bug, that would have to come before adding a new feature. Second, breaking things down into more manageable bites kept me motivated because I was creating medium-term goals (patches) made up of short-term goals (to-dos). And third, this approach ensured that patches were a tandem development of software, gameplay, and aesthetics, so that none of them lagged behind and collected debt, and so that my playtesters always had some new things to look forward to in every regard. By incrementing each section of development, I could iteratively test every part of the game. Which brings me to my next story…

On playtesting

Everyone always says to playtest, and boy are they right. The first major version I tested had the bare minimum to express the concept, and I’m glad I put it out when I did, since the game needed a lot of iteration. As a simulation, one of the biggest issues the game faced was communicating enough information to make meaningful decisions without overwhelming players. Most of my playtesting focused on what information was missing and what information wasn’t helpful. In fact, the daily report (and the concept of graphs at all) was suggested by playtesters (thanks Dray!). Playtesting also precipitated a few good ideas that I hadn’t thought of myself, such as the constraints mechanic (some stats are fixed or fixed within a range so you have to balance around them), the ability to spawn and de-spawn enemies, and the UI timers showing when the next enemy/dungeon would spawn. Playtesting also improved my existing concepts, leading to improvements on the required player count and simulation information in the UI. Really, a sizable chunk of the game was making improvements by player suggestion.

Over 6 weeks I tested 12 versions of the game. I tried to have a new version every few days, or at most once a week, so that I was never going too long without feedback. I also tried staggering my playtesters: for any given individual, I would ask for their feedback only after 3 or 4 patches so that their evaluation applied to more than just a couple of corrections and their time was used efficiently. I also tried to have at least one new playtester for each version in order to have constant fresh eyes, though that wasn’t always possible.

Near the end of the project, actually, I found it hard to get people to play the game. Maybe they were burnt out by trying the game a few times already, and I had used up my pool of friends and family to reach out to. I’m not sure if I have a solution to this besides paying for playtesters or bugging acquaintances more, because I certainly wouldn’t want to spread out playtests any further than I did here.

Game development uses more skills than you realize

I knew when opting into this project that it would use skills I wasn’t practiced in, but it’s worth emphasizing just how many skills get used in game development. Making BTG required me to act as: game designer, system designer, level designer, game programmer, artist, musician, project manager, marketer, QA tester, UX tester… I might even be able to name a couple more if I thought about it harder. Luckily, I didn’t have to do too much in art and music, which are my weak spots, but I still needed to modify some existing assets which used photo editing and audio editing software.

In short, this project was a good experience in realizing how much more there is to development than making the game. Nearly the whole last week of development was just spent learning Lightworks and making the trailer. But I’m glad I got to practice these various skills. Over the course of this project, I learned a lot about Unity and built a few scripts that will eventually become a codebase I can reuse for future projects — not to mention the suite of free assets I collected and curated. I have a feeling my next project will go a lot faster with this groundwork done and a full project under my belt.

Don’t underestimate emotional impact

One of the first things they teach you in game design is to kill your darlings/babies and not get too attached to ideas. Obviously, this theory gets tested repeatedly in every project as the ideas you like just aren’t working out. But that’s not what caught me by surprise in this project. What caught me by surprise was the exhaustion as the project neared completion and the anxiety of actually launching something.

The last couple of weeks were tough. I was tired of the game and the concept and the buggy code. My brain couldn’t help but drift off toward other game ideas and things I wanted to work on. I think two things ameliorated this: that the project was only six weeks long, and that I was only working on it nights and weekends only with copious breaks. Burnout sucks, and I did the best I could to not get completely dispassioned.

Then, on launch day, a different emotion hit me. I was actually releasing something — publicly — that would be seen by more than close friends and family. Hitting the “send tweet” button was hard, and the wrap-up had me too rattled to write this postmortem the same day. Maybe this was exposure therapy and I’ll be more resistant to the anxieties for the next launch. Or maybe this is just part of releasing something creative into the world. Only time will tell.

About the Project

What engine did I use?

Unity.

How long did I work on it?

I started BTG in mid-September 2021 with the intention of working on it until the end of Devtober, giving me 6 weeks to make a game. This was a hobby project that took my nights and weekends, with generous break time so I didn’t burn out. All things considered, I probably put around 100 hours into development, give or take a large margin of error.

Why this topic?

I decided from the start on a game about balancing a game (in fact, the original project seed “balance this game” became the title) because I wanted to make a game about practicing a skill by interacting with a simulated system. Game balancing happened to be one such skill that I use myself when developing games. Coincidentally, Ludum Dare 49 happened during the start of Devtober with the theme “Unstable,” which fit perfectly.

How much did this cost to produce?

Aside from the 100 hours of dev time, I was fortunate enough to make heavy use of free assets on Unity’s asset store and free versions of editing software. I only spent money on one asset, a $9 pack of mumble voices. During development, I was able to sell one copy for $3 (that achieves the Devtober goal of making a dollar!), so the net cost comes out to $6.

About the Author

Who am I?

My name is Josh, I’m a PhD candidate at Northeastern University studying game-user interaction and how to teach complex skills using games. My primary research focus is on creating good tutorials (though I don’t endorse my own tutorial in BTG as “this is how it should be done”). I’m currently the lead game designer of Foldit, a citizen science puzzle game about helping scientists design proteins. Despite the academics, I try to incorporate industry best practices of development into my work.

What comes next?

This project was the first in a series of small-ish games I’m making to sharpen my skills as a developer. I’m not going to say much just yet about the next one, but I will say it’s going to be closer to the citizen science work I’ve done, and I’ll be learning a lot about plants as I work on it.