The Trials of Error (2/2)

The Trials of Error (2/2)

Pictured: 4 versions of the same card from one of my games, none of which was final.
A whole lot of valuable lessons learned, though.
(Disclaimer: Art’s not mine and is just used for prototype purposes)

To continue directly where we left off from Part 1, we resume the list of common beginner mistakes in no particular order:

Project scope getting out of control

The designer keeps adding things to the design constantly, or just keeps increasing the complexity of the design until the project becomes too big to manage for the designer’s current level of skill or available resources.

This issue is one that can be tied reasonably well to the ‘Getting too attached to an idea’ one mentioned in the previous article, as it can usually be a result of that. However, it can just arise on its own if the designer doesn’t plan things out well, or at all. To quote Hegemon:

A major error that most new designers do is not set out with a scope in mind in the first place, or over/underestimate their abilities to execute on a certain scale.

It’s not always about overestimating your capabilities or poor planning. Sometimes the only way to drive design forward is to increase the scope of things in order to either increase the design space itself, or to fix some issues that would be hard or impossible with only the tools given by the current implementation.

While this is an issue that can be turned into a design tool down the line, it is not something that should be used lightly. Whenever possible, define the bounds of your project well, and remind yourself of those bounds often. When you start going overboard, it quickly becomes a slippery slope of constantly increasing difficulty to manage the whole project, which can be a very big pain to resolve in later stages of design.

Not having a complexity budget

The designer increases the complexity of mechanics in the game to a point where both the design and the gameplay suffer because of it.

Now, this one might seem mostly identical to the previous issue at first glance, but not necessarily. Projects can go out of scope even when individual mechanics are kept simple, and even projects with well-defined, small scope can suffer a lot from overcomplicated gameplay mechanics.

The ‘budget’ mentioned here can be either implicit, or more well-defined if you make some kind of metric for it. You don’t necessarily need to have empirical metrics for complexity, but you do need to set a limit which you will adhere to. I’ve faced this issue a lot, and it’s not an easy thing to handle at times. You need to work in a way that constantly checks the overall complexity after implementing changes or adding things. While this might sound like you need to halt things after changing even a single number, it’s not really the case. You’re already subconsciously aware of the complexity of the games you play, and the only thing you need to keep track of is the limit you set.

A piece of advice that I want to give related to this issue is the concept of ‘patchwork fixes’. While a discussion regarding this can (and most likely will) take an entire article on its own, the concept is fairly simple:

Patchwork fixes are fixes for a game’s issues which are done by adding more rules or parameters rather than reworking the rules that cause those issues. This is analogous to putting a piece of wood over a pothole instead of filling up the hole itself. Over time, that patch can move or break, making you have to deal with the pothole again.

As far as increasing complexity goes, these things are dangerous. This is because they attempt to treat the symptoms of the issue rather than the cause. If there’s a problem with unit movement in a board game, adding an additional number parameter that can smooth things in most cases is a patchwork fix. Instead of considering the other possibilities, the most obvious is addressed in a way that seems to immediately fix things with little effort. However, this kind of design can have a house-of-cards effect down the line. If you keep adding rules/mechanics, when something inevitably breaks, you are going to have more and more possible factors that cause the new issues. This makes the game’s mechanics too tightly coupled and can absolutely shred the ability to modify or remove things without the whole project potentially needing ground-up reworks.

However, things aren’t always so clear-cut, and this doesn’t mean that you should refrain from adding rules to games. From experience, the fact that a fix is a patchwork only becomes obvious when it causes something to fail, or when the complexity of either design or gameplay is obviously affected negatively because of it. If you can, try to look at how you can modify the problematic mechanic instead of immediately adding more in order to try and fix the problem.

Trying to reinvent the wheel

The designer either consciously or unconsciously tries to create mechanics which have already been done before, without using the existing variations as reference.

This is a common issue that isn’t necessarily exclusive to beginners. What it boils down to is the designer having an idea which turns out to be a common solution for a problem. Unfortunately, the designer hasn’t done their research beforehand, and so ends up reinventing the wheel for that specific problem. Now, it doesn’t mean that it’s impossible to make good mechanics which are similar to existing things. The issue arises when the designer fails to/doesn’t want to learn from the existing implementations. This usually ends up with the ‘reinvented’ mechanic repeating the problems that the existing versions either still have, or have done away with by that point.

