[MUD-Dev] How much should be offloaded to Scripting?

[James Pepe]

Dan Larsen said:

> Now, my question is this.  How much of the game should I offload
> onto my scripts, versus hard-coding it in the server?  ...

...

> But does it make more sense, both architecture and performance-wise,
> to shift at least some of the logic to the server itself ...

Dan -

Though this doesn't /entirely/ apply to your situation, I'm
currently working on a new codebase in C# and recently toyed around
with several ideas.  Hopefully, what I'm about to write makes sense.
(Had a few too many cocoacoffees this morning ;)

The route I've chosen is similar to the scripted version whereas all
of the parsing and I/O routines reside in a hard-coded, precompiled
package and get passed to their handling class member.  Those
"commands" have a master configuration file (xml doc) that maps the
command to the class and member used to handle it.[1] This binding
occurs at runtime and can be changed "on-the-fly."

When the server loads, it reads in the configuration and compiles
the source it needs to handle its commands.[2] New configurations
and modules can be loaded while the MUD is running, and their
changes will be "immediately" reflected.

This allows me to keep all of my commands simply as source files
(multiple commands to a file are allowed) that I can edit while the
mud is running.  It also gives me the illusion of scripting with a
faster overall execution time.

This does mean a few things, however:

  1.  Changes will not be reflected until the module containing the
  source is reloaded.  Granted, you could watch the file system for
  changes and create the same effect, but it's not a solution I
  like. ;)

  2.  That being said, an error in the source means the immediate
  disappearance of a once valid command.  Solving this is simple.
  Make sure the new assembly compiles before the system swaps it in.

  3.  If you are modifying the commands while users are online, they
  may notice a potentially long delay while things compile.  To
  prevent/reduce this, I plan on moving the compilation process out
  to a new thread.

  4.  Initial loading of the server might not be as fast as we'd
  like.[3]

  5.  Until the external commands are compiled in to a new assembly
  and the configuration is changed, the server will insist on
  recompiling the source every time it starts.

  6.  Adding new skills and features that are tied to characters
  (players) means you'll still have to modify the main server code
  and recompile the server. (bummer!)  You don't, however, need to
  do this more than once per change.[4] While its possible to have
  even base-level changes show up at runtime, the complexity it
  adds, IMHO, isn't worth the effort.

I'm not sure if your language will allow this type of feature.  It's
just another idea to toss your way.

All -

I think I missed a few points in this email and so do apologize.  If
you think I did, or would like to discuss this further, please let
me know.  I'm interested in hearing what you guys think.

Best,
!jp

  [1] I plan on eventually making this available via a database
  server as well, but that is incredibly low priority.

  [2] Adding precompiled Command Libraries is also acceptable.

  [3] More than 10 seconds is too much in my book.  It should never
  be that long, but we can't rule out the possibility.

  [4] Assuming no ugly little bugs find their way in to your code
  >8()()()
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev