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

The best game to "earn your wings" with? The one you completed.

The list

This one is based on some criteria of increasing difficulty (i.e. it is based on opinion, like many things). Some suggest that anything after Pac-Man, it is really up to you because, by then, you know enough and may want to focus on something specific.

There is also a series of tips in the section Some words of wisdom that should be of interests.

Guess the number" / Hangman / Mastermind

Basic interface, select data from a database.

Choose-Your-Adventure

Based on choose your adventure books, it is basically a simple text adventure game with an 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 (you can push it and add data structures/make it data-driven instead of hard-coding everything in the program). 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.

Tic-Tac-Toe / Rock-Paper-Scissors

Turn-based gameplay, simple opponent AI or second player.

Breakout / Arkanoid / Pong

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. No real needs for sounds. Also: input handling, collisions, stable frame rate, score, levels.

Solitaire / Minesweeper

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. They're event based rather than "real time".

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. Since it is a very common game, lots of open source clones out there to rip apart if you get stuck. Also: Data structures and how they relate to gaming.

Asteroids

Bullets, space physics, toroid world.

1942 / Space Invaders / Gradius / R-Type / Shoot-em-up

You can probably find some freeware tilesets to make this. Here the background is scrolling, you'll be using techniques for 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).

Simple platformer / pinball game / Super Mario Bros

The scrolling is 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. For an extra challenge: add irregular sloped terrain and parallax.

Bomberman / Pac-Man / Nibbles / Snake

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). Also: tile-based movement, complex enemy AI.

Moonlander

A rocketship affected by gravity, players control direction and thrust, limited fuel when using thrust. Tight tuning of physics, resource management, more advanced math.

Gauntlet / Zelda

Large map scrolling, interaction with the environment, enemy AI, inventory, health.

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.

Worms

Terrain destruction.

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. (This could go further down the list as it is really difficult.)

Some words of wisdom

Get to the finish line

It is strongly recommended that novice programmers should start with the simplest game that they actually want to write. 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 (some say it can even go up to 70% of the time) 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.

Focus on something small, don't re-invent (some parts of) the wheel

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.

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.

Once you've done app#1, take on something a little more complicated but, to get started learning a new technology, make the thing that you program brain-dead simple.

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!

Focus on a single aspect of games

One 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. And so just like learning multiple programming languages teaches you multiple paradigms, tackling different games teaches you different aspects of game programming. Try to learn one thing at a time.

This is an example journey: once you've got those done, in order...

1. Screen control. Simply render a blue sprite/rectangle.
2. Input validation. Change the colour of the sprite/rectangle based on key-presses
3. Text and sprite rendering. Since you also have input validation, a tile memory game is not a bad idea.
4. Timers. Force the player to do things faster.
5. Sound and music.

... you're ready to target a platform, and the learning may begin.

The rest is in no particular order, and you may rearrange them as you see fit. 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 independent 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 shadow-casting is an important way to look at banding and separating, which is in turn important for a whole lot of data structures.
• 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.

After your first game

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

Spice it up

You can take a 2d game and make a 3d version of it.

You can also make another version of your first game. For instance, start with Monopoly. You can use Brett Schuchert's Monopoly "code kata" as the basis of the exercise, and add a lot onto it. The reasons why this is interesting:

1. It teaches good coding practices (design patterns, TDD, SOLID, continuous integration, etc.) and puts a lot of constraints on the developers when they do this exercise.

2. Pretty much everyone knows the rules of Monopoly, and, with the proper preparation (e.g. having the assets available), 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 you can add a requirement for mouse controls later; or you can plug in a more sophisticated AI. 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, what makes for GOOD unit tests, give the real-world experience of clients who change the requirements on you after you've already started.

You can get something quick, and 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?).