[MUD-Dev] Looking for a Magic System (inspired by Bartle's book)

Damien Neil damien.neil at gmail.com
Wed Aug 31 00:26:47 CEST 2005


On 8/25/05, David Love <dlove at nighton.net> wrote:

> All of this discussion about magic-crafting has gotten me
> thinking...

> Let's assume we have a programming language that defines functions
> for applying elemental force to a target (seems to be a popular
> thing to do with magic :)):

An idea I've kicked around in the past, free for the taking to
anyone who wants it:

Spells are constructed from runes.  Runes are acquired through a
variety of means--bought from vendors, found as random loot, from
quest rewards, etc.  You take a few runes, connect them together,
and get a spell.  It may be possible to disassemble a spell to get
your runes back for use in other spells.

Runes function as opcodes in a virtual machine.  Casting a spell
executes it.  Each rune has an associated mana cost, which imposes a
limit on how expensive a spell can be--anything too complicated, and
the caster will go oom.  There might also be a delay associated with
each rune (determining the cast time of the spell) and a maximum
spell size.

The spell VM has a set of registers.  To do something useful, a
spell must load those registers with appropriate values and execute
a "cast" rune which triggers the effect.  A very simple spell might
look something like:

  { load1, assignA, load2, assignB, load4, assignC, cast }

This fills the registers A, B, and C with the values 1, 2, and 4
respectively and casts the spell.  The cast opcode looks up the
spell effect based on the contents of A (1, or "heal", let's say),
the target based on B (2, or "current target"), and the potency
based on C (4, or "pretty good").  In other words, this is a simple
single-target heal.

Rune choices are structured to make certain spells more difficult to
cast than others.  For example, if the "load3" rune is the only load
op available to low-level players, they won't be able to cast
anything indexed by other than powers of three.  A "load1" rune
would be very valuable, since it allows access to an entire other
slice of spell effects.

There's a lot of scope for various rune effects that offer minor
variations--a rune might add 2 to register A while subtracting one
from B, or rotate the contents of the registers.  New cast runes
would give access to entirely new categories of spell.  Some runes
might only function under certain circumstances--outdoors, or during
the daytime.  There might be conditional opcodes to allow a spell to
use more efficient (but situational) runes.

To make things more interesting for the players, none of this is
documented.  There should be just enough feedback to permit the
system to be reverse engineered, but the specific details are
hidden.  In particular, the exact effects of a rune are never
explicitly given.

To seed the system, players can acquire some pre-made spells from
vendors or trainers.  Of course, these won't be as good as the ones
they can make themselves.

The overall system rewards players in several different ways:
Reverse-engineering the basic structure spell system will probably
be done by a small number of people who will eventually publish
their discoveries for everyone to use.  They and other players will
then design and share common spells.  This allows people who aren't
interested in the details of spellcrafting to avoid it--they can
just rely on common, published spells.

Since runes, however, will be a limited resource, players with a
good understanding of the spell system will have an advantage over
those who don't.  By designing spells to specifically take advantage
of the runes they have access to, they will be more efficient
casters than the people who just use existing recipes.

The end result would be, ideally, to make the magic system function
somewhat like a collectable card game--having a good assortment of
cards (runes) is important, but knowing how to build a good deck
(spell) from the available ones is more so.
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://kanga.nu/lists/listinfo/mud-dev



More information about the mud-dev-archive mailing list