Yea well, for basic mudlibs its fine to store data in clientr.flags as long as its small and use a function to access the right index depending on a variable name.
But for Aeon, the system is alot more extensive and I'm planning the revamp it anyhow. First we would have the base MudObject and it would have certain joinable Qualities which would be comparable to Interfaces in Java.
Qualities List:- Breakable - This quality is for objects that have a health and stop working properly when the health gets to 0 or so. This includes players, npcs, and certain world objects like gates that can be broken, and even weapons that degrade over time.
- Class - This quality is for objects that have a player class. It controls attributes and skills for players and npcs.
- Container - These are things that can hold inventory objects and has the functions to manage them like AddItem() and RemoveItem(). This would include players, npcs, and world objects like barrels and chests.
- Drawable - This property is for objects that can appear in a level and would dictate how they appear in the level.
- Enchantable - This is for objects that can be enchanted and would reference a magic effect list and determine how those effects apply to this object.
- Equippable - This would obviously be for objects that can be equipped by the player or other npcs and would have have functions for finding slots and triggering events when an object is equipped.
- Inventory - These are objects that can be stored in an inventory and would have certain values like GoldValue, Weight, Type, StaffItem.
- Magic - This is for objects that have a group of magical effects like spells and potions.
- Named - This is for objects have a name in the Mud System, players, npcs, world objects, items, spells.
- Player - This is the player quality and controls things unique to players in the system.