[MUD-Dev] Scripting Languages and Magic

[Patrick Dughi]

Edward Glowacki wrote at some point in time:
> Simon Fairfax wrote at some other point in time:

>> I am attempting to write a new MUD codebase, and I was wondering
>> what people have done as far as magic systems. Specifically, I
>> was thinking of letting the players define spells in a custom
>> scripting language so that new spells could be created on the fly

> I've considered this a bit as well, and I really like the idea.
> But I'm not sure how easy it would be to pull off.  One of the
> things that would probably be the most difficult with this system
> is balance.

One of those 'when I get the time' projects I've developed but never
implemented requires such a system.  I wanted to generate a game
that (after taking some liberties) emulated illegal access of
computer systems, sort of a Neuromancer (the game, soundtrack by
Devo!) meets Corewars (also of note, the game Uplink).  I wanted the
players to write their own software though, so it would be more of a
battle of brains, than simply "who invested the most time on this
server".

This quickly brought up the issue of balance.  How complex can these
scripts be?  What's to stop a player from making a 'do-everything'
script?  I attempted to resolve the cost of a program in several
ways, most of which have a one-to-one correlation with a spell
scripting system, and all focusing on limiting the ability of a
player to make a uber-script.

The first would be cycle time.  In brief, the more instructions in a
script, the more costly it is.  It may run slow/take a while to
cast, and thus be prone to interruption or avoidance.  It could
simply require a larger percentage of the cpu/higher mana cost to
run as efficiently as the developer/wizard expected.

The next item was to monitor the use of world-affecting
functions/effects.  Each command in the script that was not a part
of flow-control, variable usage, or other script-specific thing was
assigned a cost of some type.  Examples of functions that incurred
costs include attack, defense, detection, transportation, and
others.  Pretty much, any item in the script which applied an effect
to the environment or or affected the players.  These costs were
calculated as a 'run time' cost, as they were potentially
situational thanks to flow control.

Third, there was an additional cost for the range of
function/effects used.  A program/spell capable of using 4-5
different functions was 'worth' more than those that were capable of
only one or two.  I outlined this as a multiplier value as opposed
to an additive value.

Last, I did a quick sweep of the entire script to look for, in
general, anything that wasn't 'simple'.  Recursion, inclusion of
external functions (if you allow it), number of looping constructs,
and a count of built in functions that were used (such as number or
string manipulation functions).  I used this to generate a
complexity score.

In the end, I had a set of costs which let me specify an
initialization cost, a runtime cost, and a complexity level for the
end script.  The complexity level would be the deciding factor in
determining if an effect would fire off or not (ie, does the
function damage(victim) actually 'run'), though it could be
influenced by external factors (cpu/level, free ram/free mana, etc).
Additional 'features' from complexity would be to fail the script
entirely(which could be valid if the complexity was too high), start
randomizing effects, targets, duration and efficacy.

In a spell system you can even provide these effects deliberately
though some sort of 'wild magic' system, which always seem fun, at
least in concept. Truly random is bad for players; they expect a
ratio of around 95 good events to the 5 bad ones.  Anything close to
50/50 is perceived as unfair (and therefore, unfun), when they don't
have a direct influence into it.  Maybe some sort of sliding scale.

Anyway, that's my 4 cents in two easy payments.

PjD
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev