Hello Everybody, Earth Otherwise here to continue our journey into Game Programming in C++: Start to Finish by Eric Yuzwa.
In this, the first part of the fourth chapter the book seeks to teach us about game engines and their uses. Games engines typically handle graphics for the most part, though often they will include things for input, sound, networking, AI, and more depending on how robust the features of the game engine are.
Most commercial games are built atop a game engine. Some famous game engines include Unreal, Frostbite, and Unity. When making ones own game engine we must consider how specific, general, and robust we wish to make it. If we go to far in any of those directions we'll end up wasting our time, so it's something we should consider carefully.
Ideally your game engine is modular enough and robust enough that you can apply it to most projects with minor tweaks, but there will no doubt come a time when your engine simply isn't the correct one for the job and you will have to use another. You must always consider what's best for you game. In fact, if you simply wanted to make a game right off the bat then choosing to design and code your own engine like we're doing now would be the absolute wrong choice.
Fortunately for us we aren't interested in the quick route to success. Instead we'll have complete control over our engine's limitations.
Throughout this book we'll be adding to our engine. Indeed so long as you are using a custom engine you will probably continue adding and modifying it to suit your needs. The engine that GPiC++ seeks to help us create will be relatively light weight, and hopefully will be easily modified for the kind of games we'll want to make once we understand fully how to do so.
Now, let's go over the parts of the engine that we'll be seeing later in this book. The EngineCore is what this book calls what we did in the last chapter. In the instance of this book I believe that the input, window, and error handlers were all in a single .cpp file. Clearly we did not do this, since code modularity is important. The EngineCore is responsible for launching the game, opening a window, starting up SDL, and sending us into the main game loop where it will handle our inputs. It's also responsible for loading our other engine parts.
Obviously our classes don't currently do this, but later on we'll probably use the .h file that shares our engine's name to act as our main loop which our game will call.
Next up is our AudioEngine, which, as you can guess from the name will be handling our audio. Now, just as our EngineCore we'll probably have several files with several classes which will make up our AudioEngine, but this book treats them all as a single object. This book uses the audio mixer in SDL which I have heard works fairly well. I'll also be inserting the audio information from Ben, of course. OpenAL is also used, the audio equivalent to OpenGL. This is covered in chapter eleven.
ScriptEngine is next. It's a small component of our overall engine which will take in scripts when we launch the game. Scripts, for those who don't know, are essentially simplified code snippits that you can use to program parts of your game without having to recompile the entire thing. An example of scripting that we've already done is our InitFileReadWrite class. GPiC++ uses the Lua scripting library which will be covered in chapter 19.
SceneRenderer is another core component of the Peon engine that the book uses. It is the interface between the game and OpenGL. The book talks about this in chapter 6.
SceneTexture is a container for texture information and is used by the SceneRenderer to put textures on the screen.
SceneFont is the same as SceneTexture, but for words and letters.
SceneGraphManager, which we'll find in chapter 8, is a class or group of classes responsible for speeding up our calls to the SceneRenderer so that drawing to the screen is quicker and more efficient than calling everything one at a time. It will also aid in physics and collision detection.
NetworkEngine is the multiplayer aspect of our game engine and something I'm sure we're all curious about. Everybody wants to make the next multiplayer smash hit. We'll learn about this in chapters 14 and 15.
ParticleEmitter is a simple particle generator for things like explosions and fire.
Shockwave is a fun little subsystem that will give us a little effect that we can apply in game.
And those are the basic parts of our game engine. When each part is activated in the main game loop it will be put into an active state. Different parts of our game will be part of different states. For example, will will have a state that tells the game we're in the main menu, or that the player is active, or that they are dead, or in the system menu. This is how the game will know to switch into different loops within the core loop.
Now, as any google search can tell you, state machines can get big and cumbersome, so what the peon, and our, engine will do to combat this is use an application and applicationState class to keep things orderly. How it's going to do that is as much a mystery to me as it is to you. Let's keep going.
Now we move into the realm of timeboxes. Defined by this book as a defined goal with defined resources including time. Now, we aren't going to define how much time it's going to take since we're all busy people, but we should draft the list of requirements for basic functionality. Fourtunatly the book gives us an example.
1: Initialize and start up the application.
2: Create some state container that we will fill in as development progresses.
Well, that seems pretty easy. We've already completed the first one, and it shouldn't be to hard to create a simple class to handle our states. In order to figure out what we'll need in our state manager we'll need to think of what states the game can be in. Some examples are provided.
1: LogoState: Pop up a company logo on screen and maybe play a little jingle.
2: MainMenuState: Load in and display our main menu as well as provide the functionality required of a main menu including the ability to change settings.
3: RunState: Basically just run the game. This will likely be broken into multiple substates.
4: QuitGameState: Clean up everything in our game and close down. Probably check to make sure the game was saved.
Now that we have an idea of what we want, it's time to move onto the next video and create our UML diagram.
▶️ DTube
▶️ IPFS