How to make a Game
This article explains how to make a game step by step. We will talk about the idea, the Game Design Document, the teams, the development phase, the test, the release, the lessons learned and the maintenance.
Before we can make a game, we need an idea. There are several methods that can assist us to find one:
If you are reading articles on a website about how to make a game, you probably already had the one or the other game idea before. Sometimes they just pop into our head randomly. The key is to remember them! All it takes is a simple text file on our computer where we add a short description about our idea every time we got one. As the months pass, the text file will fill itself with all kinds of cool game ideas.
Another method to find an idea is to force it with the Brainstorming technique. Get a friend and just speak out everything that comes to mind. The goal is that something that your friend says gives you a new idea, or vice versa.
The previous methods are very easy and can be applied by everyone. Yet there is another option, called Idea Engineering. Idea Engineering stands for a bunch of real techniques to generate ideas. Those techniques have to be learned and they are often a lot of work, but they are the best way to steadily generate good ideas over and over gain. If you are interested in learning one of those techniques, feel free to type Idea Engineering into your search engine of choice.
Game Design Document
The Game Design Document is the complete plan about the game. While it's optional, it's always a good idea to at least try it out. It helps to keep the overview along the way and it makes us think about important aspects of the game that we might forget otherwise. To create a good Game Design Document all we have to do is open our text editor of choice and write about the following topics:
Describe the game in one sentence.
Core Mechanics: what does the player do most of the time?
Meta Game: what are the rules of the game? What is allowed, what is not allowed?
What does the game world look like?
What is the path along the story? Can you create a graph that shows it?
Which game states are there? How does one lead to the other? (Example: Menu, Settings, Ingame, Login, ...)
Sounds: which events trigger which sounds?
Texts: which events trigger which texts?
Effects: which events trigger which effects?
Besides the feedback, what is the background music like? Which style is it?
Which platforms should the game run on? (Windows? Mac? Android? iOS? Playstation? XBox?)
Where will the game be released? On Steam? On a Flash game site? Or will it be a free download on some website?
Should the game be finished at a specific date(deadlines)? When should which feature be finished? Or should there be no deadlines at all?
Detailed game description
Reward and punishment: when does the player get rewarded, when does he get punished?
Characters: which characters are there? What makes them special?
Places: where does the game happen? Do the places have a special history? Do they look special?
Games can be big. Before starting to work on it, it's important to decide if there should be a team or just one person. More about teams can be read in our Teams article. In short: teams have good and bad sides. If you never worked with one, just try it out.
Now here comes the fun part, the development phase. Here is where the magic happens. Here is where the most questions about how to make a game occur. No matter how good our idea is, this part will be tough. It all comes down to hard work and persistence. This is the phase where the whole team has to work like maniacs for months or even years.
There are several methods that can help us to keep our sanity along the way:
The Waterfall Method
The waterfall method is very simple: plan every single feature before the development phase starts, work through it until the end and then release the game. The waterfall method is very strict: even if we change our mind along the way, we are not allowed to change anything in the project.
The Agile method
The agile method is basically the opposite of the waterfall method. First off, we split the development phase in smaller phases, called iterations. The goal at the end of each iteration is to have a product that can be released to the market already, even though it only has a few features. Instead of only releasing our game when its 100% finished, we release a alpha version, a beta version and so on. Another difference is that we are free to change features if we changed our mind (we are agile).
The I-have-no-method method
We could argue that we are indie developers because we don't want to work the way big companies do (which is totally fine). A game can still be finished if we have no method at all. We just start working, release when we think its time to release and work on what we think has to be worked on at the time.
After all, the game is what keep us awake at night, and what we think about in the shower. The whole plan is in our head already, there might be no need for writing it down.
If we got here, the crazy part is done. Now the trick is to be patient and take a few more weeks to stress test the game. The goal is to find and fix as many bugs as possible before the release, so hopefully the players won't find many bugs when they play it the first time.
Just sit down with the team, grab a pizza and play the game until everyone fell asleep. Make a list of all things that are broken. Try things out. Test all the settings, find out if everything can be saved and loaded properly. Try the game on as many different machines as you can get your hands on. Try different resolutions and graphics settings. Find out if the game is still playable if the monitor brightness is on low. Try everything that you can possibly think of!
We successfully survived the previous phases, now it's time for the release. The team can now go home and take a break, while the team leader uploads the game to all the markets that should offer it.
The common way for beginners is to upload the game to Kongregate, which is one of the biggest Flash and Unity Game sites. The name, the logo and the description will have a huge impact on the game's success, so give your best. The cool thing about Kongregate is that they give the developer a certain percentage of the game's revenue - who knows, maybe it makes some money.
If fans were following the game's process, then it's time to inform them about the release. Write a big article on your website, post on social media sites, write emails, make a post on game development forums and tell people in your instant messenger of choice.
Spread the word!
While it's optional, it's still a good idea to sit together with the team and think about which mistakes where made, how they could have been prevented and what else was learned. The goal is to make less mistakes in the next game and to increase the success chances.
A few common topics are:
- Team size
- Time Management
- Programming Language choice
- Game Engine/Framework choice
- Stress / Fun
- 3D Model creation
- 2D Art creation
There is one more optional phase: maintenance. If you still have fun working on the game (or if it's being sold well), then it's important to keep maintaining it for a few months. Give the players an opportunity to contact you about bugs that they find, and then fix them and release the next version of the game. This is a great chance to win a long term fanbase by showing that you care about the players.
After all, it needs hard work to make a fun game. Planning, testing and maintenance can become boring easily. The development phase usually gets people very close to a burn out.
Do your health and your sanity a favor and take some time off. Working in crunch mode 16 hours a day can't be the big thing, there has to be more. Get out, enjoy the real life for a while. Get inspired and relaxed before jumping into the next big thing.
This was the basic guide on how to make a game. It can be a long and painful way, and it can be very disappointing if a game fails. The most important thing is to see it as an adventure and to have fun along the way, no matter what happens.