class StateObject{private: unsigned long id;//index to engine objects array? std::string scriptFile;//filename of script to usepublic: virtual void save(OutputArchive& oa); virtual void load(InputArchive& ia); virtual void update(void); virtual void render(RenderingBatch& rb);};class Engine{public: std::vector> objects;//full list of objectspublic: void saveGame(const std::string& fileName);//head-method for world->save void loadGame(const std::string& fileName);//head-method for world->load SharedPtr getWorld(void);//returns index 0 from objects table};class World: public StateObject{public: std::vector> rooms; SharedPtr currentRoom; SharedPtr watchedActor; SharedPtr currentActor; public: void save(OutputArchive& oa); void load(InputArchive& ia); void update(void); void render(RenderingBatch& rb);};class Room: public StateObject{public: std::vector> actors;public: void save(OutputArchive& oa); void load(InputArchive& ia); void update(void); void render(RenderingBatch& rb);};class Actor: public StateObject{public: SharedPtr room;public: void save(OutputArchive& oa); void load(InputArchive& ia); void update(void); void render(RenderingBatch& rb);};The main difference is that the World object inherits from StateObject wherein this was not the case in the S3Engine. By having a tree-ish structure by each node subclass having it's own potential set of custom children, gets rid of the 'one-size-fits-all' approach of having a straight Children array.
The StateObject contains base functions for serialization(save/load), update (simulation time progression) and Render(visual reperesentation), it also contains the id (which is a direct index to the linear object store for easy retriveal) and a scriptFile string; each State object will have a potential script associated with them to provide custom coding for events the object raises.
So far so good :D
Thoughts? Comments?
