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 --
icarus@berkshire.net 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: |
| http://cspo.queensu.ca/~fletcher/Circle/list_faq.html |
+-----------------------------------------------------------+
This archive was generated by hypermail 2b30 : 12/18/00 PST