There a tons of good tutorials online, but they usually only show a how to do one specific thing, and aren't that great at showing the 'big picture' of how everything fits together. Even the books I've looked at or purchased on the subject don't do a good job on this (or don't even try), and instead show you how to make each little piece, but not how to put it all together. The "how everything fits together" part is the most important. IMO.

I think the 'big picture' architectural design of programs is actually the hardest part, which I'm guessing is why there is such a huge lack of information on the subject. It's something I've been struggling to learn myself, because I basically have to trial-and-error rediscover it on my own from a lack of good guides.

The only advice I can give, unless someone can point out a real book that actually teaches software engineering architecture, I can only suggest that you learn from actual practice by doing, and re-doing.

If someone can recommend a real book that actually teaches software engineering architecture, that would be grand. I don't mean, "Here's how you build this piece, and here's this piece", but "Here's how you can fit any piece together in a clean and organized way" - Again, many books claim to teach the latter, but actually teach the former, so be on your guard.

If all you are wanting is the "Here's how you do this, and here's how you do that" without the big picture, there are plenty of resources online. For OpenGL, try here. For anything else logic-related, basically just google it, as the information is scattered all over the net. (Things like "C++ physics", and "OpenGL fire", etc...)

Start with sth. simple.
I mean Unity3D or XNA.

There is a lot of XNA and unity literature, but I suggest to start here: http://www.google.com

Well, he's already started on C++ and OpenGL, he says he already knows the basics. Having him switch languages instead of going deep on the language he already knows plants a bad seed of 'language hopping' instead of actual development of games.

So you're suggesting that I should look much tutorials and combine all my knowledge?

I'm suggesting you work on games and gain new practical knowledge through experience. When you have a question about something specific (such as water reflections), you don't need to go buy a book on the item but can just use tutorials or articles. If you are looking into a whole topic (such as "OpenGL as a whole") then you can mix a book or two with plenty of online tutorials and articles as well.
And I'm suggesting you put what knowledge you've already learned into practice by getting your hands dirty. Knowledge with practice and real-world experience is much better than just knowledge on its own.

Plan out the basic flow of your game, and just start getting your hands dirty with it. You'll inevitably make some poor architecture decisions, but on a small project that's alright, and you'll learn from it for the projects that follow.

I totally agree with that big picture problem as I faced the same. In my case learning the bits and pieces and then spend some time to really understand the OOP part of C++ is what made me connect the dots. It suddenly made more sense to "submit a creature to the render class"
or stuff like that. Even the OOP tutorials that teach composition with abstract examples like a car that has an engine and doors made more sense in retrospect although initially I found them lame because I couldn't see any link between a car door and software programs. The concept of finite state-machines is very insightful too.