Growing as a Designer

I promised in the foreword that my own story would be here, for anyone who picked up this book without a burning reason of their own yet. Here it is: how I started, how I grew, and what I'd tell anyone starting now.

A big red box#

It started with a game called Soldat, a 2D action game about soldiers with modern guns blasting each other for fun. It had an active online community making "skins": mods that replaced the game's graphics and sounds, giving it a whole new theme and feel. People shared them on the game's forums, where others downloaded them, played them and left feedback.

I'd been playing the game a lot, and the more I played, the more I wanted variety and novelty, so I started trying mods. At first they made the game feel fresh. Then, as I played them more, I started noticing small things I wished were different, things the mod authors didn't want to change. So I'd have to change them myself.

Luckily, the game's files weren't hidden in any way. I could open any folder and look inside like a photo album, open the images in an image editor, the text in a text editor, the sounds in an audio editor. With a few tutorials, I could change the game's graphics directly. It didn't take any advanced knowledge.

My very first change was something silly: I made the rocket launcher's projectile a big red rectangle. Imagine someone firing from off-screen, sending a cartoonish giant red exploding box toward the enemy base. It was completely impractical, looked dumb, and would get annoying in serious play. But it was proof that I actually had the power to change something in a game myself. Before that, I couldn't have dreamed of it. And it was funny, because a moment like that would never have happened in the original game.

That small success was all the motivation I needed. I opened someone else's futuristic mod and started adding more glowing energy lights to its guns, pixel by pixel. Then I did it for all the guns. Then I drew entire guns myself, mostly by trial and error, with the occasional pixel art tutorial when I got stuck. Then sounds and text. Sci-fi and mecha anime were always my favorite things, so eventually I made a full mod that brought everything I loved into a game I loved, and it was easy to stay motivated, because it was something I personally cared about and benefited from.

My work wasn't impressive compared to trained artists. But it made me happy, because I'd made something myself, in my own style, that only I could make for me. That's how most creative journeys start, I think. Just playing around, regardless of anyone's opinions, standards or comparisons. Admiring that you, too, can be an active participant and not only a spectator.

Cortex Command#

In Soldat I could only change how things looked. Then I found Cortex Command, a physics-driven action game where every pixel could be destroyed, and which had a modding system that let me create entirely new characters, vehicles, mechanics, features and systems. You could practically make whole new games inside it.

My first mod there was a tiny change to someone else's mod: they'd made Elmo from Sesame Street into a playable character, and I made him weigh 9,999,999 kg, just for laughs. In Cortex Command, characters arrive from space in rockets that try to land gently, and the rockets are affected by the mass of their cargo. So when I ordered my super-heavy Elmo, the poor rocket came screaming down from orbit at a terrifying speed, punched through the entire terrain to the bottom of the level, and exploded violently. It was the most hilarious thing I'd seen. Poor Elmo didn't survive either.

From there I kept learning by taking other mods apart, changing values, and building more and more "cool stuff": characters, vehicles, guns, items and objects of every kind, many of them trying to do things the game had never done before.

Following the norms without noticing#

Then a trend took over the community: "faction mods", each a themed army of characters, weapons, vehicles and structures, so players could pick one faction to fight as and another to fight against. That made modders think about balance for the first time.

And here's where I made the common mistake without knowing it. I matched my numbers to the original content's, without asking why the original had those numbers. The official game had a "survive 20 minutes against endless enemies" mission, so I made one for my mod too, without asking whether it was any good. I copied the existing lineup of archetypes: pistol, SMG, shotgun, assault rifle, sniper, rocket launcher, grenade. And somehow the pressure to fit in made me suppress all the wild creativity of my earlier experimental mods. They'd been a free playground. The faction mods felt like a place where anything different was forbidden.

Most of the community did the same. New faction mods were often cookie-cutter copies with superficial differences. Pistol, SMG, shotgun, assault rifle, sniper, rocket launcher, grenade... over and over. Meanwhile, people kept releasing revolutionary one-off mods (swimmable water with real buoyancy, whole new ways of building bunkers) that proved better ideas were possible, and they almost never caught on.

