When I talk to people looking to get into game development some of the first things I often hear fall along the lines of, "How do I make games?" or "I want to make a game like Quake/Everquest/Starcraft and...". The first is just way out of the realm of answerability, as there are too many aspects to possibly go into, and each of those components can be infinitely complex.
The second, however, falls into just being unrealistic in expectations. Starcraft, Everquest and Quake were all made by teams of professionals who had budgets usually million dollar plus. More importantly though, all of these games were made by people with a lot of experience at making games. They did not just decide to make games and turned out mega-hit games, they started out small and worked their way up.
This is the point that anyone who is interested in getting into game development needs to understand and repeat, repeat, repeat until it becomes such a part of your mindset that you couldn't possibly understand life without this self evident, universal truth.
Until you understand that all skills in game development are learned by experience, (meaning to start very small and working your way up) you will be absolutely doomed to never finish your projects. Even the infinitesimal number of teams that do manage to finish a non-trivial project before they have made any smaller ones have to learn incrementally, it just takes them many times longer than if they had started out with smaller projects.
So where do I start?
Tetris.
Tetris is the perfect game to begin your journey on the path to becoming an able bodied game developer. Why?
Because Tetris contains the all the elements found in every game, and can be done with just about the least amount of work. Also, you don't have to be an artist to make a good looking Tetris game. Anyone who can draw a block, which is everyone with a paint program, can make a commercial quality version of Tetris.
This is another one of the big benefits of starting with Tetris. Not only can you make a fully functioning game, that is fun and addictive, but it looks basically just as good as any commercial version done of it. Blocks are blocks no matter who draws them, and tetraminos (the shapes used in Tetris) are all just a collection of four blocks.
Tetris has all the individual components that ALL games share in common. It has a game loop (the process of repeating over and over until the game is quit). The game loop reads in input, processes the input, updates the elements of the game (the falling tetraminos), and checks for victory/loss conditions.
Every single game you will ever make does all of these things, so learning the process and actually implementing it is extremely important. After you have completed this the first time, it will give you an insight into how hard it will be and how long it may take on future games. Without having done this all the way, at least once, you will never fully have a proper grasp of each of the elements.
When you have larger projects, there will be more unknowns that you can't judge for in complexity and time. If you don't even fully understand the entire process because you have failed to DO it, you will likely be helpless to create schedules or estimate times properly and will most likely not succeed at the endeavor. You can find a good tutorial on making Tetris with C# and XNA HERE, although the logic can easily be transferred to other languages and libraries.
Something I need to mention is that when you make your Tetris game, you can't call it "Tetris". Tetris is a trademark of the Tetris Company who is owned by Alexey Pajitnov, the creator of Tetris. It is his exclusive right to use the name Tetris, and I believe they may have won a lawsuit saying that you cannot make a falling blocks game with the syllable "tris", as it is obviously playing off the popularity of the of the name Tetris.
However, this means nothing to you if you call your game "The Sky is Falling", or anything without a "tris" in it, as they do NOT own the gameplay, interface, or idea of falling blocks. If you hear anything differently from anyone, tell them you can't own ideas, and if you require further proof you can look up information on this subject at the USPTO (http://www.uspto.gov/ ).
What's Next?
After you have totally, completely, absolutely finished your version Tetris, you are ready for your next challenge: Breakout.
Breakout is also a similar game, but it adds in much more advanced collision detection than was necessary in Tetris. You will also need to add some simple deflection physics of the ball rebounding off different portions of the paddle and the blocks. Level layout also becomes an issue in Breakout, and in order to have more than one level you will need to come up with a way to save the maps.
This deals with another component found in all larger games, which is saving and loading resources and switching levels. After you finish your Breakout masterpiece you should move on to making Pac-Man. Pac-Man is an evolutionary step because it adds in the element of enemy artificial intelligence (AI).
You may not have been aware of this, but in the original Pac-Man the four different ghosts had different goals to trying to defeat you as a team. The aggressor would try to follow the shortest path to you, making you directly avoid him. The interceptor would try to go to a junction that was closest to where you would have to move to avoid the aggressor. A second interceptor would try to stay more towards the middle and try to cut you off from using the tunnel through the sides. The last ghost would sort of wander aimlessly about which often kept him staying in a section you needed to finish the map.
This kind of detailed AI was quite advanced for games of that time, and should give you a good challenge for your first game with enemy AI. Pac-Man also increases the complexity of maps, and adds a good deal more flexibility for using sounds, as sound was certainly a crucial elements to the success of Pac-Man. (After all, what would Pac-Man be without some sort of "wakka-wakka" sound?)
The last game I suggest you should create is a side scroller, such as Super Mario Brothers, where you can jump on multiple platforms, shoot, duck and interact with enemies.
As there is added art involved in this game, I would suggest looking in to using SpriteLib for some free and easy to use artwork, which is available at: http://www.flyingyog.../spritelib.html
Side scrollers introduce the possibility of added enemy AI complexity through the use of enemy bosses which have patterns you must learn to beat, as well an added screen complexity. Now you must make a screen that is capable of scrolling in at least two directions, if not four, and deal with screen clipping, which can have a bit of a learning curve. You must also work on the physics of any jumping, bouncing of the character or shooting projectiles.
There will additionally need to be a lot more enemies than before, and you will need to keep track of their current game state (alive/dead, active/inactive), by whether they are on the screen or have already been dealt with. The level complexity and map/character storage complexity will have also increased and you will most certainly need to make a level editor at this point.
The level editor should be capable of placing tiles, scrolling through tiles, scrolling over the map, choosing tiles as brushes, cycling through the brushes, cutting and pasting, an undo, and placing enemies. If you decide to skip writing any of these, you will most likely feel sorry about it, and if you have an artist or level designer, they will probably not be very happy with you either (how would YOU feel if you had to go through someone's text files containing a bunch of numbers and commas to edit a level?).
I would also suggest making back ups of previously saved maps, as it is often easier to just back things up by versions, than redrawing them. Finally, the side scroller has a real victory condition! When you get to the end of the side scroller, you have actually GONE somewhere, so you can add on a story to progress through the game as well (and don't forget some sort of fireworks on the screen for the end of a level, so that the player has a sense of accomplishment and a REAL show of fireworks for beating the game... merely putting the words "You Have Won!" on the screen when a player has spent endless hours trying to beat your game is anti-climatic).
Get out the Polish...
Finishing a game does not merely mean you get it to a point where it is playable, and then move on, this is not a finished game. A finished game will have an opening screen, a closing screen, menu options (if applicable, at least instructions on how to play and start), introduction screens to playing, reward screens and a score board (where applicable).
If you couldn't put your game in an 80's arcade game and not be able to tell it doesn't belong just by the modes it goes through (minus the attract mode or demo mode), then your game is not finished. There is a big difference between a game that is "bare bones", and a game you have put all the finishing touches on.
This difference will be a matter of a couple of days to two weeks (depending on the size of the game). It will get increasingly (sometimes exponentially) more involved as you move from Tetris to Breakout and so on. The result, though, will be very important, both to terms of your understanding game development, and your own pride in your work and satisfaction/fulfillment. (Accomplishment does wonders for self-esteem!)
It's not easy to show people your game and have to constantly tell them to overlook different things and feel the same as if they picked it up and had no problems moving through it and everything was well presented and complete feeling. Other game developers are a bit more forgiving, since they know the process.
Most importantly though, you will learn all the details that go into really finishing a game. If you stop at just working gameplay, you will still miss out on the details of wrapping things up, which will leave a blank spot in your mind when trying to plan larger projects in the future.
But, These Games are Stupid!
Actually, these games clearly show the basis for ALL games' gameplay. Throw a fancy 3D interface over a shooter and it's still a shooter. You could create the same game in a 2D overhead view and the gameplay would be coded exactly the same.
Is it stupid to be able to make a game with EXACTLY the same controls, responses and enemies as Quake? If you remove the 3D interface, and look at what is really happening from a directly overhead view, does it still seem as out of reach?
Even so, this is not a beginning project. There are too many elements that need to be developed and refined for a first project, so I strongly urge you to follow the order of games I suggest to gradually build up your understanding of game development. (When you learned how to swim, did you IMMEDIATELY start out with a high dive into the deep water? NO! You start in the shallow end, you learn to dog paddle, and progress from there.)
One thing that you need to clarify to yourself before starting anything, is what you want out of it. Do you want to make games, or just duplicate the technology in Quake? If all you are interested in is the technology, then skip all the games stuff and get started on graphics technology.
If you are really interested in making games, then you need to separate your desire to create the next cutting edge, hard core game, and focus on building your ability to do so. The best way to do that is through actually making and (more importantly) finishing games, which is what following this path (or a similar one) will give you experience in.
Be proud of your games!
You don't hear people in college embarrassed about being in college because they don't have a job yet. You are learning, and making even a simple game is hard, especially if you want it done WELL. This is shown clearly by all the people who have NOT made even simple games but talk about it constantly. Once you have finished a game, consider yourself to have more of a track record than anyone who has not finished a game even if their idea sounds phenomenal and like it's up there with the latest cutting edge games.
If you can't play it, it's not a game. When you have a finished product you can show, you need to accept that for what it is, not what it isn't or compare it to people with 5+ years of experience and million dollar budgets who work on games full time.
I made my game, now where's my Ferrari?
Sorry, one game, two games, five games probably won't cut it. Last year there were 3,500 games released on the PC, and only a few handfuls made back a large portion of cash. Most of those that did weren't made by small groups who were self-funded, they were funded by large publishers and probably had multi-million dollar budgets, and definitely near or well over million dollar advertising campaigns.
This isn't a world you can't join though, it just takes a good deal of time and experience and track record of making quality games, that hopefully sell well, to give publishers confidence in your team, so that they will entrust you with this kind of financial responsibility.
However, there is more to making a living of games than the multi-million dollar budgets and I strongly suggest you take a look at the other things as well.
There is nothing bad or embarrassing about making budget games, they can be just as or more fun than the high budget commercial games, and it is a lot easier to get publisher to trust you with smaller budgets.
On top of that, you don't have to spend years working on the same project, and if it doesn't go over well, you don't have to feel as much loss with it. Just have an understanding of what you really want out of making games and then concentrate on making that come true.