[vworld-tech] Modern MUD server design

[Brian Crowder]

Everything Mr. Hook said, plus:

If you're engineering toward an approach like this, you're going to be 
forced, in a sense, to consider modularizing parts of your architecture 
that you otherwise might kludge together if you didn't have to worry 
about language-boundaries.  This sort of thinking can often result in 
better technical design (not always; your mileage may vary).  In other 
words, by providing a layer of abstraction to a scripting language, you 
are likely to make decisions that you otherwise might not address until 
much later (when it's too late to make the -right- decision).

Also, in my opinion, the logic and mechanics of a game are more 
interesting to implement, test, debug and deploy than are the various 
containers, algorithms, helper libraries and modules often provided as 
the core features of a good, high-level language.

Further, depending on the level of experience of the people on your team 
(a major consideration for hobby-projects like a text-mud, but just as 
significant in professional projects), using a high level language with 
features like garbage collection, absence of pointers, and intuitive 
access to things like (as Mr. Hook points out) dictionaries (hashes), 
etc., etc., can be the difference between an unstable, kludgy, slow 
mess, and a manageable, maintainable source-base (some education may 
still be necessary, though...  I'm increasingly skeptical of "here's a 
scripting language, GO GO GO".

Another considerable advantage of an interpreted language (which most of 
these high-level script languages are, or CAN be) is the ability to 
provide a confined "sandbox" for logic code, restricting its ability to 
(for example) branch or recurse, allocate huge chunks of resources, or 
do other sorts of unpleasant or malicious things.  A well-defined 
sandbox like this could put you in a position of being able to allow 
your designers, or even your users themselves to contribute dynamic 
content to your game by writing simple scripts of their own (I 
understand this one is a little -- a lot -- scary, but I think there can 
be tremendous value in user-generated content, in the right design).

Languages that support continuations or co-routines and/or allow you to 
serialize the state of the virtual machine can also offer some 
interesting posibilities for simplifying code that might otherwise 
require non-intuitive state-machines, error-prone communications 
protocols, or threads.

-- Brian

Brian Hook wrote:

>>>In my opinion, a pretty solid approach.  Of the architectures
>>>I've seen for both professional and "hobby" multi-user games, the
>>>better architectures have usually been those that gravitate more
>>>toward very high-level languages (or structured data) for
>>>defining game content.
>>>
>>
>>Why is that?  What advantages are there to writing the game logic
>>in a scripting language versus writing it in the same language as
>>the kernel.
> 
> 
> Not to state the obvious, but because you get all the advantages of 
> the scripting language.  Assuming you believe that a language such as 
> Python, Ruby, Lua, etc. has significant advantages for higher level 
> application development than a lower level language, then using it for 
> your game logic gives you a bunch of rapid development advantages.
> 
> If you're using a compile/link language like C/C++, then having to 
> recompile and relink everything just because you've changed an orc's 
> pathfinding algorithm can suck since you have to bring down the world 
> (you could, in theory, use shared libraries, but that presents its own 
> set of problems).
> 
> Basically, Python et. al. have a slew of advantages over C/C++ for 
> logic programming.  C/C++ are great for many things, especially when 
> you need good performance and tight control over memory layout, but 
> Python et. al. are really nice for fast development.  Intrinsic 
> garbage collection and dictionaries alone are practically worth the 
> price of admission, then toss in all the various standard packages for 
> sockets, io, SSL, etc. and it becomes a no-brainer.
> 
> 
>>If all things else are equal
> 
> 
> But rarely is that the case =)
> 
> Brian
> 
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> vworld-tech mailing list
> vworld-tech at cubik.org
> http://lists.cubik.org/cgi-bin/mailman/listinfo/vworld-tech