The Trials of Error (1/2)
Pictured: Cards from 4 prototypes of the same game, all of which were scrapped eventually.
A whole lot of valuable lessons learned, though.
Where we last left off (So, you want to make a game…), we discussed the core aspects of design as a process and some simple steps one can follow in order to get started with working on a project of their own. However, with any project, you will sooner or later hit a wall or two. Everyone makes mistakes, and when you’re just starting out with design, it might feel disheartening when you realize things don’t always work out the way you planned.
As it goes with most of game design, the thing that most directly translates to skill is experience. Once you’ve already made a specific error and have seen the consequences of it, chances are that you will be prepared for the next time that situation appears, and will be able to better handle or outright avoid the issues that could arise from it.
The truth is, you have to make most of these mistakes yourself to learn how to overcome them. The goal of this article is to highlight some of the common issues designers can run into, why they occur, and offer some advice on how to avoid or fight them.
So, in no particular order, some of the classic blunders:
Too much theory, not enough testing
The designer spends too much time theorizing about how the game might play, instead of actually seeing how things really work through testing.
This is a really common mistake that can plague both junior and senior designers, and it’s pretty obvious to see why. We want to be certain that the things we make will work once we actually get to the playtesting. However, it’s very easy to fall into the trap of thinking you’re able to accurately predict the behavior of things. While you get better at this as you get more experience, no one can be 100% sure how a game will turn out until you sit down and actually play it. Designers can also often make assumptions about player behavior, which almost always ends up with the players doing something the designer wouldn’t have expected or intended.
This is why we test as soon as possible. Testing early and testing often gives us the much-needed feedback which we then use to strengthen our theories and gameplay over the course of the design process. Try to design in a way that will allow you to have a playable prototype as soon as possible, so that you will have the most time possible to respond to any issues.
And that all-important feedback leads us right to our next common pitfall:
Hearing only what you want to hear
The designer only selectively takes feedback from players into consideration, most often accepting feedback that aligns with how they want things to move/turn out, rather than taking in the whole picture.
While it may seem trivial, knowing how to properly listen to, respond to, and incorporate feedback is an acquired skill that takes a long time to understand and develop. This point covers the mistakes that arise from not knowing how to properly focus on what feedback is the most important for the health of your game.
As an example, let’s imagine we’re working on a card game in which we combine different cards to make sandwiches. Following the previous point, we decide to test ASAP. We fire up the printer, make a prototype, and then find a couple of
victims playtesters. We play a match, and at the end, get 2 pieces of feedback: One player says that everything’s fine as is, but they feel like you should add more types of sandwiches, since they had more ideas than the game’s rules currently allow. The other player says that while they had fun, they feel that the sandwich-making is a bit poorly defined at the moment. Rather than give even more options, they feel that you should instead make the system itself more rigid, so that options are even more obvious when playing.
Both pieces of feedback are mostly about the same issue, i.e. the number of available options at any point in the game. Ideally, you would take both points into account and ‘read between the lines’ instead of implementing either of the changes verbatim. However, most newcomers aren’t used to this. From personal experience, a lot of new designers would much rather follow the first player’s response and keep the game as is and add more content to try fix the current flaws. Fewer people will choose the latter option immediately, because it will probably require that a big part of the system be changed.
This is all very understandable, though. Generally, we tend to avoid the things that will cause us to lose progress, but when receiving that kind of feedback, one should really stop and think about what caused that kind of response in the first place. We might have an undiagnosed issue that will end up costing us a lot more time to fix down the line. Designers shouldn’t ignore feedback that highlights potentially big issues, just because they haven’t detected those issues yet. That’s the whole point of testing with different people: You get a chance to look at your system from a different perspective, and pick up things which you might not have otherwise.
Getting too attached to an idea
The designer likes an idea/mechanic/concept so much that they’re too afraid to change it or remove it. This can often lead to other parts of the design suffering because of it. Often coupled with ignoring/not acting on feedback which goes against that idea.
This mistake is one that plagued me the most personally back when I started designing. It’s one of those things that you are either completely unaware of, or are too reluctant to do the large changes needed in order to fix it. It took me a lot longer than it should have to acknowledge that things weren’t going the way they should. To my surprise, when I eventually did drop the idea and switched over to a new thing, it was great! When you realize you’re no longer chained to some specific idea, you can start working on things with a new sense of freedom and clarity.
While this ties into the instinct of not doing things that would counter progress, the sooner you become aware of this issue, the better. It’s one that’s resolved best through being reasonably self-critical and remembering that in game design no idea is ever truly dead. Especially ones scrapped for this reason. Once you’re experienced enough, you can actually turn this into a very useful tool by knowing when to let an idea ‘rest’ for a while. When you inevitably get back to it, you’ll have a different perspective on things and can make progress much faster than before.
This article is going to be a 2-parter, so stay tuned, since we have 4 more beginner blunders to look at in the next article.
Until then, you already know how it goes by now – song time!
This is InvertedVertex, signing off.