[MUD-Dev] Re: let's call it a spellcraft

[Travis Casey]

On 25 September 1998, Niklas Elmqvist wrote:
> On Fri, 25 Sep 1998, Travis Casey wrote:

>> My own thought is to have a set of simple magical commands which can
>> be used directly:  e.g., you might have the commands:

[list snipped to save space]

>> When used in the spell programming language, these would be equivalent
>> to the pre-defined keywords or library functions of most programming
>> languages.  There would also be control-flow statements, but these
>> would only be usable in a spell/program, not as direct commands.

> So you mean that a mage could just wing it and issue these commands
> directly? But what of the research time mentioned below? If this is an
> option, I immediately see a large number of people entering the spell
> commands as macros into their MUD clients instead of having their
> characters research them. However, this mechanism might be useful when
> trying out new spells.

That's what I mean... however, there are some problems with doing it
that way:

 - You don't have any control structures.  Thus, if you want to do
   something that will loop, or wait, or do a decision, you need to
   write a spell.

 - You don't have variables.  Thus, if you want to cast a spell that
   does several things to one target, you have to give the
   specification for the target each time, instead of being able to do
   it once.

 - There's a limit to how fast you can do this... this isn't something
   specific to spells, really, but it would be global throughout the
   system.  I don't like players using external scripting mechanisms,
   so I like to put in safeguards against them, like a limit on how
   fast you can issue commands (or by queuing up commands and having
   them executed in sequence at a certain tempo).  Thus, to do, say, a
   twenty-line spell command by command might take about ten combat
   rounds, where doing it as a single spell only takes one or two.

> [Spell balancing:]
>> I'd thought of a similar system for netrunning programs in a cyberpunk
>> RPG, the rationale being that the more common a program became, the
>> more likely it was that someone would have developed and distributed a
>> defense against it.  Following the same idea, you could have NPCs
>> having pre-prepared counterspells for the spells that become too
>> common.

> Well, we have a perfectly valid reason for this in a magical world: the
> more people that use a spell, the more "toll" it takes on the specific
> powers required to invoke the spell, and it becomes diluted. Some spells
> could be defined to be able to accommodate quite a few users, the basic
> magic missile or cure light being good examples, while other more powerful
> spells would lose their power if known and used by more than a mere
> handful.

I think I prefer my own idea... that mages will tend to develop
counterspells to well-known spells, and those counterspells will
themselves become well known.  To each their own, though.  :-)

> Of course, this kind of balancing system almost *requires* that we use a
> fixed-spell system (that is, a system where the spells are defined by the
> admins instead of created by the players) -- otherwise, it is very hard
> for the server to determine that two very different spell snippets might
> do the same thing, and thus reduce the efficiency of the spell. (You could
> do some kind of calculation on the required power "types" for spells,
> though... Such as many people using spells requiring Fire, and
> consequently, the efficiency of fire spells are reduced.)

The counterspell version doesn't suffer as much from this problem... you
could develop specific counterspells for various spells, but you could
also create generic counterspells -- e.g., an anti-fire spell.

Of course, you could also combine both ideas, for more fun!

[spell research happening in offline time]

> I like it. However, spell research would almost require that the player
> leaves his character in his study when logging off -- quitting in the
> middle of Mirkwood with a dozen giant spiders stalking around would do
> nothing towards creating a nice research atmosphere...

That depends on the level of realism you like in such things... if
your mud is the type where you don't come back to the same place you
left from when you log off, I wouldn't see this as a problem.

