I believe that in order to become a good game developer, you need to make games.
From a programmer's perspective, what are some good entry level games to get your hands dirty? What skills and challenges do each of these games teach you?
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It only takes a minute to sign up.
Sign up to join this communityI believe that in order to become a good game developer, you need to make games.
From a programmer's perspective, what are some good entry level games to get your hands dirty? What skills and challenges do each of these games teach you?
Breakout
Easy game since you don't have much state to worry about (it's an array of brick values -- if you only have one brick color, it's an array of flags), there isn't any AI, and you get to do a little bit of physics to get the ball to bounce correctly.
Solitaire
The rules are a bit more complex than Breakout and the interface to it is a lot different. It forces you to think about different methods of implementing a game. i.e, what works in one game isn't necessarily what you would use in another.
Pac-Man
This one is nice because you get to work on a little bit of AI. Having the ghosts follow the player (but not too well - you want the player to have a chance) can be quickly implemented, and you will have a fun little game that you can tweak and show off to friends and family (positive feedback is always a good thing when you are starting out).
I find that if you look for inspiration in early video games, you can find tons of ideas that are relatively simple to implement. Plus, you can get away with super simple artwork and sounds because you're copying something so simple anyway. This allows you to focus on the basics first -- getting your game loop up and running, figuring out how to get your pixels to the screen, playing a sound, keeping score, getting the player's input into the game.
It almost really doesn't matter which game you choose first -- just make sure you pick something simple that you can get quick results with, that way you can move on the next day and make another one. And another. And another -- the more you make, the more you'll push yourself, and eventually you'll be making complex games before you know it.
I'd strongly recommend that novice programmers should start with the simplest game that they actually want to write. As mentioned by Matt Rix, a huge part of writing a game vs. a demo is pushing the damn thing through to completion - credits, menus, play testing, high scores, pausing, play testing, difficulty levels, clean game state transitions, play testing, etc. That stuff takes at least half the time you're going to put in and it just isn't fun. It isn't. So unless you love the concept and are really motivated, you will give up and move on before the game is a game.
If you want to write an RPG, figure out the simplest, most manageable RPG concept you can come up with that you want to do and do it. Same if you want to do a sci-fi shooter, or a horror-themed platformer, or whatever. Pick something you will finish, that you will still want to finish after everything fun is done but you're still looking at dozens of hours of work before you're really done.
The best game to "earn your wings" with? The one you completed. I don't care how many half-done PONG/Breakout/Galaga/Tetris demos you've written, you aren't a game developer until you've released an actual completed game.
Plus, no one wants to play yet another version of those 40-year-old games, and at least some of the point of writing games is for people to play, right?
I posted this ladder at TIGsource a while ago. It starts from the very basic to the very complex.
The most important rule of learning game programming: learning programming is hard. Learning game design is hard. Learning how to make good game art or audio is hard. Trying to do all of these things at the same time is a recipe for failure. Learn one thing at a time.
Corollary: program a game where the design, art and sound are already done. Make clones, not original games.
In my classes, I always recommend these games to start, in order:
1) Tetris. The art is colored rectangles, which even a total klutz can draw in Microsoft Paint. You don't need sound. The programming is relatively simple, but still requires a few key things: understanding the difference between the internal game state and what's drawn on the screen; being able to draw on the screen, period (probably involving sprites and blitting); being able to accept user input in realtime rather than just using getch() or scanf() where you have to wait for them.
2) Breakout/Arkanoid. The art is still colored rectangles, and you still don't need sound. Uses all of the basic concepts of Tetris, plus some basic collision detection and 2D physics since the ball has to move and bounce smoothly.
3) Gradius/R-Type. You can probably find some freeware tilesets to make this. Here the background is scrolling, so you have to learn a bit more about how graphics memory works, using techniques like page-flipping and double-buffering and drawing stuff outside the boundaries of the visible screen. You also tend to have dynamic enemy and bullet spawns, so you'll need to learn to clean up after yourself (i.e. get rid of enemies and bullets that leave the screen so your game doesn't leak memory like a sieve).
4) Super Mario Bros. Similar to the previous scrolling project, except the scrolling is now under player control and not automatic. You also have to deal with gravity and all the fun collision stuff that goes along with it (like not falling through the floor just because you were a few pixels above in the last frame and want to move to a few pixels below in the next frame). Also note that gravity is conditional: it affects the player and some enemies, but typically not the platforms or floating coins or whatever, which is a bit different from the real world.
If you can do all four of those, you should be able to do pretty much any 2D game you want; all the tools are there. If you want to make a 3D game... learn 2D first because it's much easier and you don't need to understand the math as in-depth and you need to understand the 2D stuff anyway... and then when you're comfortable with that, start working with some basic 3D tools (either libraries like Torque or Unity, or open-source games like the original Doom and Quake).
Good luck!
Now this is an actual good question. I don't know where you are, so I'm gonna swing for the sky, and assume you've never written a line of code in your life. Cut off whatever part of the nose offends you, to abuse a phrase.
I think I'm actually going to answer a slightly different question than what you asked, and I'm going to give examples to satisfy the question you asked in situ. The reason I'm doing it that way is a slight but I believe significant difference in viewpoint: it's not so much the specific games that matter, as much as the mindsets those games bring to a designer.
You know how people talk about you're supposed to learn a variety of programming languages, in order to eat their mindsets and their hearts and their livers, and thereby to gain their mighty power? There's a real truth to that - after your first pure or near-pure programming language, even in imperative languages, you're going to end up writing largely side-effect free functions because they're so much better defined, and everything you write even in languages not of that form will be better for it. It doesn't particularly matter which language it is - haskell, ml/ocaml/smlnj, formulaONE, c++ templates, whatever - you're still going to learn how to do many classes of work without relying onside effect state. First time you learn a rugged, machine-near programming language, you're going to learn about size type abstraction. First time you learn a declarative or constraint language, you're going to learn about bounding as a discretionary tool. First time you learn a backtracking search language, you're going to learn to pray Ia! Ia! C'thulhu F'tagn Nagn!, and then we're back to eating hearts and livers, and the circle of life is fulfilled.
Game design is no different. You don't necessarily need to learn any specific game, by parallel with a specific language, but rather to learn some emblematic representative game that handles that mindset, like the language characteristic families. Also, there's lots of eating livers and hearts. Get a pepper cracker.
The gag here (as I see it at least) is that you want to cover a large list of topics. It's like ticking off proficiencies on a character sheet - you're making available to yourself more mechanisms by which to handle a given situation. Yes, they're level-able, but having a point or two in as many things as you can across the board means that when it comes time to use one, you aren't starting from scratch, and you know what tactics are available for you to scale up by.
So, look.
First you want to cut your teeth. These are also useful when you're learning to target a new platform, or when you're recovering from amnesia. These are meant to be fast, not awesome.
In order:
Once you've got those down, you're ready to target a platform, and the learning may begin.
These are in no particular order. You may rearrange them as you see fit. I'm going to give a handful of examples with each, but they're not normative; if a different game gives you the same experience, and is small enough to be part of a series of lessons, feel free to swap it in. For practical reasons, it's good to be proficient in screen rendering and input relatively quickly; you're gonna use them a whole lot. Wait a few games before trying to write abstraction classes; you don't want to be caught in a naive abstraction.
... eh. I got bored.
Tetris
Very common game, lots of open source clones out there to rip apart if you get stuck. Teaches basics of 2D graphics, input handling, scoring, etc.
Then take this original idea and put it on a spin. I learned the basics of 3D graphics/opengl by writing a 3D version of Tetris for my computer graphics class in college.
GameDev.net has a good article recommending a progression of games to incrementally learn about game development. My favorite advice from the list is to actually polish these games. Completely finish, to a releasable state.
The list is as follows (some of these have been given in other answers):
Choose-Your-Adventure
Got this tip from a friend who started programming by creating a game, much akin to a choose your adventure book. It is basically a simple text adventure game with a output like this:
You are standing in a forest clearing in the middle of the night. You hear
some wolves howl in the distance. Should you:
a) make camp for the night
b) go further north
> _
Making such a game should teach you to make a gameloop, basic console input and basic scripting. It is quite simple to implement and easy for a beginner to jump into since you don't need a graphics engine to write the game. Advanced beginners would probably write a scripting engine.
I like to start all my guys with Monopoly. I usually use Brett Schuchert's Monopoly "code kata" as the basis of the exercise, but I add a lot onto it. There are several reasons why I really like doing this.
I care deeply about good coding practices (design patterns, TDD, SOLID, continuous integration, etc.) and put a lot of constraints on my developers when they do this exercise.
Pretty much everyone knows the rules of Monopoly, and the entire game can be completed in a single day. This gives new developers a quick win and really gets their engagement up.
The initial requirements start off with keyboard controls, but then I add a requirement for mouse controls later. This gets developers thinking about several things, how to refactor existing code, programming changing parts of the system to interfaces instead of concrete classes, better/proper abstractions, what to unit test, what not to unit test, WHY to unit test, and what makes for GOOD unit tests.
Sometimes we plug in more sophisticated AI, sometimes we don't. Sometimes we work with other board games with slightly more complex logic like Chutes and Ladders or something. Sometimes we break away from board games completely, and do a poker game or blackjack.
The really important part, for me, is that people get a quick win, and they see how flexible you can make software when you follow good programming standards. These exercises build confidence very quickly. Sometimes, the more experienced developers like to do these on their own, just to get a break from more complicated projects or to practice a new technique they've just learned (law of demeter?).
In my experience with novice programmers, the progression usually seems to go something like this:
Breakout, Pong, or Asteroids.
There is a huge difference between a game and a game prototype. If you're serious about finishing your dream game, then you should finish your "entry level" games along the way. Creating the gameplay part of the game is only half the battle. All of the extra things like menus and high scores often get overlooked or ignored, but they take way more time than anyone would expect.
There are some good suggestions in the other answers, but I just want to toss in my vote for: Start with something that seems too-puny to deal with.
Pong is a good example.
The goal is: make the game-design and rules-set so brain-dead that you can focus all of your attention on learning the new thing that you're learning (a language, a platform, an API) and not have to constantly take breaks to figure out how the game works.
Once you get going, you'll find that pong is actually slightly more complicated than it seems at first blush. (I'm teaching a guy programming and he's using pong as his learning project. We added some features, and now he's getting distracted from learning to program by learning how to do all these cool features :)
Once you've done app#1 all the way through until it's ready to give/sell to others, THEN take on something a little more complicated (Tetris, adventure or whatever you like) but, to get started learning a new technology, make the thing that you program brain-dead simple.
Other examples:
But, again -- start with something that's way-too-easy, so that you can actually complete something and look back and see what's involved. The difference between having written ONE app in a language/platform/SDK/engine and having written ZERO apps is HUGE. The difference between 1 & 2, or 2 & 5, much less so, so you can take bigger steps, but make the 0 to 1 step be a teeny-tiny one; it'll be bigger than you think!
Flappy Bird
-alike. As a professional programmer, it's an afternoon's work (well, a weekend to get it "nice") but, while teaching another to program, we learned that it's actually got lots of little complications. Again, one is far-more experience than zero and, once you have one, you'll have a much better idea about how to move forward.
\$\endgroup\$
– Olie
Oct 29 '14 at 22:51
Check out this website:12 Computer science game project ideas
Some of these games include what others have said like:
But it also talks about some other games you could try making such as:
Also, it gives a sense of what you should try doing first since it gives a sense of difficulties for each game (and therefore a plan of how you should tackle the games):
A lot of people start with Breakout because it features:
Relatively simple AI, Graphics, Gameplay, Controls, and they don't have to have sound effects or music unless you want to add that in. I started with these two when learning how to program in QBasic for MS-DOS and I think they are great first games. Pac-Man would be my other choice.
The most difficult part about writing a game--or any software--is figuring out what to do. You absolutely need a spec! That's the fun part about making a clone of an existing game: the spec already exists. Your spec is "Product must do everything that Other Product does," and if you have a copy of the other game on hand, then it's pretty easy to verify that.
Once you've figured out what you need to do, figuring out how to do it is really not that difficult if you're a competent programmer. I don't mean a skilled or experienced programmer; that would imply that you already know how to do most of what you're trying to do. But you need to understand how to think in abstractions and have the problem-solving and logical thought skills that are fundamental to programming. If you can do that, then you can do anything.
Having said that, I disagree with what most people say about trying to learn to write games by writing something really simple. The reward is directly proportional to the effort you put into it. If you learn to write games by writing a really simple game, all you'll know at the end is how to write really simple games, and that won't do you much good.
On the other hand, if you start with something overwhelming, you'll never finish it. So start with something moderately challenging that will make you deal with serious issues. Building a 2D console-style RPG or a side-scrolling platformer are very good ways to learn real game programming concepts.
It really depends on what your current competencies are. If you're relatively new to programming, then go with one of the specific games that people have suggested. Otherwise, you should think about what kind of game(s) would let you put your experience to good use.
When I started my first game, I had zero game development experience, but I'd been doing enterprise/line-of-business app development for a few years. My first game project was a turn-based strategy game, and architecturally speaking, it didn't look all that different from an enterprise application. It used a client/server system, and communication happened through a duplex WCF service channel. Most player operations were queued up as "orders" and dispatched to the server at the end of the turn. All turn processing took place on the server, after which game universe updates were sent to each client.
That first project gave let me inch my way into game development while starting me out in familiar territory. As the project evolved, I learned to think more like a game developer and less like an enterprise app developer. The end result worked pretty well, and it was a bit more impressive than Battleship or Tic-Tac-Toe :).
Moonlander style games are great (where you have a rocketship affected by gravity, players control direction and thrust, limited fuel when using thrust). Gain experience implementing very simple physics and the collision system can be quite primitive. No AI to worry about and most importantly its fun and addictive :)
A top-down space shooter like Galaga is pretty easy and teaches collision detection fairly well! It can also vary in difficulty, from a level with stationary enemies, to multiple levels which weapon upgrades and enemies that move in special patterns.
Something like Gauntlet, because you need an entity system, enemy AI, pickups, tile-maps, collision detection, scoring etc. It's got it all, but not in a way that is overwhelming.
A mini Zelda clone is good and exercises some skills that haven't been mentioned much here. Scrolling a big map of tiles and simple 8-way movement controls are good to know. Bonus points if you can do enemies, but I wouldn't worry too much about that.
I have made more than a few Tetris clones. Each time I did it I did it slightly different though. Nowadays, I usually make some type of Asteroids clone though. I also have made more than a few Missile Command spinoffs.
I've started with the basic game play and than moved onto adding more stuff, power ups etc.. to it.
I always used to start with a Tanks / Gorillas / Worms game. It gets you exercise in simple graphical display, and reading user input, plus a game loop applying gravity to the projectile and testing for collision-detection.
After that would come a game like a very simple platformer or shoot-em-up where you need to read user input in real time, rather than the INPUT statements that work for Gorillas :)
I've always asserted that if you are a game programmer you should be able to make some form of Space Invaders. Heck, the game is simple enough that you should be able to do the graphics yourself as well.
Having a selection of small games in your portfolio as the added benefit of being quite useful, for example, if I am learning a new programming language or framework, I'll often port one of my simple games across to see how the new way of doing things matches up with the way they original was written.
It really depends on what skills as a regular programmer you already have. Does your math need work? Your graphics knowledge? Do you have both under wraps?
Although in general I think Tetris and Breakout would be my two starters as well. Anything easier than that doesn't offer enough stimulus. Tetris is a good test in how to layout your data an algo, breakout is a light math example. I always tell people to aim high, the goal is to get stuck and come up with a solution.
After that, the sky's the limit. Again, aim high. Try a platformer with sloped terrain, parralax and you got a good bag of 2d tech handy. Add a pinball (prepare to be frustrated) and your math will improve.
From there go to the third dimension, learn core skills (anim, rendering) and you should be relatively well equipped to deal with a good variety of games.
My first game was something like Super Mario.
Move around, avoid obstacles, jumping. And all those tasks can easily be done without any physics calculation.
Its ideal to take a simple 2D thing, as you will not rely much on a specific implementation/framework/engine.