Jump to content
Site Stability Read more... ×
  • Advertisement
  • 03/20/13 03:11 AM

    Your First Step to Game Development Starts Here

    General and Gameplay Programming



    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.

    With your language of choice in hand, now is the time to choose how you will make the game. The choice normally is among a game development library, game engine, or a game maker. Which should you choose? If you are prototyping or are not a programmer, then a game maker would probably be the best choice.

    Game makers (ex: Game Maker, RPG Maker, ENIGMA) are able to create games (which I list later on) similar to the games of the 8-bit and 16-bit era. Game makers do some of the heavy lifting for you (ex: loading/handling image formats, input handling, integrating physics) and allow you to focus on the game itself. Most, if not all, game makers have a language specific to them to handle more advanced techniques and situations. The language more often than not is similar to C/C++/Javascript.

    Game engines such as Unreal, Crysis, and Unity handle all manner of games (ex: 2D, 3D, offline, online) and therefore are far more complex and in some cases complete overkill for the type of games a beginner should be making. Game engines should be used when you as a game developer have several games under your belt and fully understand the mechanics of making a game.

    For most beginner game developers, especially those who are programmers, choosing a game development library is a good choice. It puts those programming skills to the test and allows discovery of more things about the language. Like the language, the library doesn't matter. Whether it's SDL, SFML, PyGame (for Python only), or Allegro, the library is just another tool to create and complete the game. Game dev libraries have more or less the same features. So whichever you pick will be fine to get the job done.

    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 TM. 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 Log

    26 Mar 2013: Grammar edits, code review clarification 19 Mar 2013: Initial release

      Report Article

    User Feedback

    Create an account or sign in to leave a review

    You need to be a member in order to leave a review

    Create an account

    Sign up for a new account in our community. It's easy!

    Register a new account

    Sign in

    Already have an account? Sign in here.

    Sign In Now


       1 of 1 member found this review helpful 1 / 1 member

    I like the idea. But can you also recommend a somewhat road map for 3d games ? I am finding it difficult to move to 3d games.

    Share this review

    Link to review


    Very helpful for newbies like me. Thank you !

    Share this review

    Link to review


    I loved this article.  I'm actually following it right now and I've been at it since March of this year.  Currently on Missile Command.

    Share this review

    Link to review


    I am gonna follow this

    Share this review

    Link to review

  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!