So, you want to make a game…
A brave new world
Welcome to game design! Whether you’re completely new to the craft, or an already-experienced designer/developer, it never hurts to take a look at the basics and see things from a new perspective. In this post, I will attempt to shed some light on the process of starting a new game, as well as what resources one could need for doing so, and some challenges that might be encountered along the way.
To say that game design is a massive discipline wold be an understatement. As many other creative hobbies/professions, it is absolutely humongous in scope, and keeps getting bigger as time goes on. Game design is interdisciplinary by its very nature. It fuses together psychology, logic, visual art, game theory (which is a branch of maths, for those unfamiliar with it), and can even borrow from things like software development, all in the pursuit of creating better experiences for both players and designers.
What are the prerequisites for design, though? The answer is: nothing much, really. As with any creative process, everything starts with an idea – the core building block of any creative work. We can glamorize the design process all we want, and entire libraries of books have been written about the nature of creativity and ideas, but the reality is much simpler: You get an idea, and then, through a lot of work and iterations, you (hopefully) end up with something that can be considered a finished game.
Enough formalities, where do I start?
Game design is one of those things where there really can’t be a grand unified process, or a single ‘right way’ to do things. This isn’t really a guide, but instead it’s more a collection of advice that I consider important for newcomers to the discipline.
I will assume that people reading this have some sort of idea for a game, regardless of the scope. Whether it’s as simple as homebrewing some rules changes for a game you’re playing or some completely new concept that you want to make a reality, you need to start from the beginning.
One of the best parts about game design is how little material resources you actually need for it. A couple of notebooks, maybe a printer (especially your neighbour’s unsecured Wi-Fi-enabled printer, but you didn’t hear this from me), and the rest is really mostly mental effort. It depends on the scope of your project, but if you have the rules, most prototypes for games shouldn’t take more than a few hours to make. Remember, paper and cardboard are your best friends now.
If you ask me, there are 3 tools (and I use the term tool very loosely here) which are absolutely crucial to game design:
1) Any form of writing things down.
I prefer ye olde pen&paper, others do things digitally, but ultimately any way to organize your thoughts, ideas, comments/feedback, anything regarding your project really is absolutely invaluable. Don’t rely on memory, write down even the smallest things if you think they might be useful, and even if you can’t really find a use for them at the moment of writing. Start writing, and try to have it become a habit. Future you will either be grateful for the existing documentation, or angry at the lack thereof.
I absolutely cannot stress this enough, and it might not be fully clear to those without any experience with design. You cannot and should not expect things to always go smooth. Game design is a craft where good ideas go to die if one doesn’t have the willpower to make them work. There is no magic wand that you can wave and have your rules suddenly be bug-free, or one that reduces the complexity of that one mechanic that’s clogging up the rest of your game. That’s all achieved through constant – and at times mind-numbing – work and iteration. As one of my favorite quotes goes:
“Winners are not people who never fail, but people who never quit.”Edwin Louis Cole
A key thing to remember is that during the design process, ideas are never static. They will constantly change based on feedback, results, or hell, just because you want to see how that other option would feel like in gameplay. This point hits close to home because it’s something that took me a while to actually start practicing it when I started out with game design. You need to test your games as soon as possible. It’s hard to take a step back from theorycrafting and creating more content, and to actively go and actually play what you made. When you start working on a game, don’t look ahead to what the finished product might be like. Instead, look at what you have done so far, and make a version that would allow you to play it. It’s easy to get carried away and forget that you’re ultimately making something that’s meant to be interactive and played. Theory only gets you so far, but the reality for most games is that they show their true colors and unpredictability once you actually roll the dice, draw the cards, or move the pieces for the first time.
Where do we go from here?
To prevent this article from getting too long, especially considering how much more there is to say on the matter, I’ll cut it short for now, with a brief summary of how a process for making a game could go, based on everything we covered so far.
- Have an idea for a game.
- Write down said idea and everything related to it.
- Do your research – look up games that might have something similar, and see how they did things, i.e. learn from both their mistakes and successes.
- Create enough rules and mechanics to have a working prototype that you can play. It doesn’t need to be anything resembling a finished game, but the proof-of-concept prototype is one of the most powerful weapons in a designer’s arsenal.
- Play the game. Write down all the good, bad, and ugly things that you learned from playing it.
- Make changes based on the feedback you got (and hopefully documented)
- Go to 5. Repeat until… well, check the next article for that.
And, speaking of said next article, we will be continuing the new-to-game-design saga with taking a look at some of the most common pitfalls and mistakes that new designers can face.
Until then, I leave you – as always – with my current earworm:
This is InvertedVertex, signing off.