From Prototyping to Production: 3 Rules You Should Always Apply
I joined Mighty Bear Games as a game designer back in May of 2021and immediately began working on Disney Melee Mania. I had some experience working on a live game before joining Bear Force One, but the majority of my time had (and still has) been spent in the research and development phase of game projects, i.e. prototyping.
This was initially a bit of a shock to the system, as I found myself wondering how I could appropriate my prototyping skills on a project that was hurtling towards its Alpha build. Suddenly my day-to-day was a lot less experimental and a lot more deadline-oriented. So much of my old approach had to be thrown out. This was no longer gut-feeling design tweaks and ‘quick and dirty’ code changes; we simply didn’t have time for a ‘throw everything at the wall and see what sticks’ methodology.
During my time building prototypes, I developed a set of rules that I abide by each time I undertake a new project. Some of these rules I learned from researching how other studios made their games, some are things I learned through my own personal trial and error. Most are both.
Not all of my prototyping rules could make the transition to the production phase. For one, the idea of just throwing out anything that isn’t working and pivoting to something else is especially unpalatable when a deadline looms. It’s simply too wasteful to be effective at later stages of development.
So, without further ado, here are my rules for prototyping and beyond:
- Know your game
- Focus on the unknown
- Innovate and iterate
Rule 1: Know your game
Prototyping
While it’s great to be open-minded, the task to “make a game” is immensely broad and unhelpfully unspecific. It’s best to narrow this down a bit, without limiting yourself. The key is to understand your game. But, how do you understand something that doesn’t yet exist? Identify why you’re making a game at all.
Before conceptualising a core mechanic or even deciding the exact genre, I discover the game’s purpose by asking myself what the player should feel when they play: will they experience tension? Fear? Joy? Nostalgia?
Another approach is to consider what qualities the game should embody: will it be difficult? Competitive? Narrative-driven? Exploration-centric?
Once you’ve decided what your game is for, it’s time to construct your Core Pillars. These Pillars are the core, inalienable tenets of your game. No matter the stage of development, these Pillars will not change and will serve to determine what should be a part of your game and what shouldn’t.
The more Pillars you have, the more rigid your design will become, but having too few could leave ‘holes’ in your concept. In my experience, 3 feels like the magic number here, providing just enough guidance without feeling overbearing. Once you’ve got your Pillars, stick with them. Mechanics can be altered; art direction can shift; in some cases even the genre of your game could change, but the Core Pillars are forever.
Production
When it comes to full-fledged production, the use case for this is rather obvious. Anytime you make a design decision, ask yourself: “Does this fit our Core Pillars?” If the answer is “yes”, then you’ve got a greenlight. Otherwise, you’ll need to rework your idea until it does fit, or simply set it aside for another game. This can greatly simplify tough decisions and, if you’re working in a team, settle disputes on what is the right decision.
Here’s one example. Throughout the development of Disney Melee Mania, our Core Pillars have been (and will continue to be) that the game should be:
- Accessible
- Chaotic
- Irreverent
When designing Buzz Lightyear’s ultimate ability, I wondered if maybe we should modify the standard controls. All moves in Disney Melee Mania are performed on-release (i.e. when the player lets go of the corresponding button), allowing players to quick-tap to auto-aim or hold the button to precision aim their attacks.
I originally envisaged Buzz’s ult working a bit differently, where his laser would continue to fire so long as the player held down the attack button and would stop when released. This would, in theory, allow the player greater control and manoeuvrability when using the attack as they would be able to aim a continuous stream of fire while still moving around.
The drawback, however, is that the different input style would be jarring and difficult to explain. I could imagine a lot of players wondering why this suddenly worked differently from every other move in the game, or perhaps not even realising they needed to hold the button down (since no other move requires this) and potentially even concluding that the move is simply bugged.
Ultimately, I referred to our Pillars for guidance and the answer was clear. With ‘Accessibility’ being the very first core concept of our game, I realised the move had to be re-designed to make it work like all other moves, i.e. hold to aim, release to execute. So now Buzz becomes stationary during his ultimate, allowing the player to continue aiming without changing the mechanics of how the ability is activated and avoiding confusion.
Rule 2: Focus on the unknown
Prototyping
A common error I’ve seen (and done) is focussing too much on implementing common game elements that are known to work. It’s best to think of prototyping as experimentation–the entire point is to discover something new. Generally speaking, prototypes should be barebones, and exist only to prove (or disprove) a hypothesis or collection of hypotheses.
My approach: first, build the basic framework; but as soon as the game is playable, STOP and ask what is best to implement next. You may envisage your game having Feature X or Mechanic Y, but always stay focussed on what is different (and thus unknown) about your game. What needs to be proven?
It’s easy to fall into the trap of adding things because similar games have them, but it is imperative that you avoid this pitfall early on (there will always be the opportunity to add the obvious stuff later). If you’re making a roguelike and Feature X is in every other roguelike you’ve played, it’s most likely safe to assume that this feature works and doesn’t need to be a part of your initial prototype. But if Mechanic Y is something altogether different from what’s out there, then you need to verify that it fulfills its intended purpose. Almost invariably, you will be testing if your idea is actually fun to play!
Production
This rule applies later in development, too. In production, ‘unknown’ tasks (those that have not been done before, and therefore cannot be easily estimated in terms of time or difficulty) will be prioritised highly. More specifically as a designer, the earlier you can realise an idea, the sooner you can assess how the corresponding feature or mechanic performs and the easier it will be to tune and balance.
For another Disney Melee Mania example, I’ll go back to Buzz Lightyear. At one point in development, we felt Buzz wasn’t really working. We considered the idea of converting him into a ‘rapid-fire’ character, whose purpose would be to suppress opponents with a constant barrage of ranged attacks.
It’s worth noting that at this point (pre-Alpha) Buzz’s secondary ability was bugged and his ultimate was unbalanced. We knew the secondary ability could be fixed, we knew we could tweak his ultimate. So when it came to reviewing the character, we decided to first focus on the thing we didn’t know: how a rapid-fire character would affect the game’s overall balance.
The change was simple enough: we made Buzz’s primary attack cooldown, super low (something like ~0.2s, if I recall correctly), allowing the player to essentially spam the attack to unleash an unending torrent of lasers on the enemy. If you’ve played the game, you know Buzz doesn’t work this way, here’s why:
First, players using Buzz didn’t like having to constantly mash the button to maximise their effectiveness. Second, when playing against Buzz, the constant influx of lasers was annoying and seemed OP. Interestingly, even when we nerfed the damage to the point that his DPS was the lowest in the game of any attack, the sentiment remained. Psychologically, it felt oppressive and just frustrating to play against.
Ultimately, we decided to keep Buzz’s attack cooldown at a respectable length and instead increased his range, making him an effective ‘prodder’ that could poke enemies from afar, to harass or kite them into ambushes or away from objectives. Thus Buzz was given his place in the meta without upsetting everyone in the process!
Rule 3: Innovate and iterate
Prototyping
If you followed the first rule, then you know why you’re making your game. Now you must audit your idea to identify its inspiration and honestly evaluate if it offers something new to players and improves on what is already out there in a meaningful way.
Contrary to popular belief, the goal of game design isn’t to be as original as possible. It’s easy to be original if all you care about is originality. People have to get your game, and that’s infinitely more likely if they have a frame of reference. That is, if your game has similarities to other games.
In my personal opinion, you should try to be different, but not too different. Taking something that exists and improving on it is a fine aim. That’s how 99% of progress is made in any field. Game development is no different.
In fact, originality for its own sake isn’t recommended. But the flip side of this is that you of course need to offer something new, or at least different, otherwise no one has any reason to play your game at all. That said, I like to focus on innovation, rather than originality.
In the research phase of a project (this can either be before conceptualisation when looking for inspiration, or when you already have an idea and are looking for potential competitors) it’s crucial to determine how your yet-to-be game will fit into the current ecosystem. Consult the zeitgeist, see what’s trending, get a lay of the land. Figure out if you are diving into a Red Ocean or a Blue Ocean.
Blue Ocean concepts are those truly original ideas that have no direct competitors. While all games are competition (realistically, anything your intended audience can do other than play your game is competition) there are simply no easy comparisons to existing games. This can be a good thing, of course. The game will have an easier time standing out in a crowd. However, it also comes with a lot of potential problems. The more original an idea is, the more you have to explain to players, leaving you at the mercy of their patience and attention span.
This doesn’t mean you should necessarily avoid Blue Ocean ideas, just be aware that simply being original doesn’t equate to guaranteed success. Side note: Don’t try to reinvent the wheel; if another game has cracked the code, don’t avoid using their solution purely for the sake of artistic integrity. Take it and innovate.
Red Ocean ideas are those targeting a space with a lot of existing competition (like a MOBA, for example!) Here you want to be sure that you have a way to stand out. If you’re looking to make a Battle Royale game, why would players play your BR instead of PUBG or Fortnite? How does your game improve on what’s already out there and, more importantly, is it disruptive?
For Disney Melee Mania, it’s obvious which of the two types of oceans we were diving into. There are a lot of MOBAs out there, and more every day. We had to look at what we could offer that would be different from the rest. A massive part of that is, of course, the IP we are partnered with and characters we have had the privilege to work with. If you ever wanted to play a MOBA with a diverse mix of Disney and Pixar characters, Disney Melee Mania is where it’s at. But we also make the effort to stand out in other, perhaps less obvious, ways. Where other MOBAs have become unintuitive and complex, we’ve strived for simplicity and usability.
Production
So how is this applicable during the rest of the product life-cycle, when the game is in full-scale development or perhaps even already launched? Obviously, you always have to keep an eye on what your competitors are up to, no matter what stage of development you’re in. However, another application I’ve found for this is to recontextualise the ‘ecosystem’ you’re considering. Each time you look to add more content, whether characters, levels, gamemodes, etc, reflect on how it fits into the game, or rather, if it fits into the game.
Since launching Disney Melee Mania, we’ve been hard at work on updates to improve the gameplay balancing and add further content, giving the player even more champions to choose from. When designing these characters (that cannot be named just yet!), we considered how they fit into the game.
For us, each champion is meant to be a ‘Blue Ocean’ concept, i.e. there should be limited overlap with existing champions. We don’t want reskins and minor stat changes; each champion needs to have their own personality and playstyle. For one of our upcoming characters in particular, I reviewed our existing roster and found we didn’t yet have a champion that straddles the line between melee and ranged. And so I set my design goal to be just that: to introduce a character with the ability to switch roles on the fly, allowing it to stand out from all others already in the game.
The key to prototyping and, in my opinion, to game design in general, is iteration. Rarely, if ever, will you get it right the first time. Even if it feels good right off the bat, you can almost guarantee that it can be improved in some measurable way.
In my pre-MBG days, I’d been on projects where the production cycle was so tight that the moment a designer had written up a document, engineers were implementing it. Then the feature was shipped and then we were assigned to the next thing. No design reviews, no playtesting, no feedback, no iteration. This, unsurprisingly, led to some poor design decisions making it into the game (not to mention technical debt as even engineers didn’t get a chance to iterate on their work). There’s never going to be time to get everything perfect before it goes out, but as long as iteration is at the core of the development process, the game will get better with time. These rules go hand in hand: the key to innovation, or even achieving something original, is iteration. When you improve on something over and over again, it eventually stands entirely apart from the thing that inspired it.
I hope that by using these rules you’ll be able to take a more structured and methodological approach to your prototypes and be able to infuse the ‘magic’ of prototyping, with all its excitement and potential, well alive throughout the production process. If you enjoyed this read or found it helpful in any way, drop me a clap or a comment, and follow us on social media for more content like this!
From Prototyping to Production: 3 Rules You Should Always Apply was originally published in Mighty Bear Games on Medium, where people are continuing the conversation by highlighting and responding to this story.
