Re: Circlemud design issues

From: George (greerga@CIRCLEMUD.ORG)
Date: 04/19/98

On Sun, 19 Apr 1998, James Turner wrote:

>However, I think there is also room for higher level discussions.

Of course, I have plenty, and there's room for world discussion too.

>It really is an excellent code base, but I think it, like any other large,
>multi-generation project, has some questionable design issues that have
>long since needed rennovation.

Kind of like how the four global buffers absolutely kill multithreaded
potential? :)

>I'd like to see a discussion on these topics, which are
>probably too drastic for changes in the 3.0 codebase (maybe 3.1, or
>perhaps 4.0).

I do occaisonally, don't get many responses except when people miss the
point of the project.

>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

Macros are nice for other reasons.  They can do cheap checking like I have
done in the upcoming bpl13 code.  Everything that now references a player
specific structure element will produce a warning when used on a mob.

>Moreover, their inherent nature makes it very difficult to
>debug in some circumstances (particularly since you can't set
>breakpoints in a macro, and because expansion can be different than
>you would expect and there's no way to see the problem without running
>the code through the preprocessor).

You shouldn't do that much in a macro then.  The only real offender is
REMOVE_FROM_LIST, which is there for obvious reasons.

>Additionally, it would be nice if a higher level of data abstraction could
>be reached; macros provide useful hooks to such things (replacement with
>functions, then renamnig all occurances via sed), but they aren't enough.

They are also there for structure variable abstraction, data checking, and
readability.  GET_NAME(ch) or ch->  How about GET_SAVE(ch, i)
versus ((ch)->char_specials.saved.apply_saving_throw[i])?

>(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).

GCC will automatically inline functions if you use -finline-functions or

>2. Expandability.  Circlemud provides a great platform for newbie
>admins who just want to start a mud.  But in some respects, it is
>difficult to expand.  For instance, the skill code is rather
>restrictive IMO.

Already scheduled to be rewritten.

>In my current code I've replaced this with a more
>robust and flexible set of code.

My rewrite will be akin to what the magic system rewrite was.

>Similarly, I've done the same with ability scores (a smaller project, not
>needed in many cases, but it has its uses to abstract them as well).

Huh? Isn't GET_STR(ch) abstract enough?

>Guild code is something that Circle could use (by this I mean part of the
>main distribution) which isn't trivial to add.

It has guild code, see SPECIAL(guild)

>3. Layout.  The code in circlemud is, to be honest, poorly laid out.

It inherited from Diku.

>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.

A single .h file would cause excessive recompilation.

I can understand the argument with conf.h, sysdep.h, structs.h, and utils.h
though, since everything already includs them.


Everyone has a different opinion, although I don't entirely disagree with

>Yes, there is a tiny amount of redundancy in the name appearing twice,
>but it makes backing up easier, as well as removing a single player's
>files, renaming them, etc.  Further, it eliminates issues of having

rm */*/player.*

(Would erase 'P-T/saga/saga.*' in your example.)

>low level string functions, for instance, have several functions doing
>similar tasks.


>6. Code appearance.  Circle is in most cases readable; however, there
>are times it isn't.  In particular, the use of typedefs can simplify

Working on some... (room/mob/obj/etc types)  Feel free to suggest more.

>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.

They are quite handy to figure out what is a player-visable command and
what isn't.  I'd say fix the debugger or cross reference program.

>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 work hard to be lazy.  In other words, if I can make a script to automate
some task I do all the time, I do.  I wouldn't call ASPELL() being lazy,
it's definitively declaring what the function is, and what arguments it
gets.  The spells and commands would not work if they took different
arguments. (function pointers)

>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 useful.

Most of it was formatted with the following 'indent' parameters:

-kr -i2 -di0 -npsl -nfc1

(Saved the mail message where Jeremy said that, you can find it somewhere
in the mail archives if you don't believe me.)

>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

You don't have to use 'next', you can name it whatever you want.  The
REMOVE_FROM_LIST is simple and works, especially considering you cannot use
a function and this is not C++.

>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.

CircleMUD is a base, not the end-all-be-all MUD.

>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.

Criticism is good.

George Greer  -   | Genius may have its limitations, but stupidity | is not thus handicapped. -- Elbert Hubbard

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

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