Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

needhelp

code design assistance needed

This topic is 5848 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I''m in the process of writing a MUD in c++, and have come across a little problem that hopefully some of you can answer. First of all, here are the classes that are in question: client player character item npc room entity room, item, and character are derived from entity, player and npc are derived from character. client controls server-player interaction. Let me give you an example of the problem. A player types in the command "look". The text is parsed, and it executes the "look" function. So now, we are currently in the character class code, and the character class needs information about the room, and the contents of the room (other characters, items, etc). It would need to access the member variables of all those classes. I could have a ton of get_xxxx() functions for each class, but that sucks and isn''t very elegant. I could also use the friend keyword, and pretty much have everything be a friend of everything. In my previous attempt to do a mud, I went with the friend route, and that worked, but it also caused some problems. I''m leaning that way again this time around, because that''s the only thing I can think of that would work. Anyone have any suggestions?

Share this post


Link to post
Share on other sites
Advertisement
quote:
Original post by needhelp
I''m in the process of writing a MUD in c++, and have come across a little problem that hopefully some of you can answer. First of all, here are the classes that are in question:

client
player
character
item
npc
room
entity


room, item, and character are derived from entity, player and npc are derived from character. client controls server-player interaction.



Sounds workable. Good so far.

quote:

Let me give you an example of the problem. A player types in the command "look". The text is parsed, and it executes the "look" function. So now, we are currently in the character class code, and the character class needs information about the room, and the contents of the room (other characters, items, etc).


Does it? It sounds more like the Client class needs to ask the Player object what Room it is in, and then ask that Room what Entities are in it, and then ask each Entity to describe() itself.

quote:

It would need to access the member variables of all those classes. I could have a ton of get_xxxx() functions for each class, but that sucks and isn''t very elegant.

A few points here, which I feel are germane to OO:

* get_xxx shouldn''t be your stock way for retrieving information. Try to decide what outside parties will care about in a class, and expose that through getters/setters. In other words, your Entity class should have a getDescription() function which returns a full description, rather than getSize, getColor, etc. Those could be put in too, but they aren''t as important.

* If you find yourself using getters/setters a LOT, consider whether the function accessing them should be partially rolled into the class itself. See getDescription above.

quote:
I could also use the friend keyword, and pretty much have everything be a friend of everything.

NO! NO NO NO! *smacks with a rolled-up newspaper*

If you''re using friend classes that much, OO has failed you (or vice versa, depending on how you look at it). Tear up your class diagrams and start over.

quote:

In my previous attempt to do a mud, I went with the friend route, and that worked, but it also caused some problems.

Sure, because it was no longer an OO program.



Don''t listen to me. I''ve had too much coffee.

Share this post


Link to post
Share on other sites
The ''MUD'' is basic enough that going that your polymorphism is actually counter-productive. I have a mud engine laying around, and I am going to describe how it works -

EVERYTHING is an entity. The rooms, the exits, the players, everything. The entity looks like this -


  
class entity
{
private:
vector<string> attributes;
vector<dbref> contents;
int location;
int dbref;
int client;
string outputqueu;
public:
varius_access_functions();
message_sending_functions();
};


All ''properties'' are held in the attribute strings (I have functions to search them, and to get their values, and other such things.)

Why do it this way?
You can handle everything the same. There is very little ''type specific'' code. To make an object an exit, just give it a ''dest'' attribute.

Each object also has a ''send short'' and ''send long'' method. These send the appropriate description to another object. (ANY object can receive a message, not just players. This makes it very easy, later on, to do things like having a game object ''listen'' to a room for a specific string.) Short just sends the objects name. (In my implentation, it also takes into account a title attribute.) Long sends the name, the description string, and the contents. It uses send_short to send it''s name, and calls send_short on every object it contains.

Forget it; this is too much hassle to explain. You can grab some code at - http://www.massassi.com/coffeestain/JMServer.zip

Using this attribute system, the database also gets smaller - not storing extra info if an object hasn''t got a certain attribute. For instance, the database entry for an object in my example database -

object 3
attr $short Deyja''s funky spotted hat.
attr $alias_hat
attr $long This is Deyja''s hat. Only Deyja can use it. If you aren''t Deyja, don''t even think about touching it.
attr $getable
attr $lock ^#2
attr $osucc %1 picked up Deyja''s funky spotted hat.
attr $isucc You picked up Deyja''s funky spotted hat.
attr $ofail %1 reached for Deyja''s hat and got a nasty shock.
attr $ifail You reached for the hat and got a nasty shock.
attr $odrop %1 tossed Deyja''s hat aside.
attr $idrop You tossed Deyja''s hat aside.

Share this post


Link to post
Share on other sites
The property approach is a good one, but the real problem here is that the poster needs to know how to make real object-oriented programs.

The key is to think in terms of the actions that the objects perform, not the values they have. You will need to expose some properties to other classes, but not everything. For the few things you need to expose, write accessor functions. But plan things out first and work out the best interface in your head and on paper before you start coding.

[ MSVC Fixes | STL | SDL | Game AI | Sockets | C++ Faq Lite | Boost | Asking Questions | Organising code files | My stuff ]

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!