> However, I *still* would like to have a practical research element as part
> of the game... The Unseen University concept appeals to me; lots of
> players working in unison to experiment with different kinds of spells
> ("You are now entering the Unseen University magical testing grounds.
> Proceed at your own risk." *zap* *kaboom*).

I think there would be somewhat of a practical research element...
with the idea that you advanced of treating spell components as
pre-built modules, you could also treat spells themselves that way.
By doing that, it becomes possible for someone to research a new spell
faster by reusing parts of old spells as modules.

This opens the door to "magical research" by means of building small
spells, then reusing parts of them to build larger spells.  Thus,
there's a cycle of:

 - think up an effect
 - implement and test it in a model spell
 - start building more complex spells that use it

With spell components having pre-built modules, there's also another
kind of research -- figuring out those modules and their interfaces!
IMHO, a spell programming system should have some allowances for
reverse engineering -- for taking an existing spell and trying to
decompile it.  This allows figuring out how spell components work, and
taking a captured spellbook and figuring out the spells in it.  (And
this could be a necessary step anyways... since spells can make
decisions via if-then statements, spells can be booby-trapped!)

> I see one problem with this, though: a concept like this would certainly
> work for a fixed-spell system (defined above) where the player can type
> 'research magic missile' and then happily log off, secure in the knowledge
> that he will have another neat spell in his inventory when he returns the
> next day. However, in a spell-creation system where we don't have any
> fixed spells, how will the player be able to test his spells for "bugs" if
> he first has to type 'research magic missile' (where 'magic missile' now
> denotes a spell code snippet) and then wait four *real* hours before he
> can use it? Or is this something we want? (Spellcraft should be a
> time-consuming process.) Maybe the player could be allowed to perform some
> kind of 'dry run' with his spell to ensure that it is working properly?

That could be done partially by using the direct commands, the way I'm
thinking of things above.  That works for simple spells that don't do
much in the way of decisions, etc.  More complicated spells you'll
have to test the old-fashioned programming way... write it, research
it (equivalent to compiling it), then test it.

Go through the archives and look for Mage2Mage... the spell language
in there allows for ways to interrupt spells and modify them while
they're "running", which could be good for testing.

Also, you can use the magical equivalent of debugging with print
statements... imagine a wizard's lab where strange voices tell the
wizard that the spell has reached a certain spot, or where runes
appear in the air to tell the mage what's going on in the spell.

Lastly, with the idea of reusing spells as modules, you can do
bottom-up programming... implement and test your spell in parts, then
put those parts together when you know they're working right.

[spell components containing spell code]

> Seriously, this could be used to great effect, I think. For one thing, one
> major part of spell research will be to find out what different methods or
> calls a specific item supports -- the players would have to write basic
> 'identify' spells for this (in addition to a 'detect magic' spell which
> saved the player some power by doing a simple check if there are is any
> spell code at all in the item).

Of course, in a world like my Tobara, detect magic is useless... the
entire world is magical!  But that's another discussion.  :-)

> Also, depending on the magical potential of an item, the cost of
> identifying it could vary -- try to ferret out the powers of the Holy
> Graal and you might end up drained in the process. Why not let some
> magical items have an active defense which needs to be defeated in order
> for the mage to identify and use it -- this could be methods in the spell
> code associated with the item along the lines of OnWield(), OnIdentify()
> and OnGet() (which trigger when the item is wielded, identified and get,
> respectively). Alternatively, we could use verb-binding for this purpose.
> This way, we can easily have sentient swords, blessed armor, cursed
> weapons, etc, as well as magical traps which trigger on special events.

Yep.  This is one reason why I like treating spells as programming...
it makes these sorts of things possible in a fairly easy-to-understand
way.

> Indeed! The feather in our example could be empty of magical energy and
> you would have to channel some of your own raw power into the feather and
> use it as a conduit/focus for flight. This would be how birds fly: they
> instinctively channel their own magical power into the flight spell of
> their feathers. All magical power that is fed into the feather transforms
> into spell effects (along with some power losses, of course, nothing is
> perfect -- this could be dependant on the caster, as well).

In Tobara, life and death are the powers behind magic.  You activate a
spell by channeling your life (or your death, for some folks) into it.
Thus, a bird flies by using some of its own life to power the spell
built into it... but a mage can take that spell and power it with
his/her life instead.

Of course, if you're feeling nasty, you can power spells with someone
else's life.  :-)

> Some items could have some magical energy stored in them as well, allowing
> people with little or no magical ability to use them (eg wands, rings,
> staves). Some would have permanent effects, some could be recharged
> (automatically over time or artificially by mages), others could be mere
> reservoirs of magical power (cf the Eye of the World, which is a huge
> "lake" of power, in Robert Jordan's first WoT installment). The point is
> that associating spell code with items allow us to handle all of these
> effortlessly and without special cases.

Yep.  This also allows for the old "this item can only be used by
mages" thing in some settings... the item has spell code, but needs a
mage to supply power to it (presuming a world where mages have "the
power" and others don't).

In Tobara, using life and death as the powers behind magic gives
motivation to such things as doing sacrifices in spells... you
sacrifice someone in order to take their life from them and use it to
power a spell.

> (The SDL spell definition language I've heard of, is this a language from
> an outside source or created by someone on this list?)

It's from an outside source... the Mage2Mage magical spell/combat
system.  It's been posted to the list before, so it should be in the
archives.  If you don't feel like digging through them, email me...
I've got a copy on my hard drive somewhere.

--
       |\      _,,,---,,_        Travis S. Casey  <efindel at io.com>
 ZZzz  /,`.-'`'    -.  ;-;;,_   No one agrees with me.  Not even me.
      |,4-  ) )-,_..;\ (  `'-'
     '---''(_/--'  `-'\_)