Every game has other Options and so it makes not very much sense to hardcode the EntityStateT Options into the Engine code.
Yep, that's absolutely right.
My rough plan / idea outline was as follows:
should not exist at all. As it is, it just is a member of the
class, and all entities have to use it. This was done in the ancient past so that the engine "knows" the state of each entity, and can serialize, deserialize, and manipulate it at will / as required.
One way to overcome this is to let each entity have its own data members, just as one would expect with any normal C++ class. Each entity class would be free to define as much or as little data members as required and desired.
Of course, the engine still has to know the state of the entity, e.g. for sync'ing it across the network etc.
This can be achieved by adding pure virtual methods with roughly this signature to
Code: Select all
virtual void Serialize(SpecialOutputStreamT& Stream)=0;
virtual void Deserialize(SpecialInputStreamT& Stream)=0;
Each entity had to implement these methods, and the engine would call them whenever it wanted to ask the client to write or read its state from or to the special Stream objects. For example, and entity had to make sure that in it's implementation of
it writes all it's relevant state into the stream, and to make sure that
does the inverse: Read all relevant state data from the stream
Each stream would be a bitstream, and the engine would not be able to do something with it's contents, but it would
be able to delta-compress them, run-length encode them, send and receive them over the network, etc. etc.
This is something that I consider very important (in fact, even more important than the OpenGL 3.x renderer).
Alternative ideas, discussion, help, patches, ... all very welcome!