What are good games to “earn your wings” with? [closed]

Question

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?

Answer 1

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.

Answer 2

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?

Answer 3

I posted this ladder at TIGsource a while ago. It starts from the very basic to the very complex.

• "Guess the number" / Hangman (basic interface, select data from a database)
• Tic-Tac-Toe / Rock-Paper-Scissors (turn-based gameplay, opponent AI)
• Arkanoid / Pong (collisions, stable frame rate, score, levels)
• Tetris (data structures and how they relate to gaming)
• 1942 / Shoot-em-up (enemies, bullets)
• simple platformer / pinball game if your engine does platformers (gravity-based collisions)
• Bomberman / Pacman (tile-based movement, complex enemy AI)
• Two-player game of any of the types above (two player inputs)
• Roguelike / Diablo (Inventory management, multiple enemy AIs, saving and loading complex game states)
• Faceball / Wolfenstein 3D (basic 3d movement and rendering)
• Network turn-based game (basic networking)
• Gimmicky 3D third-person platformer (physics, complex 3d movement)
• Network real-time game (Client-server synchronism, lag)
• MMORPG (Persistent world)

Answer 4

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!

Answer 5

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:

1. Screen control. Bluescreening is great for this, because then you have compelling reason to believe you're on your way to being Microsoft.
2. Input validation. Fooscreen, where foo is blue for up, red for down, etc. Check all your keys; there are more than enough colors, or you can four-color map if you absolutely need to save crimson for more important things.
3. Text and sprite rendering. Since you also have input validation, a tile memory game is not a bad idea.
4. Timers. Time for a Mario clone or an Arkanoid.
5. Sound and music. Improve the mario clone. Not much though.

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.

• Animation. Almost anything you do can call for animated sprites. Get an independant animation engine under your belt, even if it's programmer art. Making a simple puzzle game whose tiles throb is enough.
• Complex scoring. Get all five enemies in a wing? Bonus. Land three punches in a row? Bonus. Make it through the whole level without missing a bullet? Huge bonus.
• Pathfinding. Lots of games need this, but a tower defense game is about the simplest. You can get started with breadth-first and depth-first if you've never done it before, but you're not done until you've implemented A* from scratch (NOT COPIED CODE) at least once.
• Enemy behavior. Dumb automated behaviors will be covered by your mario, but reactive behaviors are important too. This is a good excuse to build a tactics game or a roguelike. (Warning: you will work on the roguelike for the rest of your life.)
• Dynamic 2d lighting. This is also a good reason to write a roguelike. Arc-based shadowcasting is an important way to look at banding and separating, which is in turn important for a whole lot of datastructures.
• 2d Physics. This turns up in a whole lot of games, at a whole lot of levels of detail. Try a platformer (mario-ish,) which can be super-simplified; a tank game (scorched-earth-ish,) which can be equally simplified; and eventually, a game like N the Ninja, which makes you cope with running on angles, momentum, et cetera (you can do that with an axis-aligned bounding box collision system pretty straightforwardly.) Physics and collision are pretty intimately related.
• Collision detection. There are ridiculously simple cases, like grid Arkanoids and Mario clones, moderately complex cases like N the Ninja and genuinely complex cases like sandbox physics games (the incredible machine, modern arkanoids like BreakQuest, et cetera.) In many cases you can get by with something like AABB, but if you're math inclined, it might be useful to actually implement something complete. At a minimum, get familiar with a complete library, such as APE or Box2D.
• Risk/reward relationships in game play satisfaction. Simple dice games (go digging around for something called "Skunk" from the 50s) and risky-path (life, candyland) board games are great examples of simple quick ways to learn this by doing.
• Expressive variation in mechanics. Nail yourself down to some small count of rules, then learn to get a whole lot of variation out of them. Custom deck card games are a great way to work with this; take a look into Dvorak decks, and real world games like Mille Bornes, Rage and Uno, then make a few of your own. They don't get to be similar.
• Generated content. Simple map-based strategy games, roguelikes and some kinds of puzzle games are great ways to learn to do this. Bonus points if it's a kind of game not generally known for having generated content.
• Style. Don't screw around: this is a big deal. Make a game, then skin it to be four completely different games. Really different. One a kids' game, even. (Think about it: Mega Man makes perfect sense as a sorcerer adventure into hell, or as Rogue from the X-Men, or ...) Now, get four groups of people to score one each of your games. After that, have them score the next game, counter-clockwise, around the ring, and so on. Notice how radically their scoring changes based on theme and prior expectation.
• Making the player plan sequences. Puzzle games are sort of the cleanest ways to go about this.
• Resource management
• Upgrades
• Cranking up time pressure

... eh. I got bored.

Answer 6

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.

Answer 7

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):

1. Tetris
2. Breakout
3. Side Scroller / Platformer

Answer 8

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.

Answer 9

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.

1. 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.

2. 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.

3. 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?).

Answer 10

In my experience with novice programmers, the progression usually seems to go something like this:

1. Pong
2. Tetris
3. Huge amazing awesome 50 hours of gameplay 3D RPG (note: most people give up programming part way through this step)

Answer 11

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.

Answer 12

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:

• Guess the number (between 1 & 1000)
• Mastermind (advanced guess the number.)
• SimplePaint
• Snake/worm/whatever-you-call-it.

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!

Answer 13

Check out this website:12 Computer science game project ideas

Some of these games include what others have said like:

1. Pacman
2. Tetris
3. Pong

But it also talks about some other games you could try making such as:

1. Tic-Tac-Toe
2. Who wants to be a millionaire?
3. And a Mario clone.

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):

1. Beginner
2. Intermediate
3. Advanced
4. Best

Answer 14

A lot of people start with Breakout because it features:

• Input: moving a paddle back and forth
• Simple Collision: ball bouncing off of paddle, bricks, and wall
• Changing "Game State:" Updating score when the ball hits bricks and removing the bricks, decrementing number of balls when ball hits the bottom of the screen, losing the game when the number of balls == 0, etc.
• It is also a fairly gentle introduction to graphics as it's all rectangle and circles

Answer 15

Nibbles and Space Invaders

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.

Answer 16

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.

Answer 17

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 :).

Answer 18

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 :)

Answer 19

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.

Answer 20

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.

Answer 21

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.

Answer 22

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.

Answer 23

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 :)

Answer 24

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.

Answer 25

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.

Answer 26

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.