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