Why Do We Need an Engine?
What is the purpose or advantage of a game engine, as opposed to, say, just writing all the code for a game as needed? Why invest all the time in creating a game engine when you could spend that time just writing the game?
These are valid questions that I have pondered over the years while developing small and large game projects (especially those for college courses). The simple answer is: You don’t need an engine to write a game. But that is a loaded answer because it implies that either 1) The game is very simple, or 2) You already have a lot of code from past projects. The first implication is that you can just write a simple game with DirectX or OpenGL code. The second assumes that you have some code already available, perhaps in a game library—filled with functions you’ve written and reused. A game library saves a lot of time. For instance, it’s a given that you will load bitmap files for use in 2D artwork or 3D textures, and once you’ve written such a function, you do not want to have to touch it again, because it serves a good purpose. Anytime you have to open up a function and modify it, that’s a good sign that it was poorly written in the first place. (Then again, it’s possible you have gained new knowledge and want to improve your functions, which is valid.)
In my opinion, there are three key reasons why a game engine will help a game development project: teamwork, cross-compiler support, and logistics. Let’s examine each issue.
Teamwork is much easier when the programmers in a team use a game engine rather than writing their own core game code, because the engine code facilitates standardization across the project. While each programmer has his or her own preferences about how timing should be handled, or how rendering should be done, a game engine with a single high-speed game loop forces everyone on the team to work with the features of the engine. And what of features that are lacking? Usually one or two team members will be the “engine gurus” who maintain the engine based on the team’s needs.
Cross-compiler support is almost impossible without the use of a game engine. Although many programmers are adept at writing standard C++ code that will build on multiple platforms and compilers, game code usually does not fall into that realm due to its unique requirements (namely, rendering). Cross-compiler support is the ability to compile your game with two or more compilers, rather than just your favorite (such as Visual C++).
Advice
Writing code that builds on compilers from more than one vendor teaches you to write good, standard code, without any ties to a specific platform. It’s hard to write platform-independent code! Be prepared for a serious workout!
Logistics in a large game project can be a nightmare without some coordinated way to organize the entities, processes, and behaviors in your game. Logistics is the problem of organizing and supporting a large system, and is often used to describe military operations (for example, the logistics of war—equipping, supplying, and supporting troops). The logistics of a game involve the characters, vehicles, crafts, enemies, projectiles, and scenery—in other words, the “stuff” in a game. Without a system in place to assist with organizing all of these things, the game’s source code can become an unmanageable mess.
Let’s summarize all of these points in a simple sentence: A game engine makes it easy—sometimes ridiculously easy—to make a game. Contrast that with the problems associated with creating a game from scratch using your favorite APIs, such as Direct3D or OpenGL for graphics, DirectInput for mouse and keyboard support, Winsock for networking, FMOD for audio, and so forth. The logistics of keeping up with the latest updates to all of these libraries alone can be a nightmare for a game developer. But by wrapping all of these libraries and all of your own custom game code into a game engine, you eliminate the headache of maintaining all of those libraries (including their initialization and shutdown) in each game. The best analogy I can come up with is this: “Rolling your own” game code for each game project is like fabricating your own bricks, forging your own nails, and cutting down your own trees in order to build a single house. Why would you do that?
Indeed!
But perhaps the most significant benefit to wrapping an API (such as DirectX) into your own game engine classes is to provide a buffer around that API’s unpredictable future revisions. Whenever a change occurs in a library that you regularly use in your games, you can accommodate those changes in your engine classes without having to revise any actual game code in the process. Based on my comments already about the problems with compatibility in software today, this is an especially important point to take to heart.