A Game a Month 2: Engine Architecture & The First GameObject

I know what you're probably thinking.

1 - What does he mean engine architecture? Isn't he using Irrlicht Engine?

2 - If he's doing his own architecture, why would he use GameObjects?

Well, the answer to the first question, is that Irrlicht is very much batteries-not-included in a lot of ways. While it's way more fleshed out than just a rendering engine and provides most of what you need to get going, it's also pretty unopinionated, and does not provide the basic architecture for your actual game logic. Where Unity provides GameObjects and Monobehaviours (or DOTS ECS), and Unreal provides Actors and Components, Irrlicht simply does not fill this gap. Which I am enjoying, because it means my system for the same thing can be lean and really only what's needed for this game.

That leads into the answer to the second question: why use GameObjects and Components when ECS is so much better?

Well, I am making one game with this right now, which is a boomer shooter, and does not need insane performance. In the respect that I'm trying to build these games rapidly, what lets me prototype the fastest and get to the point of building the game and not the game's underlying architecture is best. One of my goals is to have at least one of these projects integrate FLECS, but this just is not the one.

Now, let me walk you through my progress so far. This is not super clean amazing code, I have had little spare time for it and I am going on 60 hours awake (with one 2 hour nap) due to baby duties, but my goal here is simply to land on a game that works.

Currently, I have 2 namespaces

RunkGameCore

RunkGameCore has 4 classes:

Component

•  Has Tick, OnCreate
• Is responsible for reusable logic across game objects and ideally should be used for all logic
• Is ticked by the game object directly
• TODO separate components by Scene Components that have a node in the Irrlicht graph and Behaviour Components which do not, and transparently wrap the root scene node of the component's transform with convenient functions

GameObject

• Has Tick, OnCreate, InitializeComponents
• AddComponent (templated)
• To be extended in games with overridden InitializeComponents to create reusable object types \
• Ticked by GameObjectManager
• Always has a root SceneNode that it manages, classes which extend it can add more and as well components can add more
• TODO transparently wrap the root scene node of the gameobject's transform with convenient functions

GameObjectManager

• Responsible for ticking game objects
• CreateGameObject (templated, accepts additional args as well)
• DestroyGameObject
• Tracks objects in maps by root node, id, name, etc

GEngine

• Currently, this is a singleton that holds global references to all the Irrlicht stuff that is created in main.cpp
• Named because I'm uncreative and tired and GEngine is what Unreal uses for something similar
• Major TODO is to bring out the code that initializes Irrlicht and operates the main game loop into this class instead of main.cpp

RunkGame has 2 classes right now

TestGameObject

• Object whose default components (defined in initializeComponents) are a cube and a RotatorComponent set to rotate on the up axis at 45deg/s

RotatorComponent

• Component that rotates its parent object around a given axis at a given rate per second

I've taken one of the basic examples, gutted it, and added a call to the game object manager to create one of these TestGameObjects, made the main game loop calculate deltatime for framerate-independent functionality, and lo and behold, it all works perfectly:

So, tomorrow I'll be cleaning up this whole main.cpp situation to make GEngine responsible for all of that and streamline the process of getting a game working with RunkGameCore, rename GEngine to something a little more original, and setting up all the lovely wrapper functions to interact with the scene nodes through the new object and component types themselves. I'll also add some transparent object pooling that's configurable in a header file for how many objects of each type to pool by default, because I know I will want it for projectiles for sure. Then, I'll write the basic FPS movement and shooting.

I'll have the whole RunkGame project up on GitHub probably by the next post, I have a lot of stuff I want to just tidy up before I do so here with what I have now. But this is a nice start!

Alex