Next-Gen Game Engine Programming

Next-Gen Game Engine Programming

I am going to attempt over the next several months to build a complete Next Generation game engine, that hopefully will be pretty great. I have pretty much no experience with this, I’ve messed with the Source engine before, and the last few weeks I’ve been messing around in OpenGL and BulletPhysics so we’ll see where this goes. The first step of course is planning the architecture, it’s been a long time since I’ve used C++, so hopefully it comes back to me.

I want to build a game-engine that also includes a real-time editor (ambitious I know), in other words I want an engine that can run the game, and the tools, all using the same architecture. I’ve decided I’m not going to use any open source UI frameworks like qt or gtk+ and am going to build a custom UI framework that will function as both in-game GUI as well as make up the GUI for the tools.

So, we’ll start with the architecture of the game engine.

Every game engine is essentially a bunch of subsystems passing data between each other. The systems I’m going to focus on are:

Entity Management (manages the things in the “world”)

All of these systems will be controlled by a System manager which in turn is controlled by the Engine itself.

We will have the game code in a separate DLL, each tool will have it’s own DLL as well. The GUI will be a separate DLL that will be loaded in and will allow it to be used in any stand-alone applications. The GUI will need to have the ability to create windows, as well as open OpenGL contexts.

The path I see it taking at first, is the exe will invoke, create the engine, the engine will initialize the system manager, one the system manager has pre-initialized all the sub-systems the engine will figure out what it needs to do, load a tool, load the game, etc, and it will create the root context window. It will be up to the tools / game to use what the engine has available.

For this to work, we are going to need to create an interface for each system, as well as the engine itself. Each tool and application will need an invoke method so it knows if it needs to load. We also will need a console, and the ability for any of the dlls to execute an engine command.

I am going to be using Horde3D as the renderer but make the ability that this can easily be swapped out. Nothing but the renderer.cpp should have any Horde3D specific code in it, it should all go through the renderer.

I will post the architecture with some nice charts and the layouts for each system soon.

comments powered by Disqus