[MUD-Dev] Condsiders

Klyde Beattie agius_ at hotmail.com
Fri Feb 23 23:21:34 CET 2001


JB wrote:

> I agree with your goals.  I disagree with your approach.  I do not >
> want player perceptions to be at issue.  I want character
> perceptions > to be.

Yes, one of the drawbacks of my approach is that the player's skills
are relied on as well as the characters. This is of course unavoidable
in game situations but is typicly limited to roleplaying inteligence,
wisdom and charisma type non physical skills. I would suggest that the
characters skills would make it easier or harder for the player, but
the player would still be responsable. The benefit is that the player
is more submerged into the character. I would argue that for *most*
players this would make the game more fun.


> I would tend to rely on a third person view, but where the objects
> in > the world are presented according to the character's
> perceptions.  > Where the character is looking, the player would be
> presented with a > full color, detailed view of the area, with the
> actual viewing > frustrum clearly demarked.  As we transition from
> the foveal area of > the character's field of view into the
> peripheral areas, the objects > start to lower in polygon count and
> the colors might wash out.  As we > go beyond even the peripheral
> view, objects are only displayed when > they make a sound and are
> presented as grey lumps.  Noises that your > character makes can
> mask noises around it.  So if you are walking > down a country road
> singing a song, it means that a bandit might be > able to sneak up
> behind you and club you.

Again this is quite a good idea, and if you want to spend the large
amount of mythical man hours on it, i'm confident it would work. The
disadvantage is that you are pertraying sound as a visual object, i
think you will get alot of people playing paranoid characters, As a
blob aproaches them from behind the draw thier sword and turn around,
only to see a squirel or a blowing leaf. Which makes the same *amount*
of sound that a good thief would want to make.

> Character perceptions are key to interesting play and entertaining
> scenarios. As characters acquire new skills, they will acquire new >
> perceptions to accompany those skills.  These will be aids to the >
> player in deploying those skills.  A classic one would be the
> archery > perception skill.  When the player is ready to line up a
> shot, the > character perception tool pops up.It lets the player
> indicate the > target and see the arc that the shot will take.  It
> will do other > things such as indicate the rough area where the
> arrow will land, > consider range, ambient conditions, equipment
> used, character skills, > etc.  As the player maintains the aiming
> without firing, that area > will tend to start to shrink.  The
> higher the skill, the more > accurage the shot, so the target area
> may drop to almost a pinpoint.

This is what i believe to be one of the strongest ideas, when a
character gets a skill, that skill is portrayed to the player in a way
that makes him feel that the character realy knows the skill. not just
gets +40% to damage and -1 range modifier. In fact i think that
interface should be the largest part of a skill, anyone can fire a
bow, but someone who knows how will do it better not get bonuses to
hit and damage etc.


> Many perceptions that are acquired will simply be appraisal skills.
> > As the character is wandering about, it can be told by the player
> to > keep an eye out for high quality longswords.  The character has
> that > perception because it has some corresponding skill, such as >
> swordsmithing or some form of advanced swordfighting.  Because the >
> character perceptions are involved, the player doesn't have to know
> > what a high quality longsword looks like.  The internal systems
> know > the character's perceptions and it knows the attributes of
> objects.  > It figures out if the character 'notices' things and
> then it gets the > client application to notify the player.  In the
> case of a graphical > client and the longsword, the client might
> actually draw in the > longsword at another character's hip and
> flash it in red.  When the > player clicks on it or just presses a
> button to ask about the > currently 'noticed' item, the client tells
> the player that it matches > a perception query that the player had
> set up.  The 'high quality > longsword' query

I would (probably cause i'm picky and always have mmy own way of doing
things) say that a sword/item would always look the way it does, and
you would have to spend time and maybe use tools to apprase it, anyone
can learn how to identify a mithral sword, but only someone with skill
could identify a fake mithral sword, or determine the value and make
of that sword. So again i simply argue that the player should be able
to attempt to discern what an item is without a skill, but wouldn,t
get any tools to help him.


> The only reason that I would provide a first person view for my >
> players would be so that they could admire panoramic views or simply
> > experience things through the eyes of their character.  This can
> be > handy when doing things like playing card games, socializing
> with > friends, reading in-game documents, etc.  When in first
> person view, > it means that peripheral vision cues and what-not are
> sacrificed to > some degree.

I agree, but to what degree is the issue. A well programed 1st person
view with peripheral vision and certian cues based on character
abilitys would be able to provide an interface that sacrfices little
amounts of visual cues, and provides a large amount of submersiveness.
I think the question would be " is submersiveness more important than
percise representation of visual cues."

I would start it off by saying that IMO subvesiveness makes a game
seem more real to the player, and gives the player a feeling that
doesn't come in other shapes and sizes. It's almost it's own emotion,
to feel like you are the character.

-Klyde


_______________________________________________
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