The following blog post, unless otherwise noted, was written by a member of Gamasutras community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.
I sincerely apologise for the terrible title of this article. I’m quite aware that this is 2014 and RPG tropes aren’t funny anymore, but you’ll just have to deal with it. It is a pretty accurate description of what I’m going to talk about, promise.
My dear friend Matheus Motta (@matheusrma) has recently been exploring Josh Kauffman’s method of “The First 20 Hours” to learn how to juggle, and it was cool to watch how successful it was for him. I’ll quickly butcher the whole thing here and summarize it for the purposes of this article as “focus on the most important aspects of what you are trying to do, learn how to spot your own mistakes, find a distraction-free environment and then practice for 20 hours”. This is the principle of factor sparsity - that is, 20% of what you do generates 80% your success, so just focus on that 20% and you will be able to perform at acceptable levels.
Josh Kaufman's book on the subject
I like to think that I’m pretty rad at learning stuff, and I won’t lie: I follow guidelines such as these all the time to learn stuff as fast as possible when they interest me. Anything from a guitar technique to sound design to quantum physics. But if you want to be REALLY good at something someday, world-class material, you’re gonna have to dive deeper.
So how do you fast-track your game design skills anyway? You copy what others have done that is proven and works, watching closely to reproduce the most important parts just right, and focus on learning how to create balanced systems and adding some catchy gimmick that doesn’t need to actually add any meaningful gameplay to your system.
This is actually how most people learn game design, and how a lot of professionals operate in the industry. Is there anything inherently wrong with this approach? Not really, but I’d like to advocate a harder, potentially more rewarding path to follow.
"Do not listen to people who are afraid of failure."
When I was starting out I was simply fascinated by game systems. They seemed to me like these beautiful, mysterious things - how can such wildly complex and seemingly chaotic player behaviour arise from just a few simple rules? How do you even go about choosing if something costs 3 or 6 resources? Or how many types of resources the game has?
This respect and awe for the craft led me to adopt a very radical approach that has been both a curse and a blessing ever since, and I will share this approach with you right here:
1. Design from the top to the bottom
Think about the nature of what you want to achieve - the experience you want to create for the player. Then establish the minimum amount of rough building blocks to get there. Avoid at all costs building something from the bottom-up, making it up as you go. Top-bottom design will strain your abilities to their limits and give you a fail-able goal (failure is super important).
2. Fuck GDDs
Just fuck them.
Wait, didn’t I just say that you need to have a solid plan before starting out? No, just read that again: you need to have a clear goal, but leave the details of how to get there fuzzy. That is actually what your job is - figuring out how to get there.
3. Ask the “5 Whys”
Also known as the annoying six-year-old designer: refuse to add or change anything to the game without asking “why” five times to get to the root of what you are doing.
“I’ve just got to add a dodge roll”. Why? “Because most games in this genre have it”. Why? “Because it feels awesome to do it”. Why? “Because there’s this cool animation and it’s fun to dodge attacks and leap out of the way”. Why? “Because trading the ability to attack and do other stuff for a short speed and defense boost is an interesting tactical choice”. Why? “Because this game’s combat has this fundamental conflict of trading space for damage as the enemies move towards you, so being able to trade damage for space would add a lot of interesting dynamics to the system”. Good, now we’re making progress.
Once you don’t have a GDD or a clueless suit telling you how to design your game, you have the blessing of having the game tell you what to do next. Games are rubbish at English, though, so they communicate with you through play. Your game needs to be played often, by you and as many people as possible, and you must watch it being played closely.
Familiar advice so far, but the difference is that you’re not going to write down if your game is cool or not because that is subjective and useless. You playtest with a clear goal that has been established in step 1. Remember that? Is that what you’re seeing in the playtest? If it is, congratulations, your job is done. If not, why? Back to step 1 and do it all over again. You will fail a potentially infinite amount of times, but you only need to succeed once. That’s why setting fail-able conditions is important.
5. Never Steal (Just Sometimes)
Refuse to do things just because “that’s the way it’s done”. Actually, go out of your way to do things differently, even when it’s painfully obvious that it’s a stupid idea. Do that for two reasons:
First, we humans suck at being able to tell how new stuff can be good when we have a perfectly adequate thing going on.
Second, and most importantly, you will learn a lot more by going off the beaten path. Honestly, most of the time you will hit a wall and say “hey, maybe that’s why everyone does it THAT way, uh?” and go do just that - but you’ll have learned much more.
6. Be A Stubborn Asshole
Stick to your guns even when it doesn’t seem like things are going to work out. If you have established a goal and a rough way of getting there that seems insane, and your colleagues are trying to convince you of dropping the idea, don’t listen to them. Pivot only when proven wrong by actual play - until then, your idea is the best thing to ever happen. Do not listen to people who are afraid of failure. Failure is super important.
glowing praise for my methods
I have been designing like this over the years, and it has paid off handsomely in the form of a collection of games which are fundamentally flawed and I absolutely loathe. The takeaway, however, is that I was able to learn game design in a deeper way by not focusing on succeeding, but on understanding what exactly it is that I am doing. With each passing day I feel more confident in my skills, and I’m able to approach design problems with more clarity and awareness of what I am doing and what I am trying to achieve. Hopefully my first really good game is coming? Soon?
So this approach won’t fast-track your success. It is much easier to design an objectively “good” game by ignoring this advice, but if your purpose is to learn and understand what you are doing with the goal of someday creating something truly great, I would wholeheartedly recommend it.
Until next week!