Learn what you need, as you need it, as you go along.
forget about object oriented C++ clasess. unnecessary overhead. unnecessary typing. and virtual methods are slower than non-virtual or regular code. use straight c code in a c++ compiler for the stronger compile time type checking. Use the standard C++ libraries and DirectX, unless you're targeting an Open GL only platform. for most PC's, DirectX is whats on the user's machine. If you ever plan on making games to sell, not requiring installation of OpenGL is a positive selling point. Also, vidcard driver support for directx is probably greater overall than that for OpenGL. And odds are there are more games made with DirectX than openGL, so any future project you become involved with will be more likely to use directx than openGL. While both are similar, already being versed in the one you're going to use helps. So even at the very start of a gamedev career, market forces influence what you do. In this case what poly engine library to learn.
Stay away from other libs like GDI, STL, templates, frameworks, and all that kind of junk. none of that stuff is for games, and just mucks things up.
I've been building games for 25 years. over time, programmers collect algo's into their "bag of tricks". code that they rely on again and again to get the job done. for making games, i've consolidated that bag of tricks into just 3000 lines of code that is a thin wrapper over directx. directx is rather verbose with lots of long variable and function names, and requires a lot of typing. The thin wrapper makes it less work: aniso(onoff) vs D3DSetTextureFilterSomethngOrAnother(Blah,Blah,Blah.........).
the "library" provides wrappers for directx, file io, mouse, windows message processing, keyboard input, string conversion, and random number generation. all wrappers compile inline.
the "library" also adds the following capabilities to directX: timer system; popup menu system; mesh, texture, model and animation databases; a limb based animation system; and matrix and string manipulators.
but the most important technology in the library is the drawlist. the drawlist queues all drawing calls, then sorts them based on the optimal order directx desires, then sends them off to directx for drawing.
these are representative of the types of capabilities needed in a generic gamedev library. As you can see, WINAPI, STL, MFC, GDI, and all the rest of that !^#@#%^$#*&^#@*%@!!!! stuff have none of this.
A minimal amount of windows API will be required to create a window class, register it, create a window, then go 3d and kiss windows goodbye! (yeah!).
a minimal windows message handler and window procedure will be required for mouse input.
as for what game to make....
well, the answer is obvious:
you make what you want to play and isn't already out there!
if you don't want to play it, odds are others won't want to either.
if you don't want to play it, you won't be motivated. might as well be programming databases for all the thrill you'll get at the end when you can use what you've built. if you're not motivated, you won't CARE about the project with the same passion, and the quality of your work will show it.
if its already out there, you don't need to built it, you can just go buy a copy and play it. in this case, building it would simply be an educational exercise. Nothing wrong with that, but another team has a head start, and it would be more work to eventually compete against them commercially.
Since you're just starting out and this will be for learning, not profit (at least at first), don't worry about whether there is already a game out there like it. this can actually be an advantage, as it gives you a working game to study and use as a reference for what you want to do. So simply decide what _FOR_YOU_ would be the coolest type of game to build, and go for it. I emphasize the "for you" because this will be key in keeping you motivated though the learning curve.
If the types of games you want to make are 3D games, don't waste time on learning how to make other types of games. there is very little in the way of game building knowledge from Tetris that transfers to Skyrim.
Also, if you want to BUILD games, don't waste time learning how to mod a game someone else has ALREADY built. While modding can be a somewhat roundabout way to learn how 3d games are built, its not the same thing as building one yourself (think "pimp my ride" vs a hand-built high-end Ferrari). And you get locked into the mindset of the designer of the engine you mod, thinking all games should be made this way. many is the time i've lamented the fact that Wolf3D/DOOM/Quake (and every shooter like on tthem) uses "levels" (level maps). now everyone thinks of game environments in terms of level maps, and that level maps are the only way to make a game. For anything you want to do in a game, there's usually a number of possible algo's, each with its own advantages and disadvantages, and its own capabilities and limitations. Learning game design by modding only exposes you to the solutions chosen by the engine designer for their particular application. If you build it yourself, the first step is to learn what algo's are out there, then pick one or roll your own if none is suitable. By doing so you learn about all the ways something can be done, not just one that may or may not be appropriate for the project at hand.
keep your favorite C++ book at your side, your favorite DirectX book at your side, the directx docs on a shortcut on your desktop, and GO FOR IT!
you may be looking up every single word in a line of code at first, and it may take a whole day to get 5 lines to work right, but keep at it, and you'll get there. eventually, it all becomes easy, especially if you spend 12-18 hours a day thinking 3d.