I mention this because it's exactly what I later saw across the games industry, in big studios and small ones: one-off experimental games that stay in their bubble, and "proper" games that keep repeating themselves, when a shift in mindset could have made them vastly better without costing more to build. It isn't a lack of talent. Both sides have plenty. It's minds imprisoned by the status quo.

Invited to the official team#

One day the game's developer invited me and a few other prolific modders to make official content. The instructions were simple: take the lead artist's sprite sheets, and turn them into playable objects. There was little direction beyond that, so we built everything by gut feeling. You already know how that went from Chapter 21: fifty guns with three-kilogram bullets, made without knowing the standards the game was supposed to follow.

When I ran out of sprite sheets, I had spare time, and for the first time I sat down and really played the game as a whole. That's when my capacity for design began to wake up. I saw levels that ignored the game's destructible terrain and forced the player along scripted paths. Missions that spawned endless enemies in a game that could only handle a handful before it fell apart. Effects built to look impressive alone that made real battles lag. A skirmish mode that asked a human to micromanage fragile soldiers against an AI that could control everything at once (Chapter 20). And the crab bomb.

I also realized the original game hadn't been designed by some genius according to a grand plan. The developers were designing it as they built it, like building a house and drawing the blueprint afterwards.

Then came the epiphany that everything depends on what's under it, and the dependency chain, and foundations before content. And then, zooming out even further: the marketing, the store page, the community, the whole experience around the game. From there, everything in this book followed, along with Nonviolent Communication, which gave me the understanding of human beings that tied it all together.

Most of the work I did for Cortex Command is gone now. Updates broke it, balance kept moving, and the game's future became uncertain. Sometimes it doesn't matter how hard you work, if the circumstances turn bad. It was a learning experience, and I enjoyed it at the time. But there are better ways to learn, ways that save time and leave you with creations that are still valuable years later. That's why this book exists.

How to start#

If you've never made anything#

Look for an opportunity like the one I found: something easy, quick and instantly visible, in something you already love. Make mods or skins for a game you play, or pick up the easiest game engine you can find and follow its tutorials to make silly experiments. Don't worry about deadlines or goals. Make as big a mess as you can, and have fun making something absurd. Share it where it's welcome. If people enjoy it, their gratitude and feedback will give you the confidence to keep going.

Know the difference between mods and games, though. Modding gives you a ready framework, an existing audience, and existing design you can lean on. But you're limited to what the game allows, you usually can't sell your work, and players need the original game to play it. Making your own game frees you from all that, and in exchange you have to build all the foundations, do all the design, and find your own audience. Both are good ways to start. Just know which trade-off you're making.

If you already have a vision#

If you've already been creative elsewhere and you come to game development with a clear dream, you don't need to mess around. Start on your dream right away, in a minimum viable form (Chapter 28).

First, find the right engine. Try several, and compare them on what matters to you: what's comfortable, easy to learn, suited to your project, within your resources and skill, and trustworthy for the long haul. Not which one looks strongest or most advanced. Go where the fence is lowest. And remember that more complex and detailed assets mean more work, slower work. Choose your direction wisely.

Then commit to it, build the barebones version of your dream, and grow it as your knowledge grows.

It may be lonely at first#

The early stages can be lonely and thankless. Few people will join an unproven project (Chapter 29). Don't be discouraged. If you pull it off, you'll have the power to create interactive experiences far more powerful than passive media, and a craft that gets easier and more rewarding the further you go. Once you've mastered a platform that fits you, what you can make with it can feel like a godlike power.

What mastery takes#

To become a master game designer, you need a lot of things: several kinds of knowledge, a library of personal experiences, and patience. The knowledge is the subject of this whole book: human beings and purpose (Part II), technology and the human body (Chapter 20), communication and business (Chapters 29 and 30), and keeping your projects organized (Chapter 28). Here are the other two.

A library of experiences#

