Actually nevermind: Game Coding Complete's source codes don't compile under Win10 / VS2015...

I got it to work on VS2015 last year.

How? I don't want to read both the book and the changes that have to be made in order to get it to work.. but your project works, thank you!

You can read the book as-is. The code is largely untouched, the "conversion" consisted mostly of rebuilding the relevant libraries.

Nice! So I can just grab a copy of it, study it while using your libraries and I should be fine, right?

Right, you should be fine.

Whether you've got VS2010, VS2013, or VS2015, that's covered -- it's almost the same code, and as far as the book is concerned, it IS the same code.

VS2010: official code bundle.

VS2013 and VS2015: unofficial forks I worked on.

(IIRC, there is/was also a VS2012 fork, but I never downloaded it nor worked on it.)

Then it's going to be: game. I won't use any game engine though, I'll just hard code it myself with calls to OpenGL maybe. It doesn't have to be awesome, just a player doing some stuff around

In general, to create a game, it's going to need an engine, whether the engine is an off the shelf one, or one that works only for the current game being made (ie, the game loop that your game runs on, etc.) Also, You're cramming yourself into a hole with having to write directly to a 3d API (OpenGl or DX), when you should be concentrating on what it takes to make a game 1st, and not have to worry about the overwhelming complexities of writing directly to those API's. Otherwise, you'll be bogging down so hard on just doing the rendering part properly that it will take you ages to get around to the actual gaming part.

Just because someone uses a game engine doesn't mean there's little actual programming left to do to make a game, there's still tons.

That's my advice, you can take it or leave it, but there's a reason myself and others who have been down this path offer this advice.

Good luck and have fun.

In general, to create a game, it's going to need an engine, whether the engine is an off the shelf one, or one that works only for the current game being made (ie, the game loop that your game runs on, etc.) Also, You're cramming yourself into a hole with having to write directly to a 3d API (OpenGl or DX), when you should be concentrating on what it takes to make a game 1st, and not have to worry about the overwhelming complexities of writing directly to those API's. Otherwise, you'll be bogging down so hard on just doing the rendering part properly that it will take you ages to get around to the actual gaming part.

Actually I've said so because I'm not (and cannot) interested in making a game that has tons of players, many characters, many maps... I'd be happy with one/two characters, one environment, plus maybe a dummy to attack.

That's my advice, you can take it or leave it, but there's a reason myself and others who have been down this path offer this advice.

I know, I know, that's why I'm replying to everyone and considering every advice. But using something too easy for what I want to do (say, if I use Unity, adding a character and a dummy would be easy wouldn't it?). Not trying to code the next Overwatch (man, that game is awesome), but just a few things here and there... as you can see, I have to clue on what's gonna happen, so that's hoping you can say :-p

Good luck and have fun.

Same to you!

The advice is valid and I have the same isue. But if the goal is to build a engine for your games. The advice is to make a game and engine wil show up after iterations and refactoring to reusable architecture with split of framework to engine and the game specific part.
That make sense!
But instead of Game to show of your engine. I think that needed for large engine team who there engine is the licencable product need a game that show of the game engine.
You get a full game which feel like tech demo but is full game. IDsoft first games of each IDtech engine.
That make sense!

But we are beginners. Not big engine building studio or team.

It doesn't have to be a full game.
But a short basic barebone short core feature showing tech demo.
Like short minimal feature playable game.
That means your first version of your first playable tech demo.
You need only the most needed features to get this first minimalistic game running and full playable.
That means it will very light on content. Using simplistic asset done by engine programmer.
No need for content production pipeline. Because that get hard needed when you go for full game and need lot of assets and levels etc.
Choose if simple MPlay like splitscreen. Or NPC not both at ones. Add one feature per iteration.
Or shooting NPC which are light on AI. Like astriods for space shooter. Zero AI needed.
Go for pure procedural first so the need for artist is low .

That the plan I go for.

Also often these example source code do work. But if not debugging and get working is big learning experience. Also what I did is rip a depricated math lib out and put the current in.
Go from 32 bit build to make it 64bit build.
And I drop the 32 bit.

I got both books. But they are bridge to far. But shows what is the end road and it a lot of features big and small. So long road to go.
Like they both mention memory management. Like my old dev PC is a memory limited platform. Not for the first 100 iterations for a demo. It got 8GB with old quadcore from AMD. It not the sinclair ZX81 where you bound by extreem low amout of memory.
And for the first low number of simplistic dummy asset a big enough memory waisting memory pool wil work. For now. And Reusing objects.
How ever at some point where you get to make a full game the asset needs wil grow and memory footprint grow and then more advance memory management is needed.
Also where you come at point to release a demo, having memory management keeping using to much might make your target audience smaller. But then again its tech demo.

I would priortise features from the minimal game demo and add and refactor for the next feature that make the most sense like depend on existing implementiation of features.

A good example are astriods. No AI as they are not NPC and no Mplay needed. To make it chalanging there can be a lot and moving fast. At some point there comes a enemy space craft but not before static mines. Then defence satelites.
For FPS shooter Classical zombie. No need for advance AI. But before that to avoid animation, some low tech robot like man size big vacuum cleaner but with a weapon.
After the 250 next feature itteration the demo have nice feature pack so does the engine .

In my case I go first for the most abstract and feature poor minimalistic abstract space shooter tech demo, that could grow to big genre merger and stil be in demo low asset state. And sticking with procedural content.

Questions like these pop up all the time. I think that the best way to actually learn game design is to learn from your mistakes. You can ask all the questions you want, and some may help you, but overall you need to develop games, receive feedback on the way you programmed the games by posting the source on an open-source repository, and learn from what everyone suggests. As you continue to develop games you'll get an understanding of what architectures will work better than others and you can determine what architecture would work better for specific situations. There is no specific way to design a game's architecture, there's only very general principles. You'll need to experiment for yourself to learn what is truly best.