Below, you will learn the process I follow to get started designing a new game project.
Note that while I recommend to try this approach, there is no one size fits all method to design any game.
When designing a game, initially, you can’t know which idea or mechanic will work. The way the game feels in your hands not only depends on its rules, but also in the feedback you get when pressing buttons, the visuals, the sound, and the way the game flows over time.
Take the many roguelikes that came out over the past few years. Some of their core can be similar, yet Flinthook, Scourgebringer, Rogue Legacy, and Dead Cells feel entirely different. That is because of the controls, mechanics, art direction, and more contrast. All that contributes to your experience.
That’s why you can’t say that an idea will work until you prototype it. The execution matters a lot. Also, during development, anything can change anytime, including late in production. In an RPG’s case, you may realize a mechanic prevents you from balancing your game, or that a character’s skills are so powerful it removes all strategy. When that happens, you have to make changes.
Another challenge is that you can’t capture a game’s feel with words only.
When designing a new game, I don’t write Game Design Documents (GDD). Few designers do nowadays as just like any software or design project, games are bound to change as we make them. Note that I’m talking about traditional game design bibles here: large documents that break down a game’s design on paper.
Depending on the project’s scope and the team’s size, you may want to consolidate ideas and workflows in a wiki. Also, large documents can work for story-driven games if the writing is at the game’s core. Still, to me, they are less efficient than prototyping and testing in many other cases.
I do take rough notes to track ideas I should test. Then, I jump to code as early as possible.
Before I learned to program, working as a game designer, I would write more. It was necessary because I had to explain intended mechanics to programmers. Now, I think coding skills are precious for designers. A prototype will save you and your teammates a lot of time.
When creating software professionally, you want to measure when you’re done and how much development will cost. And to do so, you need to break down the project in tasks with reliable time estimates. However, generally, it’s impossible to plan a video game until you’re about halfway through development. I consider that a game’s pre-production ends when:
If you’re making games as a hobby, of course, you don’t have to bother with planning or designing the final product for others. Still, keeping these points in mind can help you scope your project well and complete it, even if it’s personal.
Here are some questions I ask myself when getting a game project started. The order and timing of the questions vary. The more experimental or original your project is, the longer it may take you to find your audience.
If you’re borrowing from existing games, for instance, by making a platformer, a rogue-lite, a JRPG, or following any codified genre, then you want to think about your players early on.
In this RPG’s case, I started with the following questions:
At first, you may not have a clear idea of who your target players are. In that case, try to start with a broad audience and narrow it down throughout pre-production.
You can’t make games that everyone will like. That’s why you want to get to know your players: who they are and what they expect from you. You can learn that from other products you use as a source of inspiration or try to put your prototypes in people’s hands and see who reacts positively to them.
If you want to make a living off your creations, you need to tailor them to your users’ expectations. I’m not advising you to let them tell you what to do. Instead, I mean that you should observe how users interact with your game and do everything you can to improve their experience.
A professional designer creates games for others to enjoy.
You can look at other titles for inspiration, but you need to bring something original to the table. That can be a striking art style, a pleasant vibe, a twist on a popular mechanic or genre, or something else.
You don’t have to figure out an entirely new and unique design. Most designs merely remix what’s already out there. Producing something genuinely new takes a lot of research and experiments.
Some mechanics are hard to pitch. They can sound boring, silly, or overused when you tell them to people, but can still work wonderfully in hand.
More often, though, ideas that sound great in our mind suck in a game. This is why you should prototype, get people in your target audience to try your prototypes, and take their feedback into account. Don’t be pretty about your game and ideas. If they struggle to play, fail a lot, or quit early, think about the changes or improvements you can bring in the next iteration.
In any case, a prototype is worth so much more than words. That’s why I recommend you to start coding as soon as possible.
Prototypes can have widely different sizes. They’re here to answer questions and this is what will determine their scope.
The largest prototypes involve implementing and testing the game’s core mechanics. They answer questions such as “Is my game’s idea or design fun?”. In other words, those prototypes answer the “initial questions” we just discussed. Depending on the project, it may take from several hours to several days.
But they can be more specific and much smaller in scope. Imagine that you want to create a mobile game with thousands of characters moving around. You should ask yourself: “How can I simulate so many characters in real-time?”
In that case, your prototype would be a benchmark to test the game’s performance. Or it could be about estimating the work involved in coding the system.
Yet another question would be, “can the engine handle ten thousand animated sprites on screen?”
You can code a prototype to answer this in several minutes.
A good prototype is the smallest project you can implement to answer one question.
As implied in this section, you want to start by writing down questions to figure out the prototypes you need for your project. And these are yours to find based on your experience.
I found I mostly ask two types of questions:
The first category of questions is about game design, while the second is about time, budget, or performance.