I am a hobbyist when it comes to coding but I've set myself to
face the challenge of writing a C++ based application that would
retain the 'look and feel' of the Circle code base, while allowing
an enhanced structure easing potential modifications. I completely
agree with Dak and think that is the way to go. Ultimately, coding
for a MUD will, assuming proper design, become a 'plug and play'
exercise (at least in my vision). Imagine a design based on some
COM concept, where developers can create components realizing
well defined interfaces. Most of those can be coded with some
compile parameter allowing extensive customization. Those that can
code will do it, those that can't will simply donwload and plug the
component in.
Currently, I'm trying to develop what the design model should look like.
Interestingly enough, concentrating consciously on that aspect brings out
dependencies and questions to which answers are not always obvious
(at least not to me). Just as an example, should a player know what channels
he is on, or should a channel be an object that knows who is on it? (to
which
I've decided the latter is more correct). Even if I never concretize the
project,
(which is a possibility as I'm currently missing a lot of expertise) the
exercise
is immensely enjoyable to me :)
I ironically dubbed my project CTNG (Circle - The Next Generation :)
Regardless
of the actual language or platform used, I strongly believe that the next
generation
must include some extensive analysis, with a view to ease of extendability.
Not to
do so will get us again in a monolithic program for which those with the
necessary
knowledge to modify the application is an ever shrinking number.
CB
-----Ursprüngliche Nachricht-----
Von: Daniel A. Koepke <dkoepke@california.com>
An: CIRCLE@post.queensu.ca <CIRCLE@post.queensu.ca>
Datum: Sonntag, 16. Januar 2000 10:47
Betreff: [CIRCLE] CircleMUD's Future (was: Re: Player's position)
>On Sat, 15 Jan 2000, Brian Hartvigsen wrote:
>
>> [snip ease of use stuff]
>
>Certainly. The idea isn't to make CircleMUD harder to use, but advance
>its architecture to enforce a better design and make the higher level Mud
>stuff easier. Optimally, the game mechanics, etc., could be (and normally
>would be) implemented by someone completely oblivious to the underlying
>complexity (which, of course, isn't really all _that_ complex). The CM
>kernel wouldn't implement the game mechanics, which is what most people
>are interested in and would impose only a minimum of requirements on the
>game mechanics. The game mechanics would either be implemented via a
>scripting language, or by modules written in C or C++ or whatever other
>language we could provide bindings for (regardless of what language the
>kernel is written in). Maximize flexibility, minimize the complexity that
>the end-user programmer sees, and with the community working on producing
>a wide base of different modules, you can end up with some very
>interesting, different, and fun Muds with a minimum of long hours of code
>removal and rewriting.
>
>> And why change to a different language? C/C++ are the most used
>> language next to Assembly (from what my teacher told me.)
>
>C and C++ are used more than Assembly these days. At least, from
>prototyping to implementation. Optimization might be done with the
>assembly output from the C/C++ compiler. As for what language to use, the
>only serious competitors are C and C++ at this point.
>
>-dak
>
>
> +------------------------------------------------------------+
> | Ensure that you have read the CircleMUD Mailing List FAQ: |
> | http://qsilver.queensu.ca/~fletchra/Circle/list-faq.html |
> +------------------------------------------------------------+
+------------------------------------------------------------+
| Ensure that you have read the CircleMUD Mailing List FAQ: |
| http://qsilver.queensu.ca/~fletchra/Circle/list-faq.html |
+------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 04/10/01 PDT