Base Game Objects and Interfaces

Jun 9, 2013 at 10:54 AM
Original Conversation

I warned you that I was going to bug you with questions... :P

(Note: I wanted to pull this out into it's own thread just to make it easier to find. )

Base Game Objects:

After our recent conversation(linked above) I dug into the Environmental folder and had a look at the base classes and interfaces there. I am still seeing the over all design problem that I noted before, which essentially boils down to, you have too much junk to the base objects where it doesn't need to be tied too, and your interfaces are spread thin when they could be condensed or at least organized in a more logical manner. (The ability to later override the functionality shouldn't keep you from grinding down the design at the lowest levels to minimize the need to do so) That is not a critique against you guys, just something that I can see being headache further down the dev track.

For example:

In Muds, you essentially have three types of objects. Containers, Items, and Links. All containers share many, many similar properties, and can thus be grouped together and differentiated via sub-classing.

Containers - Realms, zones, rooms, mobs(including players), backpacks, chests, and ride-able objects are all containers.

Items - Generic items like weapons, clothing, and final raw materials are all items. In short, anything that cannot contain anything else.

Links - These perform the same basic function as your 'doors' class, and have many of the same properties.

The benefit of this break down is that you can minimize the number of interfaces that you need by grouping the core functionality together. So, using this template, we get some pretty solid examples:

IContainer: IEnvironment
    public string name{ get; set}
    public int ID{get; set}
    public bool canHoldItems { get; set}
    public bool canHoldContainers { get; set}
    public bool canHoldLinks { get; set}
    List<IItem> Items[]
    List<IMob> Occupants { get; set;}
    public int ParentID{get;}// The container containing the container.        
Now, while this looks very similar to what you have already, notice the one major difference: These can be applied to ALL container objects, not just rooms OR realms OR zones OR mobs OR backpacks... the same getter setter methods that you are currently using separately for each individual could be conglomerated down into a single interface.

Again..this is VERY similar to what you have already, but long term should reduce the size of the code you have to manage tremendously. Where you would start to see differences, unless I am completely missing something here, is when you start dealing with mobs, inventory, and other types of containers.

For example:

in IContainers : IEnvironments
  List<locations> Locations[]{ get; set} // could be used to create inventory slots, equipment slots, locations within a room which are semi-private, pockets within bags, etc
Instead of having to recode all of the container processes, they should be inherited from the Container class. Codewise, what is the difference between a player moving between containers, a room being moved between containers (relinking), and an item being passed between containers?

Right now, there is a lot of duped functionality that could be reused simply my moving it up one level instead of rewriting it for every application of it, particularly between the different Environments and between Environments and Mobs, and there is no real need for it.

Notable examples:
Inspect()(Move to a command)
health & CurrentHealth(combine with IStats)
IStats(The entire interface could apply to any object)
IAppearanceAttribute(The entire Interface could be be used by any object, with a few modifications)
IDoor(the entire interface could be used for any container(Though I would probably remove the get/set facing directions as unnecessary if you are saving the exits as a list))
The senses section of IRoom could be used for all objects. Much of the ADD/Remove Item/Character/Link(Door) functionality to could moved to an IContainer and be reused for various things.
I am not even sure what you are calling decorations here. There is no documentation on it.

You guys probably have very good reasons for doing things the way you did. These are just my thoughts and observations from what I have seen. To my way of thinking it would be easier for the devs/world builders to restrict the functionality later than to create additional functionality that was not in the engine to begin with by the simple expedience of not using the function calls for the functionality that you don't want. The more streamlined the code is the easier it will be to maintain. Or, just tell me to shut up and code something :P