Top Mud Sites Forum - View Single Post

aforsman · 05-10-2002, 12:56 AM

I'm in the process of writing an OO MUD using C++. I've found it to be a challenge to keep it as "OO proper" as possible, there are a lot of things in a MUD just aren't OO friendly. Ironically, a MUD seems to be the perfect OO setting. Like you said, having getters and setters for every variable in a class just isn't a viable option in most cases. If you do use the visitor method to get around this, you're still going to have to write a method for each thing you want to do with the class.

Let's say a player types in "look". The character class has all of the commands in it, and there is another class that holds the room. So now we're going to have to get the info from the room to the character. We could have a method that has the room create a look string and pass it back to the character class, and that would work ok for that instance. But what about other room manipulation commands? We'll need seperate methods to do all that stuff too.

I've heard that friend classes are bad, but I've spent a long time trying to figure out a way to set up my MUD to keep good OO practice and all that other good stuff. In most other programs I've written, it's been easy and worked well, but in my code this time I gave in and am using the friend keyword in a few places. For instance, I've made the character class a friend in the item and room classes, because the character class uses those all the time. I do not however, change any member variables of room or item in the character class directly.

I'm really interested in a new way to do this, but from what I've seen, many examples of OO in muds have made it way too complicated, messy, or too much work. Sure, encapsulation may make things better if used properly, but I think sometimes you can go too far and start throwing in OO techniques that make it worse.

my 2 cents.

05-10-2002, 12:56 AM	#2
aforsman New Member Join Date: May 2002 Posts: 1	I'm in the process of writing an OO MUD using C++. I've found it to be a challenge to keep it as "OO proper" as possible, there are a lot of things in a MUD just aren't OO friendly. Ironically, a MUD seems to be the perfect OO setting. Like you said, having getters and setters for every variable in a class just isn't a viable option in most cases. If you do use the visitor method to get around this, you're still going to have to write a method for each thing you want to do with the class. Let's say a player types in "look". The character class has all of the commands in it, and there is another class that holds the room. So now we're going to have to get the info from the room to the character. We could have a method that has the room create a look string and pass it back to the character class, and that would work ok for that instance. But what about other room manipulation commands? We'll need seperate methods to do all that stuff too. I've heard that friend classes are bad, but I've spent a long time trying to figure out a way to set up my MUD to keep good OO practice and all that other good stuff. In most other programs I've written, it's been easy and worked well, but in my code this time I gave in and am using the friend keyword in a few places. For instance, I've made the character class a friend in the item and room classes, because the character class uses those all the time. I do not however, change any member variables of room or item in the character class directly. I'm really interested in a new way to do this, but from what I've seen, many examples of OO in muds have made it way too complicated, messy, or too much work. Sure, encapsulation may make things better if used properly, but I think sometimes you can go too far and start throwing in OO techniques that make it worse. my 2 cents.