... after I take the childish smirk off my face for saying the word that reminds me of something else, today's topic of self-discussion will be that of entities.
I'm currently playing around with making a general purpose Entity class for Manta-X as I feel as if the current implementation doesn't quite cut it. You can tell I got a copy of GPG2 as this general class has some extra features I never even thought of including. It has:
User extensible attributes
Each entity base inherits from a PropertySet which in turn contains attributes. The idea is lifted straight from GPG2, but was influenced highly by Vollmann's paper on "Metaclasses and Reflection in C++". The main aim, as it were, is to have an entity class that can be used within the game and extended via scripting. Part of this extension mechanism includes the ability to create new attributes on the fly for entites, giving a lot of freedom to the game designer (me).
User extensible script methods
In addition to attributes, I'm now looking to add new methods to the entity metaclass at runtime using scripting. Again, this allows a whole load of extra niceties if implemented. This feature isn't high on the priority list, so it might not actually make the cut.
Embedded State Machine
I got tired of using switch machines for my state logic, so have embedded a FSM in the heart of every entity. This state machine is extensible via functors to the new state transition and execution functions. At present, states are embedded but the ability to hook and remove external states is simple to implement from here.
Entity is a Scene Node
Entities now have the characteristics of a SceneNode. I didn't like my previous implementation of SceneGraphs and would prefer to (rightly or wrongly) reduce the amount of composition I had in the SceneNodes. Naturally, I'll need some degree of composition, but the SceneNode concept is now ingrained in each entity and as such, they now have a parent and multiple children attached to them.
Entity is a Message Processor
As this class is designed to be extensible, I've added a message processing core to each entity. Instead of relying upon a static interface o each entity base, the user can now customise entities greatly via additional message handling functors for the entity. Messages can be cascaded down to children, which alters the traditional paridigm I've been working within. Now, an entity will react to a collision via a collision message, it is up to the entity if it cares or not - if so, it can broadcast a ENT_MSG_DAMAGE message to the world and the rest of the entities will decide how they're affected by it. This system will make way for many extra features and entity types to be added without the dreaded Double Dispatch patterns I've used in the past. I will also build in the ability to call a scripted event should it be needed, allowing script writers to potentially overload any entity message (outside of the core messages) and add new ones via script.
Entity has a Flyweight Component
My traditional notion of flyweights has been challenged by the GPG2 article. Instead of using a flyweight that holds position, etc information, I am likely to make the flyweight some form of media manager that controls how the entity is rendered and/or animated. The reason behind this is that I should be able to add model, sound and animation frame management as a component to the entity rather than use inheritance to force an entity into a particular type class (renderable, audiable, animatable, etc). I haven't toyed with this idea at all, but it seems a logical step to take when needing generic entities.
Entities are Serialisable
Entities will need to be easily serialised. Right now, I'm considering Xml or using the data definition abilities of GameMonkey. I'm undecided as to which one to take right now, but the entity class needs to be easily completely or partially serialised to/from disc and network resources.
That's what I'm going for here folks... a multi-purpose entity class that is alterable via scripting, messaging and property maps. I've got a lot done, time to work on the media manager.
