[MUD-Dev] Striving for originality

Matt Chatterley matt at eldoops.co.uk
Sun Jun 9 02:24:36 CEST 2002


On Fri, 7 Jun 2002, Kwon Ekstrom wrote:
> From: "Matt Chatterley" <matt at eldoops.co.uk>

>> To my mind, the place of the battlefield mage is at the back,
>> behind the others -- the same as we might use artillery support
>> in a more modern battle.

> I agree, a spell-caster shouldn't be out where he/she can take
> damage.

Of course, as other posters have pointed out, and as I should
probably have said; not all mages will *be* on the battle field. ;)
The role of the magic user in a battle is, to me, a flexible one and
context dependant. If the enemy force contains one or more magic
users, then the role of the mage on your side might be more focussed
on neutralizing their magics. Or, the priest you brought along (or
even a wizard), might use supportive magic (healing, shielding,
hasting, etc) to help the fighters along.

Either way, those spellcasters who do enter combat within the world
I'm creating will seldom do so on the front line. As I hinted in
another post, though, the idea of a 'dual-class' (to hark back to
D&D yet again) character is totally possible (especially since my
notion of 'classes' and so forth will be non restrictive and no so
definite). You might have a swordsman who can weave a few simple
spells, and who uses this magic to protect himself before he wades
in.

>> One approach to limiting the effectiveness of mages in combat
>> (and one which I will most likely use) is that of distraction. If
>> you're

> Distraction is an old philosophy... but is detrimental to solo mud
> play which is why it isn't used often.

Aye. Bar the example above of the combination character, I don't
intend combat-orientated magic users to be a solo-playable character
type. It doesn't fit for the world which I wish to create. Of
course, at high levels of power, it becomes more feasible. The
wizard might be able to shield himself almost totally from the
attacks of weaker enemies and then concentrate on striking them down
while they fail to penetrate his defenses. Still; rare. It's not a
style of play that I really mind excluding from my world. :)

The solo magic types are more likely to be students, teachers,
researchers, item-creators, and so forth.

>> carefully weaving the threads of a spell together, the last thing
>> you need is to be whapped with a sword, kicked in the groin, or
>> to get shot. As soon as someone on the other side spots the signs
>> of spellcasting, you'd become a target -- they know that magic
>> thrown against them could be devastating, and would really want
>> to prevent it.

> My solution is limited distraction.  Small but useful spells (or
> ones whose power level you exceed greatly) should be able to cast
> rapidly, almost instantly.  A spell caster casting extremely
> powerful magic should have a wait, and be subject to distraction.

I certainly have something along these lines in mind, with casting
times, casting complexities, different components (gestures, words,
ingredients, etc). Of course, this, and the problem of solo play is
less of a problem for me -- the entire game premise which I am
working from is really intended for group play (or solo play with
NPC support).

>> Hence there might be several different types of battlefield
>> mage. The one who stands right at the back and throws in the big
>> bangs; the ones who cast a few protective spells beforehand, then
>> draw their sword and wade in, and so forth.

> I don't see a battle-mage as being a warrior (although my
> classless system supports being able to learn both warrior and
> magical skills).

Nod. There are many different interpretations, and many different
styles.  In particular, one guild likely to be included in my game
world is a priesthood (or temple, of sorts) of "knights" who are
skilled in armed combat and basic magics -- for them, these skills
complement each other.

--Matt

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



More information about the mud-dev-archive mailing list