Re: Circlemud design issues

From: Rob Baumstark (shirak@CONNECT.AB.CA)
Date: 04/19/98

I agree with most of this, though there are a few things I'd like to comment
on.  I too have been mostly just listening, gathering what info I can from
the list, posting something when I think I can help.  Before you read the
rest of this though, PLEASE don't start another of those Win VS Unix
arguments because of this.  I can tell by reading the original that the
author likes Unix, well I am a Windows person, and I think that CircleMUD
should be developed for both.

>1. The biggest issue in my opinion is the use of macros.  Macros
>definitely have their place, but computer speed has increased so much
>since the first circlemud that they become less and less of a speed
I definatly agree here.  Sometimes I really like macros (like the MIN / MAX
ones), but in a lot of places (eg. REMOVE_FROM_LIST) they can be a pain.
>(Additionally, for speed issues, gcc allows for the inlining of
>functions, even in C code.  Perhaps VC++ provides a similar facility,
>but with the progression of Cygnus' gnuwin32 [which I am assuming
>supports inlining like this], I see less and less need to explicitly
>support such an alien compiler).

Though you may think of it as alien, I think it is a great compiler, and I
see no reason to stop supporting it now, after a lot of work was probably
put into getting support in the first place.  I am planning on making a
patch/port that will compile cleanly under the Borland compiler as well.  I
know that VC++ does support inlining.
>3. Layout.  The code in circlemud is, to be honest, poorly laid out.
>The file divisions are usually fairly accurate, though there are many
>contradictions and oddities in the code that make it hard to
>understand what functions belong in which files.  I personally use
>Emacs and etags, so this is much less of an issue, but it is still a
>design issue that needs addressing.  Also, we need a single .h file;
>having several is a real problem.

Here I agree with one of the other comments I read on this message.  Having
multiple .H files is a good thing.  It may make editing a bit harder, but
the amount of time it saves when recompiling makes it worth it.
>Another layout issue are player directories.  I personally like having
>a binary database (which allows for easy statistics gathering at the
>expense of offline maintenance, more on this later) and separate
>pfiles for info which grows (aliases, eq files).  However, the
>structure makes it hard to administer.  I've changed the layout on my
>mud to store pfiles in directories like this:

I too like the binary database, and have separate files for growing files.
>5. Unix tools.  I can't say how many times I've seen patches posted
>for things that would be pretty simple to with a few lines in a bash
>script.  Again, Cygnus saves us here, providing a large number of very
>useful ports of GNU tools (sed in particular comes to mind, though I
>assume there are other ports available).  There are a LOT of useful,
>powerful tools out there... we need to take advantage of that!  Also,
>everyone reading this should go download Emacs.  It's hard to learn in
>that it is very different than anything else out there, but once you
>do, you'll be twice as productive, or more.
Here I have to complain a bit.  I have a Linux machine here too, and I like
a lot of the tools, but making Unix tools a requirement for CircleMUD I see
as a bad thing.  As I said before, a lot of work has probably been put into
CircleMUD to make it run under Windows, and I don't think we should start
going Unix-only now.  Some of the Cygnus tools are great too, but I've
managed to get by without them too (I have been running a CircleMUD under
Win95 for about 1 year.)  I also think everyone should choose their own
editor.  In Win95 I like the editor in Developer Studio.  When I use Linux,
I use VIM (I also have Vim for Win32)  Each editor has it's own strengths
and weaknesses, go with what you know.
>6. Code appearance.  Circle is in most cases readable; however, there
>are times it isn't.  In particular, the use of typedefs can simplify
>things.  Also, we need to get rid of ACMD and ASPELL (something I did
>straight off).  They are a convenience in the initial writing of a
>command or spell, but they are an abuse of notation, so to speak, and
>can cause problems with symbolic debuggers as well as cross
>referencing programs.  Generally, for every time you're lazy when you
>code something, you'll spend three hours later fixing a shortsighted
>mistake or some other issue ;)
I very much like ACMD and ASPELL.  I haven't had any problems with them
debugging or anything, and the VC++ browse tools (like the tags things in
unix) work fine with them too.  I think not having them would cause even
more problems as people tried to create commands with different paramater
lists, and then the Master Command List wouldn't work anymore.
>Also, it would be nice if all the code
>conformed to one style.  I have an indent script I use for my own
>(though I don't need it often since I let emacs do my formatting for
>me) which reformats all the code to a specific style.  It's quite

VC++ 5 has a built-in indent function.  Besides just indenting while you
type, it can also re-indent files, which is great because all of the stock
code uses 2 spaces, while the default setup in VC++ uses tabs that are 4
spaces long.
>7. Linked lists.  The current linked list support is, well, somewhat
>dirty.  Imbedding next elements into all the structures then using the
>REMOVE_FROM_LIST macro is extremely ugly.  We need to get a simple
>linked list library written (a fairly simple task), or use one out
>there.  I personally use the singly linked list class from glib (a
>subcomponent of gtk, which provides a large amount of common C
>algorithms and structures, including hashes, lists, and I believe
>trees), which is exactly what we need.  The only downside is that,
>though glib itself is cross-platform I believe, gtk probably doesn't
>port to Win32 yet.

There is an STL that comes with VC++ that is portable to Unix.  (It comes
with VC++, but it is not produced by Microsoft)  I'm not sure if it meets
all of CircleMUD's needs, but if anyone wants to look at it, e-mail me and
I'll send you a copy.
>Okay, that's it for now.  I hope no one construes this as any kind of
>flame -- I am a big circlemud supporter (I wouldn't be coding one if I
>weren't).  But we need to think about the future.

I hope you take my comments the same way.  I really hate it when the large
flame wars get on here every once in a while.  If you have nothing nice to
say, don't say anything at all.
>PS: Has anyone done any work on an X based pfile database editor?
>I've been toying with gtk lately and am considering writing one.
>Would this be useful to anyone?  I'd like to keep it flexible enough
>to handle changes to the char_data structure without much rewriting.
>Is there much demand for this?  I personally don't like ascii pfiles
>since it fragments what I consider data that belongs in a central
>location... however, ascii files definitely are much easier to work
I was thinking of writing a Win32 one, but I decided not too.  If there is a
large demand I still might though, e-mail me about it (not the list.)
G:  "If we do happen to step on a mine, Sir, what do we do?"
EB: "Normal procedure, Lieutenant, is to jump 200 feet in
     the air and scatter oneself over a wide area."
-- Somewhere in No Man's Land, BA4
     Rob Baumstark:

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

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