Jumping in the gaming waters

My first advice: don't start something just because someone has recommended it. You should start doing something only if you feel motivated about it. Game programming is probably more difficult than you would think.

I have been in the games industry for several years by now and I'm working on serious games with complex engines. I think I can give you good advice regarding game programming. There are very simple games and very complex ones. For example writing a 2D amoeba is relatively simple even if you put in multiplayer mode but writing a performance critical 3D first person multiplayer shooter game has so many difficulties from several aspects (difficulties when rendering because depending on level design you may see too many polygons, network/feedback speed problems: you often have to aid this with client side physics prediction, strategy games: serialization problems/bugs all the time...).

One thing is for sure: you should work yourself up gradually as Sergey recommended. At the beginning you may be able to work yourself up quickly sometimes with large steps especially if you are eager and motivated but the limit is only the blue sky... You will see that game programming consists of so many complex technical challenges that you simply cant learn everything even in 10 years but don't be sad: Only a fraction of that knowledge is enough to create a good game! :-)

So what is the difference between the 2D amoeba and the first person shooter or 3rd person adventure game or startegy game with cutting edge technology???
A game engine is a (big) piece of helper library that can be used to create games. This library contains code that is often needed in some kind of games. A game engine itself is usually a library that consists of some of the following libraries:
- physics simulation
- networking
- renderer
- 2D/3D engine (that is used to store the objects of the world)
- sound system
- animation system
- AI system
- particle system: to show explosions, smoke, muzzle fire, ...
- any other useful libraries, for example I've seen libs that simulated a flock of birds and stupid animals (just for the sake of visuals) in a more cheaper way than creating the same as objects in the engine as full fledged world objects.
- Tools: Level Editor
- Tools: plugins for popular modeller programs like Maya,ZBrush to export created objects/animations as data that is consumable by the engine
- Tools: any other tool that makes the work/collaboration of a game developer team faster

You may be surprised for example that I've mentioned here a sound system, what does a sound system contain? A PlaySound() funcion??? A good sound system may be capable of very powerful features that you wouldn't think of as a beginner. For exmaple if you are in a tunnel with your game character you may want some reverb on your sounds. Good sound libraries have 3D support, you can specify the location of the camera and you can specify a location when playing the sound and the engine automatically plays the sound well in a multi-speaker environment by using the location/rotation of the camera and the sound source (additionally the sound sorce may have angle, direction parameter, and so on...). A sound system among many other libraries is one that developers often buy as a pre-baked solution because it has a very well defined interface that doesn't really have to change for different kind of games, for example fmod is a very good general purpose sound system. Often buying a good pre-baked solution along with its sources + having a good professional in that area is the best you can have. If the solution doesn't have a feature or is buggy then you have a professional who can kick the ass of the library until it does what you want it to do... For some problems pre-baked solutions cover 90-100% of the cases (like in case of a sound lib) but in some other areas sometimes you need totally unique solutions depending on the kind of game: For example in case of physics, networking, rendering, animation, AI, particles. It has a reason that serious games are often written under the supervision of at least one specialized professional from each of these areas, by having a professional for each of these the limit in creativity is the sky, the technical/hardware limits, and the available time but not the technical knowledge. Still, you can create a lot of very good games with pre-baked solutions only. Many small teams and indie developers do that for example by purchasing a game engine like Unity. Unity is also a game engine that is glued together from pre-baked solutions. Its a gluecode between pre-baked libraries plus a set of tools that help people in collaboration and game creation. Even if you are purchasing a game engine you have to be able to choose the most suitable engine for the kind of game you are about to create... The game engine must be either well suited for your game or you have to choose one that can be customized for your needs/game with the least effort!

So... What you are about to do is learning about a renderer: ogre. In my opinion this is a very good choice when it comes to a renderer, I would also use ogre if I wanted to create my own game however before jumping into the middle of a game engine on a specific library first I would recommend you to learn the basics that is needed to glue together different libraries that are usually present in a game engine.

Fact: You don't have to be able to write the different parts of a game engine (like renderer, physics, sound system, ...) especially if you are a one-man army. What you have to know is the interface and the capabilities that these libraries usually have. If you know what kind of magic can be achieved by calling the public methods/funcs of these libraries that you can plan and predict what kind of games can you put together from the libraries you know well.

A simple game engine can support only 2D and only a few of these sub-libraries. If you are interested in rendering then you can learn rendering and you can choose a game that requires only minimal or zero knowledge from other areas. Another interesting thing: A space of the game logic can be 2D while you can still render it using a 3D engine using fancy 3D objects and effects (you can do that with a simply amoeba game). In fact, most cool games are 2D games because average people are more comfortable in controlling a 2D game. Physics is also simpler to implement in 2D and 2D physics can be more stable than 3D because of less degrees of freedom in case of your objects and 2D physics games can be really big fun to play! Consider this, a 2D game can be very-very competitive in both fun factor and in income on the market! You can still render the "game state" with a 3D renderer if you want!

Before starting to write any games I would learn the very basics, some 2D or 3D arithmetics. BTW, how good are you about basic 3D math? In case of 3D games I would recommend this as the very first book: http://www.amazon.com/Primer-Graphics-Development-Wordware-Library/dp/1556229119[^]
If you think you have to learn that book then don't forget to put into practice everything you learnt from the book. Write simple console applications that do some calculations and output the result on the console. If you have to time and the mood then copy-paste together some opengl code that visualizes your input data/geometry along with the result output.

After the basics you have to start to explore the interface of the typical libraries used for games, first its OK to start with simpler games that use at most one or more libraries of a typical game engine (for example a renderer). Again, you don't have to be able to write these libs alone, you have to be able to use them and you have to be able to write tools that shorten the development time. Becoming an expert in writing one of these libraries may take ages (5-10 years) but learning writing one such lib on a medium OKish level (that is already extremely useful!!!) can be achieved in half-one year if you are good and fast. If you can glue together different engine libraries (engine, physics, ...) into a usable game engine and you can write tools that can be used to build the game levels and you can create plugins for popular editors (like photoshop/maya) so as to make it possible to export data from these programs in the format of your engine then you are already a very-very good game developer even if you are not able to write any of the used libraries yourself (for example a hi-end renderer)!!!

Actually, I am in the same position (or even worse). And doing some background gamedev too.
And, being in this mess for YEARS, I highly DISENCOURAGE you to run more than two large projects at a time. The best solution to me is ONE activity that brings income (I have to eat, ok), and ONE other project. Currently I have to support far more than that, but that's a project lifecycle problems.

As for gamedev, I can only tell one thing: learning a new engine is a year of work and your particular task is (for a starter): 1 week of modeling (if it's a production-grade task), a few days of coding. In GoldSource those dots were path_corners :)