Game Engine: Architecture Update

After struggling with “ownership” architectures, I finally decided on an “ownership of responsibilities” layout that I think will work now and in the future when the game engine gets more feature complete.  I did some more research on the topic of global vs singleton vs non-global approach.  The general idea is that most people never use singletons correctly and globals should never be used anyways.  I do agree with this for the most part but I think it is a little overkill to say that all global-type variables/classes are evil.

In the case of the renderer, it almost has to be global (or be a singleton) because 1.  It needs to be accessed by SOMETHING and 2. You should only ever have one (or you’ll run into two+ renderers fighting for control and reintializing windows).  A singleton would work for this I guess but for the time being I’ve taken another approach.  Some time ago, I somewhat implemented a component-based system object system.  It isn’t 100% component, but it gives me enough freedom to do what I want and to seperate responsibilities if needed.  It isn’t used very much in the way component-based systems are supposed to be, but it has organized object creation a lot.

Currently I only have three components that can be added to a class.  Here, objects aren’t created dynamically (something a true component-based system would allow) because while I like genericity sometimes, objects just seemed to be a collection of objects that had no connection to eachother other than that they occasionally pass messages back and fourth.  Another reason why I didn’t want to go full component-based is the messaging system itself would be a great pain in my side.  So, to define an object, you simply declare variables of each component you want in the class schema.  The three components are RenderingManager, PhysicsManager and InputManager.

The InputManager deals with all input.  The only game object I have, the player, doesn’t actually use this component directly.  Another component PlayerInputManager, uses the InputManager to create a mangeable interface between player input and actions.  For example, pressing Escape sets the bExit boolean to true in the PlayerInputManager (which is a variable in the Player object).  This will also allow me to create a Key Binding system easier.

The PhysicsManager handles all of the physics properties/objects of a given game object.  Currently, I don’t have an wrappers for the actual classes contained in Chipmunk Physics (the physics engine I am using) but the PhysicsManager acts as a wrapper to the functions of Chipmunk.  This component is responsible for creating rigid bodies and adding collision shapes to that body.  Later on, the Level object cycles through all of the game objects in the world and adds each rigid body and shape to its physics space.  The handling of the creation of the rigid body and collision shapes is handled through each parent objects constructor. 

The RenderingManager used to simply hold the rendering location/rotation/scale and a couple of other properties and methods but now this component is responsible for everything to do with the Renderer.  It holds a list of models, model names and model offsets as well as functions to draw the models.  This means that the Main method is no longer responsible for dealing with rendering at all.  The Renderer is -still- global however, and currently I see no problem with that.  Later on, I may move to a singleton system.  It is only a problem if I start access the Renderer again from outside the Rendering Manager, and I will only do that if I want to test some rendering stuff.

Currently, Main still holds a reference to the PackageManager, which isn’t a component that can be used by game objects.  Since I’ve moved total control of the game world to the Level entity, I will be moving the package manager reference over there I believe as the Level will have to preload all content and what not.  I am unsure about this decision though as I will need a seperate Menu entity for authoritative control over rendering menu items.  I may leave the Package Manager in Main and keep a list of content that needs preloading in the Level entity.  Then I will go through the list and preload each asset from Main.

At any rate, the engine is FINALLY shaping up into a workable state.  I can soon start doing less behind the scenes work and more game work.

Advertisement

---