[MUD-Dev] Moving away from the level based system

John Buehler johnbue at msn.com
Wed Jan 3 08:28:46 CET 2001


Hulbert, Leland writes:

> From: John Buehler [mailto:johnbue at msn.com]
> Sent: Friday, December 29, 2000 9:24 PM
>
>> Forging a sword should be the same way.
>>
>> How many times should the metal be folded, assuming the technique
>> of folding is known?  How long should the tang be?  How long should
>> the blade be?  How wide?  Where should the balance point be?  And
>> so on.  These things will come out as the player directs his
>> character to strike the metal here or there, to fold it another
>> time, to apply this treatment or that, to cool the metal in oil or
>> water, or any of a number of treatments.  These are the decisions
>> that an afficianado of sword making enjoys.  Hearing the ring of
>> the hammer, the quenching of the heated metal, the pump of the
>> bellows, etc.  Mistakes will be made by less-skilled characters and
>> the player must decide on a path of correction - just as a new
>> twist in a combat scenario forced the player to make decisions.
>
> The trouble I have with this is that the player then needs to
> acquire the skill of forging, at least within the confines of the
> MUD skill system.  Not the character, the player.  I would love the
> idea of playing a skillful smith, and managing resources to get
> proper quality I can agree with.  But I am not prepared to learn
> where, when and how to strike the metal just to play my character.
> My smith should know these things, I do not.  I want to be able to
> tell my smith to forge a sword with X materials, and he will do it
> to the best of his ability.  Combat(and many other skills) are run
> this way...I do not know how to properly swing a sword to kill
> something, or pick a lock, but my characters do.

Well, you must be making some kind of decisions and learning
*something* as a player.  Do you like combat to be Target, Kill, Wait?
I doubt it.  People interested in combat like to tell their character
what to do as the fight progresses.  I've seen a number of discussions
where combat is desired to be far more than it is.  Players want to
see far more action by the characters, and I've suggested that the
combat system should encourage players to make some decision every
couple seconds.  Where to move to during combat, how aggressive to be,
what kind of damage to inflict (lethal, stun, crippling) and so on.
The character does all the attacking, running, jumping, dodging and so
on, but the player remains engaged in the task of combat.  Yes, this
means that player skill becomes important, but not to the point of
twitch skills being important.  Think of the pace of 'action',
one... two...  'action' one... two... three... 'action' ...  Actions
are single key presses or mouse clicks.

In the same vein, blacksmithing is a game unto itself.  Forget about
combat and monsters being in the world.  The player who is engaging in
blacksmithing is doing just that.  It's him, the forge, metal, tools
and possibly some journeymen and/or apprentices.  That's the world of
items and characters that must entertain the player while the weapon
or item is being forged, cast or whatever.  It really is its own game.
Call it 'Blacksmith World'.  All that happens is that player
characters craft and repair iron and steel items, visit the tavern and
other towns.  Such a game is appealing to those who like to craft and
repair iron and steel items.  They will roleplay or powergame within
the world of the blacksmiths.  They are the best roleplaying
blacksmithing out there.  They immerse themselves in blacksmithing.
If they're not interested in blacksmithing, the don't play
blacksmithing.

You see, this is precisely what these games need to do.  The people
who enjoy the secondary tasks of the world never seem to get enough
out of the way those tasks are implemented.  That's because they are
viewed as *secondary* tasks.  Characters are assumed to go out and
kill stuff.  In order to relieve the monotony of killing stuff, they
can toy around with trades.  Aren't the trades cute?  Well I want the
trades, fishing, cooking, running a farm, whatever, to be just as
engaging to a player as combat is.  But not necessarily to the same
player.  Cooking will appeal to one group of players, combat to
another, fishing to yet another.  Most players will want to do
multiple things.

In brief, I want a virtual environment into which a game company
starts introducing full blown systems for every task that they tackle.
Start with combat and then put in magic.  Then put in tracking, as in
hunting.  But not a namby-pamby tracking system.  Put weight into the
thing.  There's knowing different animal signs, being able to keep the
track going across different kinds of terrain, being able to move
quickly as the detection skill goes up, learning more about the animal
being tracked as the track progresses.  This is what an afficianado of
the hunt is interested in.

Put in archery, with true distinctions between bow and arrow types.
Don't put in silly magical arrow types as with Asheron's Call.  Find
out something interesting about archery to engage the player.  Why
bother with magic when there's so much depth to archery in the first
place?  Those interested in archery will get into archery in the game
world.

In the grandiose plan, developing systems for this world becomes
something that third parties start to get into.  Put each system onto
a distinct server and have each of those servers talk to whatever
coordination servers are needed over 100MB lines.  Turn this puppy
into something so vast and complicated that no player could ever hope
to try to macro it or even learn it all.

By the way, engaging players during any given task and having them
make intelligent decisions is exactly what another recent poster was
asking for when they suggested that random questions should pop up -
like 'What is 2+2?'.  A reply suggested that the questions stay
in-game.  Well, this is precisely where that idea leads.

JB


_______________________________________________
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