1)
The one biggest problem I've had with circle over the years has to
be the unsafe extensibility of the combat system. Every part of the
combat system requires a pretty decent working knowledge of how every
skill/spell works, as well as potential affected spec_procs, and a bunch
of object-related issues as well.
The stock setup is simple enough (despite some required
interesting checks in 'damage' and 'hit'), but it is not a foundation upon
which to build.
I haven't put much thought into how to fix it without changing the
functionality. Previous (working) examples included queueing all battle
actions (still pulse-generated, so not a timed queue), which allowed us to
make any change, and depend on the queue system to determine if a given
event was valid or not. The events themselves are required to cause only
one of a given set of possible outcomes (ie, one event won't cause 3 types
of damage, it would either cause all 3 at once, or have 3 seperate
events).
I also used the queue-system to perform rollups calculations for
the battle messages (Commonly refered to as spam), and made that
toggleable.
2)
Number two is incomplete compatibility with the telnet protocol,
and a marked dependance upon non-intelligent telnet clients. In short,
the protocol-handling sections are far too intimately married with the
rest of the code to easily allow replacements for the input path, much
less allow multiple input paths (say, ssh-telnet connect, and the custom
client has it's own protocol for downloading graphics, sounds, private
message interface). We've seen other aspects of this in codepage
support for foregin languages.
Some of this is crying featurality, instead of commenting on what
needs to be fixed, but if we're supposed to be an easily extensible mud,
today, that cries out for some sort of native custom-client support,
regardless of a client's existance. If 'fixing' the telnet dependance
makes these features easier to implement, just consider that a
side-benefit.
As for custom clients, if you build <server side compatibility>,
will they come?
3)
Three is vague, so sorry if I describe it poorly. Due to design,
the singly threaded nature of CircleMUD makes it difficult or awkward to:
Easily allow for required responses
(yes/no, etc, current requires adding to main input loop
per unique question!)
Allow for nonblocking operations for the mud, while blocking on a
single character - think admins who are performing shell
commands, or time-consuming actions like server-to-client
file downloads (graphics, sounds, zone updates for admins..etc)
Just a simple set of forking/new thread/new process operations
designed for this would make it easier, in addition to changes from point
2.
4)
Statistic logging absent. I'm not talking about rollup
calculations, like "A given monster is the prime prey of level 32 fighters
with ac > 40", but just the ability to collect mass amounts of data, and a
few external programs to do some correlation later. I wrote some scripts
a while back that did some simple things, like take a zone and compare
hit points, damage, level, thac0, gold of a monster vs. the entire mud,
and say 1) If the mob compared with others of the same level 2) point out
the parts that did not (via a std. dev function).
The actual format would be something like:
time:event:<affected party/unique id>:data value
ie,
9892332:Level Gain:Player 'Joe':32
(And, there'd be an identical format that would be run on 'static'
data, like character class, or zone reviews)
This would let people decide on things like if a zone was
proper, or if their new class allowed too-hasty level gain... in short,
balance issues.
Given a standard set of statistic types, we'd have a growing set
of standard statistic-checking scripts, in the same way many zmud-users
just copy their macros/aliases/etc from others.
There are more, but these peeves already break the boundry between
functionality and featurality.
Sure would be fun to make mixed drinks though.
PjD
--
+---------------------------------------------------------------+
| FAQ: http://qsilver.queensu.ca/~fletchra/Circle/list-faq.html |
| Archives: http://post.queensu.ca/listserv/wwwarch/circle.html |
+---------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 12/06/01 PST