Skip to content

Engine Development – Basic Structure

November 4, 2011

The Dragon Engine is built with modularity in mind. It is designed to allow a developer to strip out large chunks of it’s default code and replace it with their own version. The engine is built on flexibility and ensuring systems can be easily optimised for whatever the developer wants to do. Below I describe the overall engine structure and I will aim to go into further detail with later blogs.

A system deals with a particular over-arching task that may consist of a variety of smaller jobs. For instance, the input-system handles all of the key and mouse gestures produced by the user. It stores the gestures in a queue and passes the input data to the appropriate classes that have requested it. A system is generally devised to enable the developer to either extend or replace the current version. Many of the systems implement an Interface that standardises how one should interact with it. Enabling it to be replaced with relative ease.

The Dragon Engine is built from a multitude of different systems:

The Game System can be considered the root of the engine, it pulls everything together and gets the ball rolling. The Game System contains a Finite-State-Machine that can be filled with States. A State can be extended to implement game specific logic.  When a State is added to the Game System it registers it to the Input System and Event System, it also passes it a pointer to the Game Window. The Game System will only allow one State to update at a time, ensuring that States cannot conflict with each other.

The Game System also loads the global Configuration file and initialises the Game Window. The Game Window is passed the State to handle its own Rendering and refresh times.

The Resource Manager is the gateway to retrieve game content. It provides access to the other managers that keeps track of content currently being used by the game. This includes: Models, Textures, Animations, Sounds, and Fonts. The Resource Manager is effectively a Façade that hides the more gruelling details of retrieving and storing the content requested by the game. Each resource is tracked by their respective manager, enabling content to be quickly cleaned up if space is required.

The Input System does what it says on the tin, it handles the users input and feeds it to the appropriate classes. The Event System operates on a similar basis as the Input System but it handles Events instead. An Event is a message from one object to another.  An Event is a list of relevant information that an object/s may find useful. It enables an object to send a message to multiple other objects without having to know anything about them.

The Entity System is contained within a Game State, it manages all of the Entities that are currently being used. An Entity is a game object that can represent anything within the game. This can be something simple like a door, to a complex AI operated NPC. It is built on a Component based design enabling a vast amount of flexibility. The Component structure implemented really requires a whole( or more ) blog post of its own.

As stated previously the Rendering System is contained within the Game State and enables content to be rendered onto the Game Window. Currently it only supports 2D rendering and is rather simple in its implementation. Though it does support alpha sorting and optimises the rendering list to ensure the minimal amount of binding. The Renderer is based purely on OpenGL and takes advantage of VBOs, however I have yet to implement Shaders, one day!

A recent implementation to the Engine is the Collision System. At the moment it only sports AABB collision detection with the aim to implement OBB soon. It also requires a moderate clean-up and some general optimisations as the system has a processing performance of (O)n. Which I’m sure you can agree is rather slow!

Well I believe that is most of the important Dragon Engine systems covered, though it does have a large range of support classes that are invaluable to its running. In particular the Settings class. Though for now I believe I have written enough.

Ross Forshaw.

No comments yet

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: