It's been a while, I'm busy working on Malathedra's story modifications, and on future (not the engine for Malathedra, I'm not touching it lol) engine enhancements.
It occurred to me a few weeks ago, that I write a lot of engines, personally I don't think there is a lot wrong with this, eventually I write an engine which is used for a game (Flare 3.0 for Morning's Wrath, and the S3Engine for Malathedra), however what is wrong, is that writing the same things over and over is just a waste of time, after enough engine writing you start to see components of game engines that can be isolated and turned into reusable code, code you likely never need to look at again :)
I finally decided to take a serious stab at componentizing a major part of *most game engines.
(*For all things considered this component should work well for C++ Windows platform Single Player, Platformer, RPG, Adventure, Side-Scroller, etc. type games, it is not designed for Multiplayer games or different platforms)
The main component is a Class called 'Core', it and it's supporting classes provide these features for very little code:
State Management:
The most important feature, the Core object stores a vector of 'Object' types, which serve as a base class for implementing your own stated objects (Map, Enemy, Weapon, etc.); the object contains a user-defined integer type id, and an integer instance id which is generated automatically and is unique within a given state session; the instance id acts as a persistent way to reference a state object in scripts and between sessions (serialization). Objects are created through a factory delegate (function pointer) leaving the host application in charge of defining type id's and construction of objects.
The core object provides functions for creating new objects logically (Object* newObject(int type,const std::string& script);); and functions for clearing, saving and loading the entire state; the Object class defines the virtual functions save(const OutputArchive& oa); and load(const InputArchive& ia); which can be overridden in sub-classes to save additional state; the passed Archive objects provide simple methods for saving and loading binary data, such as byte,int,float,double,std::string and Object* which saves object references.
Lua Scripting:
The Core also maintains a sand-boxed lua state which is also serialized; each object can have a script file bound to it and raise events on the script through the bool raiseEvent(const std::string& name); function. It has base features for pausing and waiting for scripted actions. The script API can be extended to add new script-callable functions (such as for the creation of objects). Each script is executed on a further sand-boxed thread, where all global variables defined are stored in the global state, yet the event functions are considered local and within the scope of an executing script.
Core Game Loop:
Handles the non-blocking message pump and frame-time sampling and limiting (to avoid massive time-based jumps or 'no time progress recorded' cases; a 'time passed' value measured in seconds is passed to each object's virtual update method, allowing for a time-based logic progression. Each object is updated automatically every loop (eventually an enabled property can allow turning off an object's logic). This 'update' event is also sent to the host application through an update method (function pointer) which can be used to process additional logic and/or render the state.
I believe this to be a really useful bit of code, and I am open to making it available if people want it; I'd like to also hear your thoughts/comments/criticisms; if anyone would like to check out the code feel free to contact me via a comment here, or via email Raymond@EDIGames.com
You betcha!