How I Learned This the Hard Way

A warning about the labels#

Before going further, a word about the labels "Unaware Beginner" and "Experienced Specialist".

I'm worried that some people will read them as a judgement: that the unaware beginner is inferior, deficient or stupid. Absolutely not. The unaware beginner is just as smart and capable as the experienced specialist. They simply haven't come across the crucial information, the knowledge of human needs and the experience accumulated from failures and successes. They haven't been lucky enough to find it yet. That is the only difference between the two.

I use the labels purely for convenience, as a quick way to refer back to two approaches. Nothing more, nothing less.

So when you talk with other people, NEVER say these labels out loud. They're meant only for this book. Said to a person, they come across as insults, judgements and analysis, and can leave someone feeling sad, hurt, angry, guilty or ashamed, thinking there's something wrong with them as a human being. That is the opposite of what the labels are for. Keep them inside this book, especially never as a judgement spoken to someone's face. You may receive a fist in the face if you try it.

Thank you.

How I came about this information#

In the beginning I wasn't aware of the common mistake. I repeated it constantly without realizing it, let alone knowing it was a mistake, or such a common one.

As I played games, modded them, created designs and later thought about how to make them better, something kept bothering me on a level I couldn't name. Whatever I played, there was often a feeling of disappointment, especially when I had read developer interviews or development diaries about what they wanted to achieve, and the final result was flawed or the opposite of what they intended. And whenever I created mods or designs, I felt dread, because I never knew for sure whether what I was making was going to be good. I had an intention and acted on it, but often what I finally made didn't satisfy even the most basic thing I'd hoped to achieve. Sure, it was made with care, with as many features and as much innovation as I could pour into it, but it still seemed like I hadn't arrived at what I was supposed to make. Something was off.

Back then, I thought the way to make a better game was to take the parts that made it good, remove the parts that were bad and upgrade it with more of the good parts, bigger and more prominent. If I were making a successor to an existing game, that would basically mean:

• Improved graphics, made more complicated and tedious to produce.
• Improved sound and music, made more expensive to produce.
• More content: a longer story, double the levels.
• More people, more money, and advertise the fuck out of it.
• More details, more polish, more filler for any empty space in the game.
• More advanced mechanics. More complexity.
• Popular features other games have, like leaderboards and multiplayer.
• Support for as many platforms, controllers and devices (VR!) as possible.
• Whatever the modern trends are.
• More impressive, more layered visual effects.
• More innovative/creative designs for characters, objects and worlds.
• A foolproof tutorial, to reach the largest possible audience.
• Sanitized controversial/offensive/provocative content, to appeal to bigger outlets.

So with all this, a better game is guaranteed? Hah. No. Absolutely not.

Back when I was an unaware beginner, all of these sounded like the best ideas ever. How could anyone go wrong with them? They're all popular, more advanced, more complex and more detailed than before. Where's the problem?

The problem is that everything on that list gets added for its own sake: because it sounds cool, it's popular, it's traditional ("this is how it's always been done"), it worked elsewhere, or someone asked for it. Not because the purpose of the project demanded it.

Many items on the list might not even be compatible with the game's purpose, and could ruin it outright, in the sense that the game fails to deliver what its creator was trying to achieve. Some items might happen to be good, but there's no reference, no certainty and no guarantee that they come anywhere close to the project's full potential, or even point in the direction it's supposed to go.

I've seen this in countless projects I've followed or played. Each time the mistake gets repeated, I feel sad, because I really wanted that developer to succeed and make a great game. So much effort and potential gets wasted, often bankrupting the team and burning people out so badly they can't make anything more. Nobody wins. Everyone loses.

I learned all this the hard way, through my own work and through playing what others made. The failures were what taught me. Each failure and disappointment piled up, repeating as a pattern, until I could finally see it.

And when I did see it, years of my work went down the toilet in an instant. Believe it or not, I still consider myself lucky. Some people, companies and communities keep going for decades without ever finding out what's going on, suffering for it more with every passing year, and some never find out at all. I would have preferred to have this information when I started. But hey, at least now you, the reader, won't have the same problem.

Why the mistake is so common#

The reason the common mistake happens to me and to countless other developers is no surprise. It's a flawed way to approach a project, but it's completely understandable where it comes from.

It's because the most convenient, most available, easiest, lowest-cost action a human being can take is to look at a problem at face value, without understanding the underlying causes of why it's really a problem. It's the natural thing anyone does when they don't have the information that would warn them where this approach fails.

Let me clarify "most convenient" and "easiest", because they could be misread as "humans are unwilling to do anything complicated". That's not what I mean. Many things factor into every decision a person makes. Sometimes people do something that looks really complicated and hard, but given everything they were weighing, it was actually the easiest, most convenient thing for them at that moment.

For example, it might seem simpler for me to just write "people do what is most convenient" and leave it at that. But I've had bad experiences in the past whenever I was too brief and got misunderstood, so I've factored that past pain into my decision today. That makes the extra effort of writing this clarification the "easier" thing for me to do. A lot of painful and pleasant experiences like that go into a decision, which ends up being the most convenient thing to do at that time.

So an unaware designer looks for the most obvious causes they can find and credits them for a project's success or blames them for its failure, even when those causes are only symptoms of a larger core problem that isn't as visible. It's the first thing available to them, so of course it's what they do, and what I did.

Avoiding it requires the knowledge to look for underlying causes. Anyone going into design without that support is guaranteed to make the mistake, unfortunately. That's why it's so common. We're limited to what we have access to, after all.

Thankfully, it is possible to avoid it, or at least to stop the cycle of repeating it: by studying this book, by having a mentor who knows this stuff, or through any other source made by people who went through the same pain, disappointment and failures and came to the same conclusion I did.