In a program like a game, there are portions of the logic which must be very fast, such as the actual 3D computations or the rendering-process itself; and those which can afford to be much slower, like the game decisions themselves. (The video must match the speed of the eye, whereas the game must match the practical reaction-time of the player.)
So, you often come up with a “hybrid” approach, the so-called “game engine” or “game construction-set.” The high-speed dirty work has already been done for you, and it has been done very well. In other words, a very stable and complicated display can be reliably presented at “sixty frames per second.” Now, on top of that platform, you build your game.
The best place to start is … take, say, Blender and actually build a game. Any game. Remember that Blender was originally built to produce professional-quality games. Use Python, logic-bricks, the whole nine yards. Experiment with techniques. Go as far as you possibly can until you absolutely run into the limits of the tool … which might take a long time, or which might never happen. Now, explore other techniques… but don’t re-invent any wheels.
By all means, learn from examples. Take an existing game that has been published in source-code form on the Internet and study the source-code. Learn from what others have already done.