Re: C++ Cirlce Mud worth the effort?

From: Project Leader McCoy (
Date: 10/31/96

On Thu, 31 Oct 1996, Yoink! wrote:

> Not to disrupt the questions from those who have no idea what it takes to
> run a mud (*cough* Bad Boy! Bad Boy *cough*) but i was wondering about the
> intracacies of re-programming a mud in a C++ OPP type mud.

I hope you meant to say "OOP," not "OPP."

> To get to some of the paticular's:
> 1. Charecter's: Structures or Classes?
> Switching to classes would allow for certain player-specific actions
> (equiping, removing, fighting) to be contained within the class.  Not much
> of an advantage if you look at it one way, I'm open to your opinions on
> the matter, from charecter creation to death.

Actually, the biggest advantage to this is that you'd no longer have to
pass the player structure as the first parameter to I/O functions.  In
fact, if you make the player class inherit your I/O class, you can do
something like this:

player << "Your name is: " << player.queryName() << ".\n" << endl;

Also, inheritance is a help.  Polymorphism is there, but it's not
significant.  (I can say this because I've looked over how easy or hard it
would be to convert CircleMUD to C++.)

> 2. Channels?
> I'm thinking that removing the current channel system with a stream
> defined to send messager over the telnet system would be easier to deal
> witht he current system.  Image sending text to players with statements
> like 'pout << "You are sleeping";' and 'vout << "You fell chilled";'
> rather than the sprintf etc statements in current Circle coding.
> Adding gossip, chat, and clan channels could be a greatly simplified
> process, all derivatives of a (new? Know c++ but not much about unix
> specfic stuff like socket programming) base stream.

You're looking for the streambuf class, I think.  It's the one that
ostream and istream are derived from, and handles the low-level I/O.  It
doesn't really have anything to do with UNIX.

You could actually layer classes.  You'd have a player I/O layer, which
handles routine I/O (i.e., all of it is "trusted" and displayed exactly as
told), a system I/O layer (for system messages), and a custom I/O layer
(channels).  Each one would be handled in a slightly different way, but
would be passed off to the lower layer as well.  This is inheritance - at
least, one way of implementing it is.  (playerIO, systemIO : playerIO,
customIO : playerIO, with appropriately overriden functions.)

> 3. Anything not coming to me at the moment :p

There are a lot of advantages.  But then, it'd also take a veeeeeery long
time to convert procedural code to object-oriented code.  It's like going
from BASIC to C - it's easier to rewrite it from scratch, and you get a
better result, too.

                          "The human brain is like an enormous fish --    it is flat and slimy and has gills through
                           which it can see." - Monty Python

| Ensure that you have read the CircleMUD Mailing List FAQ: |
|   |

This archive was generated by hypermail 2b30 : 12/18/00 PST