22 Feb, 2010, Kardon wrote in the 1st comment:
Votes: 0
Hello all,

I've been trying to design a framework for building a SUD/MUD in C# and had a question about how to properly design a generic mud object that items, mobs etc would inherit from. Would it be proper to create a "MudObject" class that "Player", "NPC", "Item" etc would inherit from so I could do something like:

foreach (MudObject obj in objects)
{
Console.WriteLine(obj);
}


However another question arises then. How do I differentiate between a mobile and a "gettable" item for player interaction within a room? I'm fairly new to object oriented design so any suggestions are greatly appreciated!

Thank you!
22 Feb, 2010, donky wrote in the 2nd comment:
Votes: 0
Kardon said:
Would it be proper to create a "MudObject" class that "Player", "NPC", "Item" etc would inherit from so I could do something like:

foreach (MudObject obj in objects)
{
Console.WriteLine(obj);
}

Sure. There are other ways to do it, but there is no reason you can't start this way. It's simpler.

Kardon said:
However another question arises then. How do I differentiate between a mobile and a "gettable" item for player interaction within a room? I'm fairly new to object oriented design so any suggestions are greatly appreciated!

There are many ways you can do it. You can have them both be gettable, but have the weight of the mobile be appropriately high that it is unrealistic that the player can get it. Or you can have some property like "IsGettable" that returns True for anything that inherits the GettableObject subclass at a lower level, and False for anything does not inherit GettableObject at a lower level. Or..
22 Feb, 2010, Idealiad wrote in the 3rd comment:
Votes: 0
There have been a few threads here I suggest:

Component-based MUDS

Socket-character-mob relations

Object messages

And from MudLab:

Feedback on mud design

Mob taxonomy

So I guess the short answer is…it depends!

However my basic recommendation is to avoid a deep inheritance tree to start. You can simply use properties/attributes, or hashes/lists/vectors of same, to determine a game object's what and how.
22 Feb, 2010, Kardon wrote in the 4th comment:
Votes: 0
Thank you both for the quick replies! I did some tinkering in the meantime and came up with a polymorphic approach. I used the original idea of all items, players, mobiles etc. inheriting from a "MudObject" and then created a virtual function "Get" within the MudObject class which extracts the object from it's "inRoom" and places it in the player's inventory. It is then overridden in the Player class and prints a message that "You can not get a player!". I'm assuming this approach can be used in other use cases also?

In the mean time I will read up on those links that were provided. It was just difficult for me to think of how to properly design a way to hold a container of generic "mud objects" and later be able to act on each one uniquely depending on object type.
22 Feb, 2010, Idealiad wrote in the 5th comment:
Votes: 0
I think as donky mentioned that's a good way to start. Inevitably you'll be rewriting and revising your ideas with future projects but something has to get the ball rolling.
22 Feb, 2010, David Haley wrote in the 6th comment:
Votes: 0
Idealiad said:
There have been a few threads here I suggest:

Component-based MUDS

Socket-character-mob relations

Object messages

And from MudLab:

Feedback on mud design

Mob taxonomy

So I guess the short answer is…it depends!

However my basic recommendation is to avoid a deep inheritance tree to start. You can simply use properties/attributes, or hashes/lists/vectors of same, to determine a game object's what and how.


Thanks for those links, Idealiad. It's nice to see how much interesting discussion there has been and the sheer quantity of material that's floating around. It's too bad that it's scattered over various threads and that there's no consolidated view, but really, that's a lot of interesting stuff.

EDIT: in the interests of full disclosure I was involved in many of the discussions so I don't mean to sound self-promoting. It's just that I forget myself what conversations have come up over the years so it's nice to have reminders. Maybe I should bookmark some of those.
22 Feb, 2010, Idealiad wrote in the 7th comment:
Votes: 0
It's good to point that out actually…MB may be at a point where some kind of indexing of threads might be a good idea. For example check this out:

http://ifwiki.org/index.php/Past_raif_to...

Of course you can just browse the individual forums. It's nice though to have things categorized once (well, once, every so often).
22 Feb, 2010, Kardon wrote in the 8th comment:
Votes: 0
Just a suggestion, but perhaps the owners here could create a wiki within the site that anyone can create and add to a "Getting Started" section specifically for starting from scratch, linking threads such as these within the article. Perhaps worth starting another thread over?

EDIT:
I see one was already made, silly me for not looking!
22 Feb, 2010, JohnnyStarr wrote in the 9th comment:
Votes: 0
LOL, going back to Object Messages makes me realize how little I knew then. :redface:
But, it's also cool to see how much I've learned in the last year or so. Also, it helps me gage where I
should be a year from now and so on. This site really has helped a lot.
0.0/9