While it can be disheartening to learn that your mechanics aren’t as unique as you originally thought, it’s important to understand that it’s not necessarily a bad thing. If nothing else, you have the experience (and mistakes) of the others who worked on similar ideas at your disposal. You should take situations like this as opportunities to build upon the existing implementations, and ultimately make a better one, or at least one that better fits your purpose.

Next, we’ll look at the beginner mistake that’s both the opposite of this, and very connected to it at the same time:

Blindly copying other games

The designer uses mechanics from other games in their game, without understanding the full context around which these mechanics exist and the reasons they were made that way.

This one can cause a lot of annoyance if one’s unaware of it, or detects it after a lot of time has passed. This happens when the designer decides that a mechanic from another game will fit perfectly within the project they’re currently making, and implements it as-is, without making (m)any changes.

This rarely works as well as people expect, though. Problems appear because games are very finicky things. Unless you’re making the exact same game, even the slightest deviation can make mechanics work completely unexpectedly, or just not work at all.

The cause of this is lack of understanding, and the solution is proper research. Before you try to incorporate another game’s mechanics verbatim in your own game, try to understand why that mechanic is implemented the way it is. Look at the surrounding context, see how the mechanic interacts with the rest of the source game. Often, the specifics aren’t visible until you start digging a bit deeper. Mechanics are never designed in a vacuum, so you can’t expect them to transfer seamlessly between games.

Even if you manage to adapt a mechanic enough and make it work perfectly in your context, you still have to take into consideration the implications/consequences each new mechanic brings to the table. Instead of trying to match each feature and parameter of the source mechanic, a much better idea is to break it down first. Figure out its pros and cons, and take only the things you need from it. Make your own mechanic based on the source’s features that best fit your needs, rather than change the whole package to meet your requirements.

Mechanic soup

The designer adds more and more mechanics to the game, causing things to lose direction and become more difficult to develop and/or test.

I was responsible for doing this back when I first started with designing games, and to make it go away, I ended up doing a complete 180° with the way I approach designs. It’s tempting to want to add more cool stuff to your project, especially if said stuff is in the form of mechanics you already enjoy from other games. But, while the downsides of this might not be immediately apparent, it’s a problem that gets worse the further along the project you get.

Too many mechanics means that both development and testing get harder and harder, until things either break, or you start removing them. And if you need to remove mechanics for the game to work, it was probably a bad idea to add them in to begin with. Now, with most things in game design, it’s impossible to predict their behavior before playtesting, but just looking at the bigger picture and taking an educated guess can give more insight about a mechanic even before it’s added to the game proper.

I’ve noticed there are 2 major approaches to designing games, as far as complexity is concerned:

  1. Slow and steady – adding new rules/mechanics only when all of the current ones are thoroughly tested and polished. This is the approach I use, and I feel like it’s best for simpler games, where the core of the game takes up most of the mechanical space.
  2. Fast and furious – adding a bunch of things in quick succession, before cutting the ones that have negative impact (or no impact at all) on the design itself. For games that have a larger pool of mechanics, this method can improve iteration speed, because the changes (and testing) are done in batches, so that a lot of ideas are covered at once. This, however, comes with the downside of harder-to-manage testing, both with the setup and with properly evaluating the results.

The trick with both approaches is to evaluate how a mechanic you want to add will affect the direction and scope of the game before you commit any changes. Even perfectly-functioning systems can just crash and burn if they’re disjointed (I’ve had this exact thing happen to me because of the reasons stated here).

Well, here we are. I hope that you can find some use for the info in this 2-part article. Like I said at the beginning, you can’t be 100% sure you won’t make mistakes. But, with things like this, knowing is half the battle. After all, acknowledging you’re making a mistake is often the hardest part of fixing it.

And that about wraps it up for the beginner-friendly series for now. The next articles will cover some more complex concepts, but the complexity comes from being familiar enough with the situations rather than being difficult to understand. I have one more beginner-“friendly” Sidequest article planned for the very near future, talking about some harsh truths in game design, but since it’s a Sidequest thing, it will be a lot less formal than this.

Until then, ♪♫:

This is InvertedVertex, signing off.

Tags: , ,

One Response

  1. […] 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. […]

Leave a Reply

Your email address will not be published. Required fields are marked *