On the future issue I think that the windows port should have a graphical
interface where you could read the logs, and boot people, or send them a MUD
message and other things like that. It could also let you change things,
like a character file(ascii pfiles maybe). It should provide plenty of game
info, like who is logged on, where they are at. Alot of info and tools where
you wouldnt have to be logged onto the MUD. Let you have access to
wizcommands also like stat. Well, I have alot of more features that I would
like to see in it, but I will wait for development to start before I
continue my wish list and stuff, later
> -----Original Message-----
> From: Circle Discussion List [mailto:CIRCLE@post.queensu.ca]On Behalf Of
> Claude Belisle
> Sent: Friday, January 21, 2000 3:22 PM
> To: CIRCLE@post.queensu.ca
> Subject: Re: [CIRCLE] CircleMUD's Future (was: Re: Player's position)
>
>
> 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 |
> +------------------------------------------------------------+
>
+------------------------------------------------------------+
| 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