The Metaclass system as it stands would be suitable for creating entity 'classes' and then building objects from them. Each of these can have properties attached and dettached as required, meaning that it's a dynamic environment, much like a scripted object. In fact, one of my 'todo' extensions on this is to add in native GameMonkey scripting so that any object could be effectively scripted; the nature of the system should mean that this is a doable feat.
However, I recently decided to think of things other than 'classes'; in effect the fact that you define a singular class for an object is pretty idealistic. C++ gets round this to some extent with the whole multiple inheritance thing, but I don't really want to throw that in to my MetaClass system. I could, any probably will, provide the ability for a user to build an object from various prototypes (a class in the system is basically a prototype object). However, what if you need to change 'classes' at runtime? In effect, when does a "LiveObject" become a "DyingObject" or a "DeadObject"?
The multiple inheritance paradigm doesn't really lend itself to this fluid nature of objects in dynamic systems, especially those of a game. People often get around to building state systems into their objects, so that our object then becomes divorced from the classification of Live, Dying or Dead and exports this as a state. All well and good then, but what if the object needs to be of multiple states? Especially if these states are fuzzy in their nature? You could build up a complex system that lets objects do all this, but it could become confusing.
My solution to this is actually based on document and file management systems; what if you forget the notion of states and even to some extent classes (a class becomes nothing but a prototype) and implement tagging? An object is recognised as an object and nothing else - it becomes an entity that has attributes which can be added and removed at will without violating the concept of 'classifications'. The tagging system replaces the notion of states by allowing you to categorise these entities. Objects could be assigned various different tags depending on what you need them to do. For example in an RTS game we have a group of units available to the player. They'll all be part of the same squad but each have different attributes, models and unit classifications. They can all be tagged with the "Squad_01" tag as they're in the same group, but then the three tanks in the group are tagged with the "Tank_Unit" tag, the infantry with the "Infantry_Unit" tag and so on. But then, the player will have more tanks available to them in other squads - each of these tanks would have the "Tank_Unit" tag to say that yes, they are also tanks. Within the tank category you have large tanks, medium tanks and small tanks. You could have tracked large tanks, wheeled large tanks hell even flying large tanks - and then you have the weapons given to these, powerful, medium, weak - laser, plasma, shell - etc etc You get the idea. Each one of these units would be tagged with the various tags to identify them; these tags do not have to resemble their attributes, they're just a way of classifiying the units.
And so from here, you can see that the player may need to say "select me all my tanks with a blaster that aren't assigned to a team" - how do we do this? This is where the game database concept comes into play - you need to be able to retreive units with specified tags from a global list of objects. With the database system it would be case of traversing the tag lists to find the objects that match. This idea starts to mesh well with my metaclass system; remember how I said that our entities all have attributes? What if, we build in a system to query these attributes along with the tags? "select all tanks that have a blaster and a health bar above 70%", for example.
I think this is the way I'll be pushing my metaclass system now. I am currently exploring the ability to query these attributes and tags, as well as the possibility to execute SQL-like commands to update, create and delete objects within the database. I say SQL like, this IS NOT a SQL database system and never will be. It is likely that a simple query language may be used at some point, even if it's just pseduosyntax to help convey the meaning of operations.