Written by Tanya X. Short, the Captain of Kitfox Games, a small independent games studio in Montreal currently working on Boyfriend Dungeon (on which she is the lead designer), Lucifer Within Us and publishing Six Ages, Fit For a King, and Dwarf Fortress.

Here are a few thoughts and observations on how to grow as a designer, whether you’re aspiring or senior. I’ve been a salaried game designer for over 10 years, and I’ve found these pieces of advice useful at various points in my trajectory.

1–3: What to Read

Less experienced designers often ask for book recommendations. My first answer is “Have you made stuff?”

You’ve probably already read enough blog articles or watched GDC talks, so if you haven’t yet, step 1: go make some stuff. And yes, yes, maybe you already have a full-time job making stuff for a company — but make your own stuff.

It doesn’t always have to be finished games. Test out ideas. In an engine.

Then, Step 2: it’ll be helpful to think about the theories, after you made or while making stuff. Here’s a few books that are pretty good, but you can also watch a bunch of GDC talks for free on YouTube.

But the important thing overall is to alternate between the practice/craft of making stuff, and absorbing some new perspectives and best practices. By ‘engine’ I mean whatever. Twine, Frostbite, modding, cardboard bits, who cares. Make stuff.

Kitfox members have made many small, free jam games which you can find on our itch.io page!

Once that gets comfortable, Step 3: actually finish something. Even if it’s non-commercial, make something until it’s “done”. Concepting and early production are different design skills than finaling/shipping. The whole process will help your growth.

I find alternating between creating and reading/discussing the best rhythm. One without the other becomes stagnant.

4–6: Harvesting Ideas

Aspiring designers usually play lots of games. But playing by itself isn’t enough. Step 4: the basic questions to always ask yourself when you play:

It can be useful to reverse-engineer some systems or features and understand their design for yourself. For example, if you enjoy Spelunky, really STUDY its wiki for its damage numbers, spawn rates, etc. Make a spreadsheet or five. What would happen to the ~feeling~ if some of those numbers changed?

Step 5: lose your disdain for genres you don’t naturally enjoy. Ideally you’d go play them and understand them deeply to grow, but at LEAST understand it’s your personal taste, and not the Gold Standard, whatever it is.

In fact, exploring “unfun” genres may teach you something you can carry back to your design nest. You don’t have to play and master all games, but getting your feet wet in unfamiliar territory CAN be helpful in widening your vocabulary.

Bored by combat? Cool, me too mostly, but there’s a LOT of careful content AND systems craftsmanship there to learn from. Don’t love heavy UI? Puzzles? Platformers? Fine. You don’t have to make them. But you CAN learn stuff from them that you won’t find in your stomping grounds.

Speaking of stomping grounds, Step 6: get a hobby or 2 outside of making/playing games, and commit to them. Cooking. Sports. Travel. Woodcarving. Music. Film. Whatever. Designers are problem-solvers, and you can only be so good at problem-solving if your reference-points are all insular.

Will woodcarving give you a solution to that progression problem on level 3? Nope. But your brain will be better at lateral and cross-system thinking when it has more experiences to draw from.

Step 7: Focus on the Player Experience

Get into the habit of writing down your game design goal before you start to implement. But AVOID the temptation to write the nitty-gritty feature implementation details. Focus on the player experience —i.e. the intended emotional journey. Refer to this often while making.

You might enjoy writing endlessly detailed features or lists of content or spreadsheets of system/item ideas. It’s fun. But it’s also a trap, because it’s the cart before the horse. The player experience needs to direct what kinds of attacks each enemy has or whatever, not the other way around.

That “player experience” or design goals document will also help prevent you from stunting your growth in the most common way, which is to simply replicate other games.

Yes, yes, I told you to reverse-engineer a game. But that should help you understand how a player experience is achieved, NOT how to make a game. Beware basing your game design solely on someone else’s work (or accepting a genre label) before defining those player experience goals.

For example, if you want to make “a 2d game that teaches the player timing-skill mastery”, it’s possible you will independently re-invent Mario Bros. But it’s also possible you will invent something new and fresh. Whereas if you start out saying “I’m making a platformer” (therefore the camera must do this & the character must jump like this) that’s probably all you CAN make.

Beware inheriting another game’s design problems & solutions without even knowing what they were trying to achieve.

Step 8: Get comfortable with criticism. Don’t put up with harassment but do grow a thick skin, when it comes to people not enjoying your design, or not having the experience you intended. You can’t grow as a designer if you can’t listen to players. Even when it’s unpleasant.

This might be controversial for the more artistic among us, but I don’t believe a designer can grow in a vacuum… maybe fine artists can in other fields, maybe not, but in games, the player is your co-author, even more so than other mediums.

Usually this belief in player-authorship is opposed when it’s conflated with commercialism, but I’m not saying the designer must bow to the market. What I am saying that if you can’t honestly evaluate and iterate on the player experience, somehow, your craft will be stunted.

The more experience you gain, the less dependent on playtests you can become! You’ll be able to imagine and iterate on a player experience more and more efficiently. But if you’re dreaming of someday ignoring what players experience in your game, what you’re dreaming about isn’t game design.

We’re building places for other humans to be, like architecture. Even the most inspired architect’s ability to make houses for other humans would be limited if they didn’t remind themselves what it feels like to live, breathe, eat, etc, as a human in a space. Same for games.

Step 9: Get comfortable with ambiguity. Designers have to accept that you may never know whether what you did was the right solution. Game design is an art, and no amount of obsession or process can turn it into pure science. There will usually be no ‘clearly’ right answer or perfect solution to a design problem. There are common solutions to common problems, but you’ll find thornier, messier problems and solutions, the more you experiment in your designs.

Most senior/lead game designers I know score extremely high on the openness to experience in the OCEAN personality test, and I think this required comfort with ambiguity is why (in addition to needing lateral thinking, and that being improved by new experiences).

Read more about the OCEAN Personality Test on Wikipedia, to better-understand yourself and your players.

So if you feel comforted by the idea of ‘right’ and ‘wrong’ answers, design may not ultimately be your most comfortable field.

Steps 10 & 11: The End Game

As a middling-experienced designer, reading and talks will stop being actively helpful and be best-used as occasional reference material and reminders. You may feel like you’re floundering in guess-and-check. Unfortunately, blanket design statements and theories can only take you so far.

Experienced designers sometimes take step 10: form retreats or think-tanks together, and even pay for the privilege. Each game is its own unique design problem to solve, after all. If you’re physically isolated, join or create some online communities. There are other designers out there hungry for deeper problem-solving.

Step 11: Know thyself. Most game designers tend naturally/instinctively towards either content (characters, levels, world) or systems (rules, structure, tools). It’s best not to fear or avoid the one that doesn’t come as easily, but it’s also OK to focus on what brings you more pleasure.

Like all binaries, this divide isn’t hard. Lots of people enjoy both, and lots of game design (AI, procedural generation, core gameplay) tends to be both or neither. But you don’t have to apologize for enjoying spreadsheets, or dialogue trees, or whatever. Both mindsets are needed for good games.

Figure out where you’re comfortable and where you aren’t, and connect or collaborate with other designers accordingly. It’s up to you if you round yourself out or specialize more, but both paths of growth will be faster if you are self-aware.

That’s it for now! Go make stuff and read stuff and make stuff some more. Best of luck, designer-friends!