This article attempts to answer one of the most asked questions on GameDev.net. "I am a beginner. What game should I make?" If you are a beginner at game development, you should definitely read this article.
Your First Step to Game Development Starts Here
You've learned a language. Skills are at the ready. Now it's time to finally create that game! After years of playing games and discussing graphics, design, and mechanics, the time to put the game that has been dreamt about on the big screen is now. That Final Fantasy 7 remake is the first game that needs to be made. The idea of making it an online multiplayer is also a priority. Why? It would make the game better of course. Plus, everyone wants that feature anyway. Now the googling begins. What engine was it made from? What graphics does it need? Did it use DirectX or OpenGL or even Unity? Every new question produces two more questions. It gets to the point that the tasks and goal can be overwhelming. But with ambition the goal can be met! Right? Unfortunately as many beginners come to find out, the complexity of a game can tamper ambition and in some cases completely put out the flame. However, this article will help you prevent that and also build up your game programming skills.
But first let's address some issues that a vast majority of beginners run into.
Many beginners ask what language they should be using. The answer is this: any language. Yes, that's right: C, C++, D, Java, Python, Lua, Scheme, or F#. And that's the short list. The language is just a tool. Using one language or the other does not matter. Don't worry about what the professionals are using. As a beginner, the only priority and goal is having the tools to create and complete the game. The second priority is to improve your code and skill. We'll get into that a bit later. Remember there is no "which language is better?" or "which language is best?". The only question anyone with experience will ask is: "How much experience do you have with the language?". At this stage in the game development journey, familiarity and skill with whatever language you are using is more important than the language itself. This is an universal truth.
Finally after gathering our tools: language and game dev library or game maker software, we are ready to answer the most important question of all. "What game should I make?" For this question, the answer has to be approachable, doable, and for the most part understood. This is why the game that should be made should be 2D. Everyone understands 2D games. 2D games can be fancy but at its core they are basic with very few "moving parts".
Believe it or not, the previous question has a definitive answer. And that answer is Pong. Now you may wonder, "why?". Well, Pong is one of the simplest games known. The graphics are simple and the mechanics are simple. There's no guesswork on how Pong should work. Therefore it's the best candidate for the first game to be made. Each new game that is presented in this article is meant to show something new and/or build upon what the last game taught you. The skills that are learned from each game become cumulative and not specific to just one game. So each game is a step up in terms of difficulty, but nothing a little brainpower and some brute force can't solve.
Now I'll list some well-known games that will definitely help your game development skills and allow you to have actual complete games under your belt. I'll quickly point out some things that will be learned for each game. These games are:
- Pong = Simple: input, physics, collision detection, sound; scoring
- Worm = Placement of random powerups, handling of screen boundaries, worm data structure
- Breakout = Lessons of pong, powerups, maps (brick arrangements)
- Missile Command = targeting; simple enemy ai, movement, and sound
- Space Invaders = simple movement for player and enemy, very similar to breakout with the exception that the enemy constantly moves downward, simple sound
- Asteroids = asteroids (enemies) and player can move in all directions, asteroids appear and move randomly, simple sound
- Tetris = block design, clearing the lines, scoring, simple animation
- Pac Man = simple animation, input, collision detection, maps (level design), ai
- Ikari Warriors = top down view, enemy ai, powerups, scoring, collision detection, maps (level design), input, sound, boss ai
- Super Mario Bros = lessons of Ikari Warriors (except with side-view instead of top-down view), acceleration, jumping, platforms
The list shows games in terms of difficulty from least to greatest as far as programming them goes. There are games that others may suggest but these 10 games will definitely round out what you need to know in 2D game development. If you can make and complete these games, then games like Sonic, Metroid, or even Zelda become that much easier. Those games are just variations or extensions of what you have already learned.
Before I end this article, I would like to say something about completing the games. As I said above, your primary goal is making and completing the game. However, your secondary, and arguably just as important, goal is to refine your game. It's safe to say that 99% of programmers do not code Pong perfectly. Most likely your first or even second go around with Pong or Worm will not be a software architecture masterpiece. And it's not supposed to be. However, to improve your code and therefore your skill, you'll have to submit code for a code review. As all will attest to, this is A Good Thing <sup><font size="2">TM</font></sup>. Allowing others to proofread your code will give you insights on better structure, better practices, and dangerous code that may work now, but may crash in the near or far future. Being introduced to good advice early in your game dev journey will save you from sudden and unnecessary meetings between your head and the keyboard. As you complete one game and move on to the next, do not kick that completed game to the corner. Go back (sooner rather than later) and refactor and improve the code. Doing so is proof that you understand the advice that others are giving you and shows that your skills have indeed become better. So in short, the process of making a game should be: create > complete > code review > refactor. Again, once you submit your code for review go on to the next game on the list, but remember to go back and improve that code after you get some feedback.
If you've made it to the end of this article, you now have a path to start your game development journey. This article is meant to be a guide and not a be-all, end-all to game development. Hopefully the advice given here helps others start to become better game developers.
NOTE: You can post code reviews in the For Beginners forum. Also, it is easier on the people checking your code if you post all the code in your post.
Article Update Log26 Mar 2013
: Grammar edits, code review clarification19 Mar 2013
: Initial release