This can't really be learned from a book or taught. It comes from exposing yourself to many different games, films, shows, anime, events and experiences, and asking questions while you do:

• What mechanics, features and systems does this have?
• What context, theme or purpose does it have? What kind of content?
• How does it feel to play in the short term, and in the long term?
• Does it have potential, or is it a dead end?
• Is it good or bad? Why?
• If I could change something about it, what would it be?

Be inspired, be disappointed, be curious about how things work and how they were made. All of it accumulates into a library inside you, which becomes your intuition. Eventually you'll come up with ideas quickly, as if by magic, and see opportunities clearly where others stumble. It's a giant mental toolbox to borrow from, combine, remix and replant in new settings.

Observe people too, with curiosity: around you, and in streams, videos, podcasts, books and conversations. Why did they do that? Why did they say that? What's their story? It builds empathy, which is the designer's most important instrument.

On the outside, much of this looks like procrastination: countless hours watching videos and browsing forums. It isn't. That's how knowledge accumulates, gets digested and organizes itself in your head, a little at a time.

And if an idea is good, take it and give it new life. All art is a remix. The difference between a thief and an artist is that the thief takes from one place and changes nothing, while the artist takes from a hundred places and combines them into something that goes beyond all of them.

Patience, and health#

Making a game is a bit like building a satellite. It's fragile, small mistakes can become very costly later, and once it's launched, it's often easier to build a new one than to bring the old one down for repairs. So be careful and methodical: test your theories, simulate them in your head, experiment safely before committing.

Nothing in design is automatic. Every detail can turn out to be its own rabbit hole, and some of those holes you have to go all the way through, because the system you need depends on them. Days become weeks, weeks become months, even while you work at full speed. Patience, endurance and focus matter more than you can imagine. A game is an edible elephant: you can eat it, but only in small pieces, over time. A tiny step every day, advancing slowly but surely.

And take care of yourself. Your health is as important as the work. If you burn out or get sick, the project fails anyway. Be healthy and strong.

Trends, and the five stages of grief#

A designer needs to keep up with new technology and conventions, to use new possibilities and replace old systems with better ones. But be careful with "adapting to market trends". Players, critics and experts are limited to the information they currently have. They often don't know what they want until they get it, so following what they ask for leads to the same mistakes everyone else is making. Popular isn't the same as smart, good or sustainable.

If you discover something truly better, people won't see its value until they can try it. And even then, expect controversy. People often go through something like the five stages of grief when a new idea shakes their world: denial, anger, bargaining, depression and, finally, acceptance. During the anger, some will attack what you made, unprovoked. Persevere. Keep believing in what you're doing. If you don't do it, someone else eventually will.

Always design from the purpose of the project, never from what's trending. Nothing gets innovated otherwise.

Learning and teaching game design#

Can you learn game design at school? Honestly, a school is unlikely to teach you this. Schools are constrained in how they work, and game design is so abstract that it's hard to teach and rarely taught well. The industry also values finished work far more than diplomas. If you go to school, consider studying something tangible that you can show (code, art, audio, music, technology) and learn game design yourself, alongside it. And start building your dream now, in whatever reduced form you can, today.

I once saw a video saying nobody knows how to teach game design in schools, so here's a general outline of how I'd do it. The specifics are easy to work out from the rest of this book.

1. Inspire the students first. For the first few months, focus only on this. Give them a library of games, films, books, comics, videos and documentaries, and let them browse it freely, and keep coming back to it. This is how the library of experiences gets started.
2. Be honest about what's available. How much time they have, what tools and resources they can use, and what will be expected of them after school.
3. Let each student say what they want to pursue. Their own inspiration, their own purpose.
4. Help them achieve it. Support and guidance, keeping everything in step 2 relevant. Teach the method, not the final result. A teacher who only shows finished games teaches students to copy finished games. A teacher who shows how to get from an inspiration to a design teaches them to make their own.

The same applies if you ever explain this book's ideas to someone else. Don't hand them conclusions. Show them the root cause, and let them find the result. That's the whole book in one sentence.