You’ve thought about making games for a long time, but you haven’t seriously pursued it. Until you get serious about it, you’ve accomplished nothing, you’re a mere dilettante. So today you’ve decided to make a game. How are you going to go about it?
First, unless you have well-developed programming skills you’re going to have a much better chance of achieving something if you make a tabletop game, or (perhaps) make a level for a videogame. The most important thing is to get to where you play the game. All the idea generation and other preliminary stuff is effectively airy-fairy head-in-the-clouds daydreaming that almost anyone can do but which does them no good if it doesn’t result in a playable prototype. Without well-developed programming skills or at least a good working knowledge of small game engine such as Gamemaker, you won’t be able to make a videogame prototype soon enough for it to be practical. You may be able to use a level editor that’s included in an existing game to make a variation, and that can be a good way to start.
Second, beginners almost always make a game based on another game. Often the best way to start out is to make a variation of an existing game, because it takes a lot less time and work to get to the point where you can play it. Again this applies to tabletop games or to video games that provide ways to modify them, usually a level/scenario editor. If you can’t bring yourself to make tabletop games then the level editor is definitely the easiest way to start out, even though you’ll have to learn how to use the level editor, a non-trivial task.
Third, reign back your ambition. Try to pick a type or form of game that is fairly common, not one that’s unusual; unusual forms are frequently more difficult to achieve, that’s why they’re unusual. For example, cooperative games are especially difficult in tabletop form because it’s so hard to provide significant opposition. This is much easier to do with a videogame IF you have the programming and “artificial intelligence” skills. But it is still much harder to program a game that can be played by two or more people at the same time, than to program one that is played by one person at a time.
In other words try to choose a project you actually have a chance to complete. This can be generalized to “keep it simple”. Making a game is almost always harder than it seems at first, even for experienced people. The most common mistake of people seriously trying to make a video game is to plan a project that they have virtually no chance of ever finishing, because it will take much too long. Remember, AAA video games take hundreds of man-years to complete for professionals with vast budgets.
Fourth, focus on the gameplay not on the appearance (or the story) of the game. You’re making a prototype, not a finished game. You want something that people can play so that you find out whether they enjoy playing, and how you can improve it. You can’t rely on flashy looks to make games fun, even if you’re an outstanding artist. A major mistake of novice game designers is to make something that’s pretty rather than something that’s functional. If you have something that just looks functional and people like to play then imagine how much more they’ll enjoy it when it looks professionally pretty. You only need it to look good enough that playtesters will be willing to play, and that depends in great part on what playtesters are available, how well you know them, how persuasive you are, and many other factors not related to the game itself.
In most cases, you may be excited about your story, but other people won’t be. Most games are played for the game, not the story (which is often only an excuse to get to the action). If you’re heavily into story, write a novel, don’t design a game! When you’re experienced you may be able to rely on a story to make a game enjoyable, when you start out that’s a big mistake.
Fifth, when you have a playable prototype play it yourself, solo, before you inflict on other people. I say “inflict” deliberately. You may be super excited, you may think it’s the greatest thing ever, but in reality it will be like almost every other initial prototype of a game, it will suck. Experienced designers have a much better chance of recognizing what will suck before the game is played: they play the game in their mind’s eye, so to speak, and anticipate many problems before it’s ever played in reality. Beginners should try to do the same but will be much less successful at spotting the flaws. What solo testing can do is quickly reveal where the game really sucks so that you can change it before other people have to put up with it. In other words, be nice to your playtesters: get rid of the really bad aspects yourself rather than foist them on other people who want to play a fun game.
Some people confronted with the notion of solo playing a multiplayer tabletop game will say they just can’t do it, they just can’t dissociate themselves from one side when they play another side. Wags like to say “well at least when you play solo always win”. Of course you also always lose. But the point of solo playtesting is not to win or lose, it’s to find out whether the game is worthwhile and how it can be improved. And that dispassionate dissociation from one side to another when you play a solo game will actually help you recognize what’s good and bad about the game.
I cannot say this enough: play the game yourself before anybody else plays.
Sixth, if you got this far you’re doing really well. But you’ve only just begun. The really hard part of making a game is a last 20% of improvement that takes 80% of the time. This is a process of playtesting, evaluating the results, modifying the game to improve it in light of the results, playtesting again, and going through the whole cycle again and again and again. This is called the iterative and incremental development of the game. If you want to make a really good game then you are probably going to be sick and tired of it by the time you get toward the end of this process.
Finally, the game is never really done, you just come to a point where the value of the improvement is less than the cost of the time required to achieve it (Law of Diminishing Marginal Returns). Moreover, you might think you’re “done”, and then find out that improvements need to be made either for your peace of mind or because the publisher requires it.
Good luck. And remember: “A designer knows he has achieved perfection not
when there is nothing left to add, but when there is nothing
left to take away.” Antoine de Saint-Exup’ery
• make a tabletop game, or use a simple level editor to modify an existing videogame
• make something based on a game you know
• reign in your ambition–try to complete a small project, not a large one
• focus on gameplay not prettiness or story
• play the game yourself before anybody else plays, even if it isn’t intended to be a one person game
• iteratively and incrementally playtest and improve the game
• your never really finish