• entries
    500
  • comments
    1888
  • views
    333131

More Design...

Sign in to follow this  
EDI

48 views

So I did some more tinkering and contemplation last night; I discovered that while the strict tree structure of 'State Nodes' at first seemed ideal, it led to a few weird inconsistancies; e.g. having a render function echo through _all_ of it's children would not be ideal if calling render from the root of the gamestate (the world object), which contains multiple rooms, we wouldn't want to render all rooms, just the one we're looking at, this would require overriding the render method in world, and doing the echo customly starting with the 'currentRoom'; this need for fine tuning via overridden funtions seemed to lessen the elegance of the strucutre, so instead I decided to go with a closer model to what the S3Engine used:



class StateObject
{
private:
unsigned long id;//index to engine objects array?
std::string scriptFile;//filename of script to use
public:
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 objects
public:
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?
Sign in to follow this  


0 Comments


Recommended Comments

There are no comments to display.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now