Claude Belisle wrote:
>
> 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.
One thing I'm presently looking up is to take the editors and work out a
generic class that all the editors derive from. By the use of virtual
functions the addition of a new editor could be greatly eased. you just
add in the new editor, no hacking of interpreter.c oasis.c etc, you just
add the editor c file and add the info to a struct somewhere.
As for the look and feel I'd rather see some cleaner API's in, however
mappings to the existing macros could be done.
I'm even thinking of working out a way to load in shared objects that
contain new commands, these can be added and removed on the fly :) IE
you literally just compile a command module and plug it in. Ideally
this could be more general so that you can add a new spells etc in.
Some work would have to go into the interface for this (The obvious
thing being how it handles the dlopen on differing platforms, I assume
that cross platform sort of thing is going to be around)
> 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 think that it'd be best to have a channel handler, that players
register which channels they're on with, this means that the save file
for a player contains the channels they're on. IE the channel deamon
handlers channels. This would require some hookups to save a player.
> 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.
I'd think most ppl would prefer C++, these days the compilers are
getting better, g++ 2.95.2 is pretty good (it can manage to compile
Unreal Tournement up)
I've certainly lots of ideas of things I want to do with C++ and circle
code. Initially it's just cleaning up the interfaces, perhaps the code
I'm working on has been so patched and hacked that it's got too much
strange junk in it (3 different isname's!) One of the nicest things
I've done is get rid of rnums, I use an index class and overide the []
operator. It's so much nicer :) (those wondering I took the idea and
code from the source of death gates mud)
My aim is to tidy up a lot of the code, and then release it out to see
what ppl think of it, but that'll probably be a few months off on my
own. (and at the moment it's a mess of ideas)
> > Von: Daniel A. Koepke <dkoepke@california.com>
>
> >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.
I've not seen much code in asm for a while, and then it was kernel code.
Cheers,
Chris
+------------------------------------------------------------+
| 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