Greetings everyone,
I've been lurking around here for a bit, listening to the discussions
and such, and I've been very impressed with the level of support
offered to newer coders. It's reassuring to see a such support (with
no/few flames, no less).
However, I think there is also room for higher level discussions.
I've coded on Circlemud code bases for about a year (having begun my
own at the beginning of this year) and have had a good deal of
experience working with the code base. 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. 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).
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
issue. 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). 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.
(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).
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. In my current code I've replaced this with a more
robust and flexible set of code. 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). Guild code is something that
Circle could use (by this I mean part of the main distribution) which
isn't trivial to add.
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.
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:
home/P-T/saga/saga.alias
home/P-T/saga/saga.objs
home/P-T/saga/saga.skills
As opposed to
home/aliases/P-T/saga/aliases
home/objs/P-T/saga/objs
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
all your files stuffed into a single directory (which I think an older
version of circle did, but I could be mistaken).
4. Redundancy. Many redundant functions have snuck into Circle. The
low level string functions, for instance, have several functions doing
similar tasks. This needs cleaning up, and an explicit string library
needs to be made. Also, in making this library (and in other
restructuring efforts on other parts of the code), data abstraction
and modularity really, really need to be enforced. Circle could very
much be simplified while simultaneously adding flexibility,
reliability, and robustness.
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.
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 ;) 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.
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.
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.
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
with.
That's all for now.
Chip
+------------------------------------------------------------+
| Ensure that you have read the CircleMUD Mailing List FAQ: |
| http://democracy.queensu.ca/~fletcher/Circle/list-faq.html |
+------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 12/15/00 PST