I was wondering if somebody could tell me how the game and the game engine fit into game development. What I specifically mean is, the game engine does not actually contain a game. Do game developers build an engine, then create a new class that inherits from the engine, which becomes the game?
For example,
class ShooterGame : public Engine
{
};
I'm not sure about where the game code fits into the engine.
Don't get caught up on the concept of a "game engine". While it is true that game studios often have some sort of game engine which they create in order to speed the process of producing games, many independent developers get hung up on trying to create a game engine that they never actually make something that works.
A game engine can be whatever you want it to be. If you find enough in common between your games that you can subclass an Engine class like your example, that's fine. If an "engine" is really just a small library of functions which you've found to be handy in past games you've developed, that's great too. Whatever it means to you, the concept of an "engine" is just reusable code to help you make more games.
If you're trying to make a game though, don't focus on making an engine. Make a game. Once the game is done and you're ready to make your second one, start making the second one, and you'll find bits that you already made in your first game; then you can extract those bits into a library or engine, to be shared between the two games. That's how an engine should be made. It's not typically something that you decide to write before making a game, because you'll end up with tons of code which is untested and you are essentially writing things before you know you need them (therefore you might not even need them). This is like premature optimization, but worse.
So to directly answer your question, basically a game engine is a reusable "thing" (library, tool, framework) which a game studio uses to aid in quickly producing games, and they typically create it with specific games in mind or after having created several games, extracting out the similar bits and moulding them into an engine which they know can be used in future games. It should almost never be created without either retrospect (two or more games already created) or EXTENSIVE planning.
basically i'm unclear on where the game code fits into the engine.
Don't worry: I've worked professionally on games where we were all a bit confused on where the game code fits into the engine. ;)
I find myself saying this a lot in game development, but there is no standard system or definition for this. Some engines (typically for quite simple games) let you create new games without writing any more code at all. Other engines are basically a skeleton of an existing game and you must alter the code in-place to add your features. Some are like your example and are collections of classes which you can subclass or aggregate into your own system. Others are more like libraries of code which you add to your own application and make use of as necessary. The only thing they have in common is that the engine is the part of the system that is suitable (or claims to be suitable!) for multiple games.
I'm sure there are circumstances where people have done as you have above, but personally I've always favoured engines as a collection of libraries, with bits you can pull in as needed. That would ultimately give you more flexibility of choice to swap different components in/out based on their suitability to a specific type of game (i.e. you could choose a 2D or 3D physics library or renderer depending on the type of game) without having to have all the other alternatives resident in memory, or you could choose between a rendered based on DX9/DX11/etc).
