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