In the world of game development, assumptions can subtly creep into the process and unconsciously play a significant role in shaping a game's design and determining its degree of success. We invite you to make a game with us and explore five key assumptions that influence its development. Together, we’ll aim to understand how to recognize and mitigate these assumptions to be better equipped to make amazing games in the future.
Making a game - “Stick Two”
So, let’s start by making a game! It's going to be called Stick Two (clearly it's a sequel). We know Stick One worked well, so if it worked before, it will work again.
So, in Stick Two, what do you do? You have a little stick that you control, and as it runs it can jump over enemies that come towards you. Because this is Stick Two, we have to add something new, something exciting, and that something will be red hearts. Now, everybody knows what red hearts mean, so we're just going to stick those into the upper-left corner, and we know exactly what they're going to do.
At this point we've got this nice prototype with new mechanics in it, so we distribute this build among our team, and we play it ourselves. We realize that the game is way too easy, so we go back and add a bunch of new enemies and some more complicated jumps.
Now that it’s no longer too easy, we need something else, another interesting game mechanic. Well, we all like roguelikes, right? So we’re going to add a roguelike mechanic to the game. We’ll add boxes that you can open and get various power-ups as you progress.
Awesome, now teams need their salaries, so we’re going to be adding video ads that trigger when the player taps on the hearts. We still all know what hearts mean, so we know exactly what this does as well. Lastly, we’re going to add a subscription model and lock the main features because players will buy anything.
Amazing. This is Stick Two. Ship it!
As some of you might have realized throughout that brief description of the making of Stick Two, certain things can occur while making a game, and we call those little things assumptions. And a couple of the assumptions that we mentioned aren't just minor little tidbits. No. Assumptions can affect the development of a game to the point that it goes from a completely normal platformer to whatever Stick Two turned out to be (a mess, basically).
Understanding assumptions
Now, before we continue, let’s look at the official definition of what an assumption is so that we understand each other moving forward. So, according to the Cambridge Dictionary, an assumption is “a belief or supposition that something is true, even if there is no conclusive evidence to prove it.” Now, for all of those who do not read the Cambridge Dictionary, we could also describe it like this: “We believe something is true, it influences what we do, and we don’t give it much thought to how accurate it is.”
During that little story, there were a couple of assumptions that popped up. Did you catch them?
There were five, and here they are:
It worked before, and it will work again
Everybody knows what red hearts mean
The game is too simple
We all like roguelikes
Players are gullible
Assumption 1: It worked before, and it will work again
This one is fairly simple. The assumption is that old ways are still the best ways of doing things. Now, don’t get this wrong, using heuristics - something that is tried and tested, and that you know has worked in the past - is a good thing to do.
The only problem that can occur here is that you don’t think about it enough. Firstly, things might have changed since you (or even someone else) released a successful game or included a successful game mechanic. Secondly, maybe you didn’t fully understand why something worked in the first place.
Now, consider this scenario: you had a popular match-3 butterfly game. But for the next one, you thought, "Let's switch it up. Match-3 but with dinosaurs eating dinosaurs!". After making a successful match-3 game with butterflies, we assume we can make a similar match-3 game, but with dinosaurs. The dinosaur game flops, because we did not understand that the main reason for the success of the first game was the butterflies and not the match-3 mechanic. This kind of assumption can lead to poor decisions when taking a feature from one type of game and putting it in another, and when creating sequels.
Assumption 2: Everybody knows what red hearts mean
Everybody knows what red hearts mean, right? Of course, they do. This is the assumption that players know a certain symbol, a certain language, or certain things that are used to represent something in the game. This, we assure you, is not the case. Your target audience might see a heart and think this is a cookie that needs to be eaten. This can be problematic, especially for games with a global audience, as some symbols may have completely different meanings in different cultures.
Why is this a problem? Well, because it makes your game harder for the player to understand. And the harder your game is to understand, the less people are going to enjoy it and play it. It's as simple as that. Casual games are particularly susceptible to such assumptions, which often result in player frustration and lead to churning.
Assumption 3: The game is too simple
So, the game is too simple. Now, while the previous assumption was focused on player knowledge, this one is about players’ skills. Oftentimes, our teams start playing these games forgetting that they are the people making the game. They already know everything about it. The artists know exactly what certain assets do because they made them. Developers know exactly what button to press because they understand the whole logic behind it.
But at the time when you're making this game, we recommend you keep in mind that you are essentially the pinnacle of skill, which means you're probably overshooting the complexity and difficulty of the game. For us, this usually happens when balancing the game for the team's excitement, and systems and new interesting things keep getting added to the game; stuff that keeps the game interesting for people who’ve been working on it for months, but that may diminish its value for players.
Assumption 4: We all like roguelikes
This one usually splits the room. Some people say, “Yes, of course, we all like roguelikes”, while others say, “What the heck is a roguelike?”. Essentially, a roguelike mechanic is a game type, where you control a character that gets upgraded and gets progressively stronger as you play through a single run of gameplay. Once you die, those upgrades are lost, and the player must begin anew, but usually with a bit more power than last time.
The assumption that everyone likes a game genre or game mechanic just because it’s popular, or because you like it, can give you tunnel vision and limit your ideas.
Let’s say you’re making a realistic football management simulation and, because you really like roguelike mechanics, you decide to add a mechanic where players have to choose one player from a randomly generated selection of three (in the same way a roguelike might grant you a choice of a new magic item or skill). Keep in mind this is a game that is usually targeted at players who love spreadsheets, realism, and having control over data and decisions.
Features that mismatch with the overall game vision can seriously derail the direction of the whole project
Assumption 5: Players are gullible
The last assumption assumes that players will not feel cheated no matter how your game’s monetization features are. It essentially results in disrespecting the players who make microtransactions in your game.
Some companies do this more than others, and while it may seem like a good short-term approach, it pretty much guarantees long-term failure due to the loss of your players’ trust and respect.
TL;DR: Addressing assumptions
To avoid succumbing to these assumptions, it's crucial to recognize when and to understand how they might influence your decisions. Here are some practical steps you can take to help mitigate these:
1. Do your market research. Ensure your decisions are informed by up-to-date market research, not just past successes.
2. Set a strong product vision. Define a clear and concise product vision that guides your decision-making and aligns the whole team's efforts.
3. Make sure you get good feedback. Encourage open and honest feedback from your team and from players in order to identify potential biases in your game's design. A vital skill for any game designer.
4. Effectively use research. When conducting user research, set clear goals and observe players' natural behavior before asking for their opinions. It’s important here to let players play, give them the time to play the game and observe them while they are doing so, as your observations will tell you just as much as what the players tell you afterward.
5. Understand your audience. Take the time to understand your audience's preferences, behaviors, and needs. If you don’t, you will miss your mark.
6. Reflect on your personal biases. Continuously reflect on your own biases and how they may influence your decisions. Remain open to different perspectives.
Throughout the journey of game development, assumptions can be subtle yet powerful forces that shape a game's outcome. By recognizing and addressing these assumptions, game developers can create more engaging, inclusive, and successful games.
One last thing remains now:
Which of your assumptions have you noticed, and how will you find the rest?
