Re: Even more dynamic spec procs?

From: Patrick Dughi (dughi@imaxx.net)
Date: 09/09/02


> This may be totaly off the wall here, but have you thought about
> using libxml instead? Using a fairly standardized node system, you
> could safely read new structures into the game, since libxml has
> a really nice error catcher all of it's own. Then an easy little
> bottleneck function could sit and watch the files and reload/unload
> the structures as needed.
>
> Example:
> <?xml version="1.0"?>
> <commands>
>   <cinfo>
>     <author>Shane P. Lee</author>
>     <datewritten>September 9, 2002</datewritten>
>     <fname>Commands.xml</fname>
>   </cinfo>
>   <cmd cnum="1">
>     <name>say</name>
>     <self>You say, </self>
>     <room>Says, </room>
>     <nself>Say what?</nself>
>     <call>do_say</call>
>   </cmd>
> </commands>
>
> While that may be a very poor example, you get the idea. Of course
> there are lots more to a command than what I showed in the example.
> Xml works great in that you can also use outside editors to change
> or add the nodes as the game runs, xmlnotepad springs to mind.
>
        Actually, I considered briefly the idea of using an external
little language, precompiled bytecode, patching in scripting languages,
etc ...

        Lemme start at the first problem: I'm not worried about syntax
issues; if it's in C, the compiler will never generate code that doesn't
'work'.  Sure, the code could crash, but, that's an application error, not
a syntax-level problem. I was worried about things like memory access, or
a library with a piece of code that segfaults..

        Er, but that wasn't the biggest problem with developing a new
scripting language.  The problem is that you have a cookie cutter tool,
and you can't make anything that's not in the shapes you have.

        Think about dg scripts.  DGscripts are rather full featured, at
least from a spec-proc replacement view.  You could - if you really wanted
to - even write the hooks so you could use dgscripts to generate new
commands...

        But here's a problem; lets say you want to do something as simple
as replace the 'who' command.  Can you do that with DG scripts? Well, not
really.  How about show rent on a saved player?

        Yes, I know - you can write the special case code in, insert the
hooks, develop new grammar, etc... and the time to do that takes longer
than just writing it the one time in C (or modifying existing code) to
produce the output you want.

        I'm reminded of a fairly good example, when Alex was talking about
making the CircleMUD follow the telnet protocol; he suggested that in the
future, there could be an assignable object responsible for socket
communication.  You could switch it out with an object that performs an
ssh-style connection, or just a standard compressed transfer, or..whatever
you want.

        I don't think I'd want to do THAT in dgscripts OR xml.

        Aside from the interesting possibilities, I just think that it
would promote CircleMUD use in general; copying a supplied binary object
into a directory sure is alot easier than patching one in yourself.
Granted, it could create alot of joe-muds, or whatever we're calling them
now-a-days, but it'd also make it easier for people to start.

        Kinda curious about what people feel about the popularity of text
muds lately..  if they're going downhill, vanishing, etc.  They rocked in
the early 90's when I started, but now I have to explain what they are to
kids who can't remember when they didn't have email.

        And guys who haven't ever, ever, heard of 'Zork'.

        That's a topic for another day though, I suppose.

                                        PjD

--
   +---------------------------------------------------------------+
   | FAQ: http://qsilver.queensu.ca/~fletchra/Circle/list-faq.html |
   | Archives: http://post.queensu.ca/listserv/wwwarch/circle.html |
   | Newbie List:  http://groups.yahoo.com/group/circle-newbies/   |
   +---------------------------------------------------------------+



This archive was generated by hypermail 2b30 : 06/25/03 PDT