Final Result vs Root Cause

What the common mistake is#

When it comes to game design, the easiest mistake to make is to approach a project with the mindset of creating the final result, instead of making that final result happen as a side effect of a root cause.

To explain it a different way: the common mistake is to take that initial vision/inspiration/fantasy/dream/wish/idea and create it directly. To imitate/mimic it exactly as it is, instead of understanding the reasons behind it and using that understanding to create something that will become the proper fulfillment of that vision.

Why is that a mistake? Because the vision is not guaranteed to bring fulfillment. It's merely a guess. It's only one of infinite possible strategies for fulfilling the root causes behind it, and it may well be a flawed one. Creating a project this way is blind.

With only the final result in mind, nothing tells you whether a given design decision serves the root cause behind your idea. You're far more likely to make mistakes or bad design decisions that actually make the project worse, or that turn out to be a useless waste of time.

The root cause, on the other hand, the understanding of the real reasons behind the vision, gives you a real guarantee that the project will fulfill what the vision was supposed to fulfill. Creating a project this way is confident, clear and effective.

That root cause is fundamental human needs. I'll explain them in detail in Understanding Human Beings. For now, the short version: video games and interactive tools are just some of infinitely many strategies to meet those needs. Some strategies are poor, others are more effective, and the ones that connect with the root causes are the most effective of all.

When you clearly understand the root cause, you have complete information to make the best choice at every single design decision in your project. You'll know exactly what's needed and what isn't, which lets you work effectively and avoid wasting time, resources and effort on things that would have a bad or useless effect. In other words, understanding the root cause gives you mastery over any project.

A game example#

Let's say you were inspired by a game/movie/music/comic/book/nature/event/experience or anything similar, and an idea came to you that involves making a game.

The common mistake is to recreate the vision directly without first finding out the root causes behind it. If you saw a movie about exploring alien worlds, the wrong thing to do would be to build alien worlds and gameplay systems so you can repeat for yourself what was done in the movie.

Instead, look at the root causes of the vision. How did it make you feel? Using those feelings, you can pinpoint what the root causes are and see what the real purpose of the project is. (The exact process is in From Inspiration to Purpose.) The root cause can change your design decisions a lot. Here's what it might turn out to be, using the alien world example:

• Challenge. To improve yourself as a person, to grow spiritually, intellectually or physically. Survive on the hazardous alien planet using your skill and limited resources.
• Empowerment. To feel capable, confident and free. Conquer and reshape the alien planet at your will with godlike power.
• Variety. To discover and explore something you've never been exposed to, to see something new. The planet is full of mysteries and cool random things to find and document.
• Beauty and satisfaction. To get joy from seeing, hearing or doing something that pleases your senses. Fly through the planet, interact with it, take in beautiful vistas and curious details, and enjoy simply being there.

These are only a few of the possible root causes. Whichever one it is (or several of them), it can drastically change what every part of the game looks like: the genre, the aesthetic style, the mechanics, the UI design, the marketing, the controls, the narrative, the context, the theme. Four games about the same alien planet, and they'd barely resemble each other.

If you don't know the root cause, there's a high risk you'll accidentally make design decisions that conflict with the purpose behind your vision, or add systems and content that don't enrich the experience, or make it worse, confused and messy. And here's the consequence that people tend to underestimate: you usually won't find out until the game is built. By then the wasted months or years are already spent.

If you do know the root cause, you can avoid these mistakes and always have a clear compass that points toward the best design decision for any part of the game, at any time. No confusion, no wasted time. A direct, efficient path that makes sure your vision actually satisfies you, instead of blindly missing the point.

An interactive tool example#

The same thing applies to a real-life issue. Let's say something inspired or troubled you, and an idea came to you for an interactive tool to address it.

Again, the common mistake is to build the tool and hand it to people without connecting with the root cause first. If you're making a tool to raise awareness of climate change, or to teach math, a language, cooperation or some skill, the wrong way to do it is to just teach it directly.

Why is that wrong? Because the user has no context, no reference experience of why it matters or how it would make their life more wonderful. If the tool only teaches without explaining why, the user can't find the motivation to care. If it explains why and teaches it, but doesn't show how it would make the user's own life more wonderful, it leaves them confused and concerned: they know it's important, but they can't connect with it. They have nothing to compare it with.

Here's the thing to notice. The reason you're working on the project at all is exactly that context, that reference experience. You needed it to start. It's the very thing that drives you and makes you care about putting effort into the project. Because of it, you can see why the project needs to be made and shared.

The user of your tool needs that same context to care about it as much as you do. It's essential for everyone involved, not just the developer, so ignoring it or forgetting it would be a dire mistake.

So look at the root cause of the tool and reveal that reference experience, then use it as the starting point and main driving force of the tool. Instead of directly teaching/raising awareness/motivating, give the user the same experience that made you care, and integrate the teaching into it. Then show clearly how the tool concretely makes the user's life better.

A couple of quick examples:

• Climate change awareness. Show what frightened you, how it made you feel and how your life would be better if people did what you're asking them to do. Then, within the context of that experience, show them what to do and clearly demonstrate why you think it works.
• Teaching math. Show what inspired you, how it made you feel and how math lets you make life more wonderful. Show how life would be better for you if other people knew math and used it. Then teach math in the context of what inspired you, so the user sees concretely why it works and how to use it.
• Teaching cooperation. Share the experience that troubled you, how it made you feel and how life would be better if people cooperated. Teach the tools for cooperating, using your own experience as the setting, since a real example shows how it applies in real life. You can expand to other settings later, but not before the personal experience, because that's the strongest and clearest reference you have.
• Teaching a skill or technique. Same process again: your reference, your feelings, how it would make life wonderful for you. Then teach the skill within that context, and finish by demonstrating it in action in a real situation. The user will see its effectiveness and value on their own.

Essentially, your outspiration becomes their inspiration. You breathe out, others breathe in what you breathed out. That's what inspiration is.

You may have noticed that in these examples I keep talking about how to make life wonderful for you, not for others. If that sounds selfish to you, you'll soon find out that "selfish" isn't what's going on. Your needs are a gift. Understanding Human Beings explains why.

In short#

So that's that. The common mistake is trying to solve a problem on the surface without addressing its hidden root causes. There's a well-known saying, usually credited to Einstein, that we can't solve our problems with the same thinking we used when we created them. This is exactly that.

Next I'll show how the mistake plays out in real projects, using my own experiences.