[MUD-Dev2] [TECH] Server Side Scripting

[Ammon Lauritzen]

Roger D Vargas wrote:
> I have designed my server oriented to heavy scripting. C++ code does low
> level stuff, but knows nothing about entity attributes (stats, skills,
> items). All that stuff is handled by lua scripts. A friend told me that
> approach is very bad. His solution is to define a server/client specific
> language that gets checked at compilation time, opposite to my approach
> (code is checked at runtime). REally is that bad to make server
> dependant of scripts?

Well, it depends on the game and the nature of the scripts. The two big
reasons that I can think of that server-side scripting is bad:

1 - It eats up valuable resources. This doesn't matter while your player
base is small or when you aren't running very many scripts. But... if
your initial design is really heavy into that sort of thing, you might
have problems pushing some scripting off to the client in the future.

2 - The scripts can pose a stability hazard. If sufficient checks are
not made to balance the scripts, it is entirely possible that a mistake
can run away from you.

Now, that said... there are plenty of reasons to do scripting on the
server side. Otherwise, what's the point of the server? May as well use
Jabber + MUC or even IRC if all you want to do is make a bunch of
clients talk together w/o any logic on the server side ;)

In some cases, your client isn't capable of performing the logic
necessary. MUDs are famous for doing everything on the server with
absolutely no work performed on the client side except (maybe) some
formatting.

Pre-AS3, a Flash client would have been terribly limited in the amount
of computation you could expect from it w/o making the player's computer
unusably slow. Likewise with an AJAX client.

Sometimes you don't want the client to see the logic - suppose you've
got some world simulation going on whether or not any players are
present. There's no point in offloading this logic to a client. In fact,
you'd likely be harmed by requiring a client to be present in order to
perform the math.

But it's not difficult at all to bring a moderately high-end machine to
its knees by running too much NPC ai. One time, I wrote a flawed new
system for handling mob spawns... thankfully I was smart enough to run
the test in a remote, enclosed portion of the game world, otherwise the
mud would have been neck-deep in ducks laying eggs ;)

And sometimes, the server NEEDS to know the answer to the computation
quickly. You don't want to wait for client-side latency. What if you
have 50 clients all waiting on the results of the script? It's not fair
to them to make them wait on Bob's client to do the math - especially if
he's playing on his laptop over a cell phone connection or some other
hideously high latency method.

As fas as separation of the core engine into a low-level precompiled
kernel and a scripting engine? Sounds good to me. Scripts are easier to
debug, change, and add to than hard-coded logic.

The first mud codebase I ever played with was CircleMUD, and recompiling
the universe on a 40mhz machine with 8mb of ram each and every time I
wanted to correct a typo or tweak some numbers was annoying in the
extreme. Had I been able to use a scripting language at the time, it
would have improved things dramatically. Shortly thereafter, I switched
to LPC and couldn't have been happier.

Is it bad to make your server dependent on an interpreter that performs
no compilation step and runs free-form code on the fly without any error
checking? Probably, for the reasons I mentioned above. Ideally, new
scripts would be compiled once and would let you know when something
went wrong before being released into the wild. They would then also let
you know if something went wrong at runtime (uncaught exceptions, etc...).

Lua is an appropriate choice for a server-side scripting language, with
the added benefit that it's portable enough you could distribute it with
your client to handle the client-side scripting as well ;)

Generally, you want your kernel to handle the most computationally
expensive and most frequently executed code possible. Adding 1 to a
player's strength isn't terribly expensive, but pathfinding is. Writing
your expensive algorithms in C and then calling them from your scripts
can give you a big performance boost and can improve stability once
you're sure your C works correctly.

Ammon