Best Laid Plans: 7 Game Design Failsafes
How to catch design flaws before it’s too late
If one thing is certain about game development, it’s that as your game moves between stages of completion you’ll encounter plenty of issues you didn’t consider in the early days of the project. For a designer, these can range from bugs to holes in the design itself to changes in overall game-scope which can be almost puzzle-like in complexity. These blind spots will often become most obvious as you near the end of a development cycle.
Over the years I’ve developed a few methods for capturing and addressing these issues sooner rather than later. I hope you’ll find them useful!
Note that I’m starting this article with the expectation that you’ve written a solid design document and figured out the numbers already.
1. Don’t just trust the numbers, feel!
Your project can look nice and tidy when it fits into an intricately designed spreadsheet or design document — if it does, the first part of the development puzzle has been solved!
However, first-hand experience has taught me that while a solid design plan is a must-have for good execution, it is only after actually implementing this design for the first time that you’ll begin to understand how everything works in practice.
I rarely if ever take for granted that an early design will make it to the final stages of development unchanged, so it’s important not to become paralysed during the documentation stage and instead to move forward at the right time. New needs and conditions will force revisions, and much of that intricate documentation will soon be redundant — so don’t expend all your time and energy on getting it “perfect” at the expense of making progress with the project.
2. Simulate your design
A more recent piece of design advice I’ve learned helpfully conceptualises something many of us already do in a new way. A former project leader of mine stated the following:
I want designers to simulate and think through their ideas before sharing them with others.
This piece of advice might seem fairly obvious on the surface, but it became something the design team kept in mind as a sort of a mental braking mechanism used before blurting out a potential fix for a problem or sharing an idea we hadn’t fully thought through.
This approach applies to the question of documentation, too: Once your design is written (or even better, while you’re writing it), try to imagine it playing out in your head! This can sound odd at first, but picture the feature being played in the game, or this level mechanic, or that playable character — does your idea still hold together or did you hit on something you hadn’t considered?
It can be easy to fall into the trap of “finishing the document” rather than “solving the problem”, but with a couple of minutes spent on this mental exercise you could save time during the review and arrive at better insights than you would just by re-reading a document. You won’t solve every problem this way and I’d still argue that testing is always the key in the end, but it helps a great deal along the way!
3. Keep track of all feedback
In recent years I’ve enjoyed a wider view of the projects I’ve worked on, so this is something I’ve been able to put to the test a number of times.
When discussing design plans with your team at any stage of the project, exciting new ideas for the game design can come up out of the blue. I make sure these are (mostly) noted down.
I used to think, “I’ll remember” — I no longer trust this!
There are simply too many discussions with too many people for you to be able to remember everything, and out-of-the-blue ideas can be some of the best and most stimulating. We also have a section in our design documentations for fully written-out Design Risks, or specific Tests we’ll need to run.
I’ll often start a “shell document” of a design I know we’re due to tackle some time in the future, adding bullet-pointed ideas here and there as they’re raised by the development team.
Once an idea is in development we take detailed notes during meetings. This means that weeks or even months down the line we can dig back into a document for a feature and be able to find the context for a change which was made during a review.
On a previous project before my time at Mighty Bear, there were so many pieces of feedback from stakeholders to keep in mind all the times that we ended up creating a feedback document for each level. We’d refer back to this document fairly regularly to ensure we hadn’t forgotten any previous feedback.
4. See for yourself
During my first professional project, each designer would be required to play the entirety of their content (that is, their level) on a daily basis for the final few milestones of the project. I have to admit this was tedious, and there were some questions posed as to why we needed to do this when there’s a whole department dedicated to doing the same thing.
But therein lies the point:
We know our content better than anyone else.
In fact, we know our content so well that it helps us detect the slightest change in an unrelated system: if the jumps feel weird today in a platforming level we know was built perfectly to metrics, maybe there’s been a change in the character’s implementation? We can then check with someone in the know who can potentially help resolve this early. This aligns with a Mighty Bear principle our CEO Simon has previously pointed out: that people should call out problems as and when they see them.
We also know the parts of our work which may be “a bit fragile” and need additional testing to shore up their weakest points.
Admittedly, regular playtesting is much more fun on a multiplayer project…all part of the perks of working on multiplayer games at Mighty Bear!
I remember a feeling of dread I used to get in designer playtests during the final stages of development: “I really hope I don’t find something serious”. Precisely because of the daily playtests, I never did. (Though that feeling still rears its head occasionally!)
I feel most at ease when I’ve played through my content and confirmed for myself that it works as intended. This may not be possible depending on the scale of a project, but at the very least you can use the odd session to check in on elements of the game you feel may be getting neglected!
5. Play your game like a player
During the regular playtesting of your content, it can be extremely tempting to “autopilot” your way through. The problem is that this means you’re doing minimal surface-level testing and not making the best use of your time. Your flow through your content will become increasingly optimised with each robotic playthrough and you’ll rarely deviate from a given path: you’re essentially doing a speedrun!
If you find yourself doing this, make a conscious effort to shake up the way you play!
Deliberately play your game differently: take a different path, use a different character, collect a different weapon, play to lose! You’ll soon uncover new issues you didn’t know existed and parts of the design that may need more work.
6: Ask a development outsider to play your work
Although late to the list, this is one of my favourites. Keep a list of colleagues not working in development and call on them at important points in the project. You’ll only really be able to get one set of “first impressions” from each of these people, so make the most of it: if there’s a screen flash every time your character jumps in today’s build, maybe delay that playtest until tomorrow!
Watch how they play and how they react. Ask them to be brutally honest and say exactly what they’re thinking. Record the session and take detailed notes (more on these points later). Better to hear anything negative now while you can still act on it than after the game releases!
Some of the best feedback on a recent project came from a Managing Director’s Assistant who hadn’t had eyes on the game at all. She was a gamer herself and the approach she took while playing was much more in line with how a player at home (or a project stakeholder) would play. We were able to get great actionable feedback from her and really improve the level of polish at a crucial stage in the project.
I personally value these non-developer playtests from anyone regardless of how much they play games: they’ll help you see how easily players might understand and digest design elements that may seem totally obvious to you. (You’ll find they rarely are to anyone else!)
7: When playing someone else’s work in a 1:1 situation, say exactly what you’re thinking while you play
Now let’s turn the tables and consider how you should act while playing someone else’s work…
Just by playing someone else’s work for the first time in front of them, you’re giving them the most valuable feedback and information you could possibly offer!
- Record your playsession — everyone has access to screen-recording software these days.
- Mention exactly what is on your mind while you’re playing. Don’t filter. This feedback is what the Designer needs and wants to hear (provided it isn’t too late!): you’re offering a window into your decision-making process and experience as a player, and I can’t overstate how valuable this is — especially for single-player games.
Here are some cues to get you thinking (and talking!) while playing:
- You’ve just entered a new area — what do you see?
- Where are you going to go first? Why?
- Why are you focusing on this enemy?
- Why did you attack the enemy from there?
- Why do you think you failed this jump? Are you annoyed? Did it seem easier than it actually was? Why?
- You’ve run out of ammunition — what will you do now?
If you don’t verbalise these thoughts, the designer watching is left only watching and guessing what you’re thinking — no-one can read minds.
Make sure the designer is taking notes! As mentioned earlier, it’s much too easy to forget crucial details of a discussion afterwards.
The End!
That’s it for now! I hope these points are useful for your own approach and help save you from nasty late-project surprises! Feel free to leave a comment below if you have any thoughts on these tips or think I’ve missed anything!
