Menu

Designing with the Team

Introduction

As the Lead Designer on reBERth it is my responsibility to propose designs for systems, outline requirements for feature development, verify that designs are on target and adjust them when they’re not, and overall ensure a cohesive, entertaining experience for players. This means lots and lots and lots of decisions, both big and small. As these decisions pile up, so do the problems.

The core issue is that the brain is only capable of making a limited number of quality decisions over any given span of time. This is due to an effect known as decision fatigue. As we make decisions, our brains burn up our glucose stores. As glucose depletes, we become reluctant to make trade-offs. With the astronomical number of decisions required to make a game (let alone one that people enjoy), it’s easy to see how susceptible the process is to suffering from poor decisions.

So what is a small team with a single game designer to do? How does the designer productively tackle all the decisions that need making in order for development to progress? As a team of six developers, we are not limited to a single “decision making battery”, but actually have one main battery with five in reserve! Not only can we make more decisions together as a team, but we can make better decisions overall.

Every developer on reBERth, whether a composer, artist, programmer, product manager, or level designer, is invited to contribute to the design of the game. The one requirement is that proposed designs must be in line with the shared vision for the game. To that end, I developed and maintain a Vision document that is separate from other design documents: it lays out the expected final gameplay experience and establishes a set of design pillars that help direct the entire development process.

Invitations to contribute design input aren’t rare, either. I try to recognize when I’m feeling creatively stymied or otherwise caught between what appear to be two (or more) equally good options. In those cases I reach out to members of the team and ask for their thoughts. At times they come back with ideas I hadn’t even considered, which is extra rewarding.

I’d like to provide a recent example that shows how working on design as a team can lead to some big wins. Let’s dig into something at the absolute core of the reBERth gameplay experience: the Weapons System.

Case Study: The reBERth Weapons System

Some History

If you’ve played a version of reBERth already then you should know that what you played was a prototype. To date we’ve created two such prototypes, each with a separate take on “musically driven weapons”:

Pressing down the “Fire” button puts the ship in “firing” mode, but it doesn’t necessarily shoot. Different elements in the music cause different weapons to fire. If no such elements are playing, the ship is silent, even though the player clearly wants to shoot.

Pressing down the “Fire” button turns on an audio track that’s synchronized to the main level music. This track is special, however, in that there are always more music notes coming. When those notes hit, the player will fire.

We built these two separate versions to get a better sense of what does and doesn’t work for our players. Of course, the second prototype was informed by the first, and they are both informing our current implementation.

The Proposal – Iteration One

When it came time to draw up designs for the next (and nearly final) version of the weapons system, I turned back to the Vision and thought about where the prototypes failed to meet our goals. I proposed a new system that broke the level’s audio into multiple layers, each of which could be tied to a specific weapon. The player would decide which layer to “focus” with the controller, and this would simultaneously cause the audio system to duck out the non-focused layers.

With this system, the player would be encouraged to strategically connect their specific weapons (pew-pew gun, laser, etc.) to a layer of the music and then see how their connections worked. Of course if a layer ever went silent, that weapon would not be able to fire, and the player would be forced to switch to a different weapon.

As part of a quick technical prototype, I built a multilayer ducking system to showcase and sell/prove the idea to the team. With my initial prototype, the user would simply press a button to set which “layer” was focused, and it would stay that way until a different button was pressed. Simple!

Iteration Two

I showed this prototype to a reduced team (holiday break) and asked for feedback. Evan (our programmer) mentioned that while he thought the idea was neat, he felt a bit saddened that we wouldn’t be able to hear the original version of the music anymore (the full mix), especially since our composer put so much effort into making the music sound so good. He paused for a minute before proposing a simple solution: “What if you only duck it while the player is holding down the fire button?”

The change was simple enough that it took less than five minutes to implement in the prototype. The results felt incredible.

Iteration Three

With the entire team back from break at the next meeting, I was able to proudly show off the new weapons system design that Evan and I had put together. Reactions were positive and yet lukewarm. Several on the team were hung up on the fact that players might not be able to use their favorite weapons whenever they wanted to, that forcing them to switch to a different weapon based on the music would create a poor play experience. “Strategy!” I countered. “Frustrating! Confusing!” they struck back. Sensing myself starting to feel defensive, I asked rather what they would suggest to overcome these shortcomings.

After a few minutes of spitballing and digging into each other’s ideas, they proposed a new approach: separate weapon choice from the music layers. “Players get to keep using their weapon of choice and, better yet, we can modify that weapon based on what layer they focus on!” I was initially skeptical, but began running it through a few imaginary gameplay scenarios in my head. How did it feel?

The more scenarios I ran it through, the more excited I became: this proposal inherently encourages experimentation. Furthermore, not only did it address the issues that my initial proposal set out to address, but it absolutely nailed the Vision:

[T]he player should feel like they are channeling the music, focusing the energy of it into a tangible form with which they can influence the game world.

This quote was lifted directly out of the vision document and practically describes the new Weapons System design proposed by [Evan-Justin-Larry-Eric].

Wrapping Up

My initial proposal for the Weapons System was the result of countless hours of worrying over details of how the player would express themselves in the game – how would they channel the music? What would that look like? Is it feasible to develop technically? Musically? What happens when the player presses a different button? How do we smoothly teach the player how the system works?

With such an innovative system at the core of the experience, there are simply far too many decisions for a single person to make effectively within a reasonable amount of time. “That’s why we have playtesting,” I hear you say. Yes! We’ve already built and playtested two separate prototypes and will continue to playtest this new design once we get it moving. However, the iteration that less than 30 minutes of focused attention from minds with a shared vision was able to get us cost far, far less than the playtesting loop would have.