Dynamic social system -> eliminate 'emote' !
Goto page 1, 2  Next
 
Post new topic   Reply to topic    mudlab.org Forum Index -> Design
View previous topic :: View next topic  
Author Message
Grem



Joined: 15 May 2005
Posts: 36
Location: Maryland

PostPosted: Tue May 31, 2005 12:35 am    Post subject: Dynamic social system -> eliminate 'emote' ! Reply with quote

So how many different ways can a player 'smile' ? Should the MUD track the dental structure of the player, lip width, or grin style when displaying the message to players in the room? Can command-based socials efficiently replace 'emote' and 'pose' ?

Can the line between 'roleplaying' and 'hack-n-slash' MUDs be thinned by providing a dynamic system that allows players to interact with each other by performing social commands?

The biggest problem with the 'emote' command is that it gives too much power to the player character's action potential. Utilizing the command, players can force their character to do 'anything'. Although the command works well in controlled environments, many MUDs suffer from emote abuse, particularly hack-n-slash MUDs.

So how can a social command system be written to allow extreme flexability of character social actions, all the while maintaining realism and abuse prevention?


nod smile grem
You nod and smile at Grem.

frown smack grem
You frown and smack Grem.


How can adjectives and adverbs be presented into the flow? Should players have emotions and demeanors that effect the statements? Should emotions be player-set, or stat-set?


mood happy
nod smile grem
You nod and smile happily at Grem.

mood angry
frown smack face grem
You frown at Grem and smack his face angrily!



How should social commands be parsed? How should commands link together? What happens when a command is invalid?


shake hand grem
You shake Grem's hand.


What happens if Grem doesn't want to shake your hand? How does the opposing player react to socials? In the above example, the 'shake' command has assumed that Grem has shaken back. This is another problem with emotes, 'assumed actions from the opposing party'. Anyway, this unstructured post is sort of in the format of 'thinking out loud'. Im just typing thoughts as they come to me, feel free to respond with something a bit more structured and realistic. =)
Back to top
View user's profile Send private message Send e-mail Visit poster's website AIM Address
Author Message
KaVir



Joined: 11 May 2005
Posts: 565
Location: Munich

PostPosted: Tue May 31, 2005 7:56 am    Post subject: Reply with quote

Quote:
So how many different ways can a player 'smile' ?


Lots.

Quote:
Should the MUD track the dental structure of the player, lip width, or grin style when displaying the message to players in the room?


Could do, although if the socials are purely cosmetic in nature then I'm not sure how worthwhile it would be.

Quote:
Can command-based socials efficiently replace 'emote' and 'pose' ?


Not practically, no. However some muds combine the two, allowing socials to be followed by emote-like text. This allows you to keep most of the customisable aspects of an emote combined with much of the coded support of socials (eg, having a grin displayed only to those who can see you, or a laugh displayed only to those who can hear). Of course you wouldn't be able to differentiate between a happy smile and an evil smile without having a more cumbersome interface (or a complex parsing system that would probably miss certain combinations).

Quote:
Can the line between 'roleplaying' and 'hack-n-slash' MUDs be thinned by providing a dynamic system that allows players to interact with each other by performing social commands?


No, I don't believe so. The differences between RP and HnS are due to a number of reasons, not least of which is the mindset of the players they attract. I don't think an advanced socials system would make much difference at all, to be honest (although removing emotes, no matter what they're replaced with, is likely to alienate some of the hardcore RPers).

However that's no reason not to implement a better socials system!

Quote:
The biggest problem with the 'emote' command is that it gives too much power to the player character's action potential. Utilizing the command, players can force their character to do 'anything'. Although the command works well in controlled environments, many MUDs suffer from emote abuse, particularly hack-n-slash MUDs.


Well the emotes are only cosmetic - just colourise them differently from other text, or display them in brackets, or in some other way mark them as emotes. As long as people know they're emotes they can't really be abused (except in an RP sense, but that's really a different issue).

Quote:
What happens if Grem doesn't want to shake your hand?


I've ignored contact socials for now specifically because of this sort of issue. I'll probably end up adding some sort of consent system, allowing players to either manually accept the handshake or concent one or more other people to automatically accept their socials. Some socials will probably be tied in to the combat system so that they can be used as non-damaging attacks which automatically hit if your opponent has given you consent. So you could offer to kiss someone (allowing them to kiss you back), or just try and plant a kiss on them (in which case they'd try to dodge).
Back to top
View user's profile Send private message Visit poster's website
Author Message
Teelf



Joined: 12 May 2005
Posts: 21
Location: Seattle, WA

PostPosted: Tue May 31, 2005 2:28 pm    Post subject: Reply with quote

Skotos has a fairly advanced system for eliminating emote that they call the evocation system.
Back to top
View user's profile Send private message Send e-mail Visit poster's website AIM Address
Author Message
KaVir



Joined: 11 May 2005
Posts: 565
Location: Munich

PostPosted: Tue May 31, 2005 3:05 pm    Post subject: Reply with quote

Teelf wrote:
Skotos has a fairly advanced system for eliminating emote that they call the evocation system.


I handle similar options within 'say', which basically breaks down the argument as follows:

1) If there's a smiley at the end of your argument, chop it off and use it in addition to the 'say' text based on the type of smiley used.

2) If there's punctuation at the end of your argument (after chopping off any smilies), use it to convert 'say' into something more appropriate, with double punctuation marks stripped and emphasis added to the new say message.

3) If the first character of the argument is '@', then strip off the next token as the target of your say - or if the first three characters are 'to' followed by a space, then do the same, except that if the token isn't a valid target then assume that 'to' is in fact supposed to be part of what you're saying.

4) If the first character of your argument (after chopping off any target for your 'say') is one of the gesture characters (+ for nod, - for shake, etc) then chop it off and apply the appropriate gesture.

5) Capitalise the first letter, and add a full stop to the end of the sentence if there's no other punctuation.

The command is therefore fully compatible with what most people are used to, while allowing more creativity to those who wish to use it. For example:

> say hi
You say, 'Hi.'

> say @kavir hi :P
You grin at KaVir and say to him, 'Hi.'

> say -nope...:/
You shake your head with a grimace and mutter, 'Nope...'

> say @kavir ^Really?? :D
You raise your eyebrow at KaVir with a laugh and ask him in amazement, 'Really?'
Back to top
View user's profile Send private message Visit poster's website
Author Message
Ashon



Joined: 11 May 2005
Posts: 86
Location: Seattle

PostPosted: Tue May 31, 2005 3:24 pm    Post subject: Re: Dynamic social system -> eliminate 'emote' ! Reply with quote

Grem wrote:
So how many different ways can a player 'smile' ? Should the MUD track the dental structure of the player, lip width, or grin style when displaying the message to players in the room?


Track the dental structure if you want to, but it's probably not cost effective if you only use it for the smile. But, to answer the spirit of your question no, it probably shouldn't need to get that detailed.

Quote:
Can command-based socials efficiently replace 'emote' and 'pose' ?


Wow, that's a tough question. I think it depends on what the goals of emote and pose are in the game system.

Quote:
Can the line between 'roleplaying' and 'hack-n-slash' MUDs be thinned by providing a dynamic system that allows players to interact with each other by performing social commands?


I don't think so. The hack-n-slash muds would probably continue down the path of creating toon'ish socials, but they'd be more elaborate.

Quote:
The biggest problem with the 'emote' command is that it gives too much power to the player character's action potential. Utilizing the command, players can force their character to do 'anything'. Although the command works well in controlled environments, many MUDs suffer from emote abuse, particularly hack-n-slash MUDs.


Agreed. The emote command while nice for some instances in which certain socials do not address has too much power in a game to enforce action upon other people. I think that this is why a lot of Emote's are precursed with either an * or some other designation, that this, is not a game altering command being sent from the server.


Quote:
So how can a social command system be written to allow extreme flexability of character social actions, all the while maintaining realism and abuse prevention?


This has been the topic of recent discussion. But we've been avoiding the abuse angle. The only way that I see to avoid the abuse is to remove the emote command. Implement Consent, and turn socials into a more combat oriented system. (See: Social Combat)

Quote:
How can adjectives and adverbs be presented into the flow? Should players have emotions and demeanors that effect the statements? Should emotions be player-set, or stat-set?


I think that stat-set is a good way to go about it. But with a player-set option to it. The player can update their mood to make it more appropriate. But the system to should take over and degrade it to a stat-set. However, the stat-set should be able to handle a little bit of learning, or re-mapping. So if a player, continually updates their mood to happy after combat, they will start to automatically become happy after combat.

There's no way for us to predict how talking and interacting with other players will affect a PC's mood. So to encourage the roleplaying, the player should definitely be able to fine-control it. But leaving it solely in the player's hands, will give us the sam situation with player descriptions on most muds, and thus become an ineffectual tool.


Quote:
What happens if Grem doesn't want to shake your hand? How does the opposing player react to socials? In the above example, the 'shake' command has assumed that Grem has shaken back. This is another problem with emotes, 'assumed actions from the opposing party'. Anyway, this unstructured post is sort of in the format of 'thinking out loud'. Im just typing thoughts as they come to me, feel free to respond with something a bit more structured and realistic. =)


Well, if you start by categorizing your socials into the different types: Tactile(Touch), Auditory(Sound), Visual(Sight), Olfactory(Smell), OOC, and to some extent Gustatory(Taste). And you've got underlying mechanisms to handle each of these Senses (Minus OOC) you can see the ones that require Consent (For the most part: Tactile.) The second part I would add is whether it is an 'emotional' part to it. Is it an Aggressive Social? A Loving Social? etc ... And then build the consent mechanism. I plan on letting player be able to:

>shake Grem override

So that they can attempt to override the consent mechanism. But that goes into the social combat systems.

I posted my results on the Social Breakdown at TMC: The Impact of Socials, and what the mean to a mud
Back to top
View user's profile Send private message Send e-mail Visit poster's website AIM Address Yahoo Messenger MSN Messenger
Author Message
Spazmatic



Joined: 18 May 2005
Posts: 76
Location: Pittsburgh, PA

PostPosted: Tue May 31, 2005 5:30 pm    Post subject: Reply with quote

Quote:
Can the line between 'roleplaying' and 'hack-n-slash' MUDs be thinned by providing a dynamic system that allows players to interact with each other by performing social commands?


I do believe in advanced socials, but I don't believe in removing emotes. Notably, socials help create a common medium of interaction, especially for players a little less gifted in the prose department. More importantly, though, socials can be coded into the mud - NPCs can react, certain socials can be blocked in certain situations, they can be tracked to help with RP rewards, etcetera. However, I don't believe you can ever replace the power of emote for roleplaying purposes - there are always details you want to include that simply aren't supported by code. As happy as I am using complex social systems to "Spazmatic smiles happily and shouts with exuberance, 'Wonderful!'", sometimes, to add enough personality and style to a character, I need more.

That said, some approaches, both done before and not:

1) Forever Always, by Iain Merrick, is a piece of IF that features adjective enhanced conversation with NPCs as a key plot device. Even at that level, you could add a lot to NPC interaction in quests, or even in general! It's just the "talk softly", "shout loudly" type of system, but its use with NPCs is, I think, a good example of how that can work.

2) A number of muds offer socials that are at least partially based on player status - often times, these are coded on a case by case basis, but include such wonderful things as including your weapon when you wave, i.e. if you're dual wielding swords, "Spazmatic waves at you with his sword of goblin slaying."

3) A simple addition that would greatly enhance most social systems, but isn't used, is '&'. Why shouldn't players be able to both smile and wave in a sentence? It's not used a lot, but being able to string together a series of socials would go a long way towards enhancing socials.

4) Some muds allow the embedding or inclusion, in some form of another, of freeform text into emotes. By forcing structure on player additions, it solves many (though not all) abuse problems, and allows the system to react to player activities. However, it's kind of messy, in general - some of the more advanced xemote commands are good examples.

There's a lot of stuff, including more specific examples, but I've got to get to work. I'll add in more later.
Back to top
View user's profile Send private message
Author Message
Tyche



Joined: 13 May 2005
Posts: 176
Location: Ohio, USA

PostPosted: Wed Jun 01, 2005 6:59 am    Post subject: Reply with quote

Teelf wrote:
Skotos has a fairly advanced system for eliminating emote that they call the evocation system.


Quote:

Problems Solved by Skotos Evocation System
In creating the Skotos Evocation System we decided to specifically forbid freeform emotes. It is our belief that emotes have four serious probems:

1. Arbitrary expressions rely on extensive creativy on the part of the players and thus are quite intimidating to new players.
2. Arbitrary expressions can be abused in a game context. They can refer to object that don't exist or include actions that aren't possible.
3. Arbitrary expressions can be abusive to other players and even can be harassing
4. Arbitrary expressions are largely opaque to NPCs and to the game, and thus they are unable to respond appropriately.


[rant on]
Sure...
Tyche shouts, "Bubba, go f*** yourself and the horse you rode in on!"

Now I have referred to a horse that doesn't exist and an action generally considered to be impossible. I am probably engaging in abusive behavior and have intimidated a new player named Bubba. It's still opaque to their NPCs.

And frankly...
Tyche whingingly ejaculates, "But your evocation system is stifling my creativity and is not advanced!"
SYNTAX ERROR - ejaculate is not a valid evocation (Sir Arthur Conan Doyle be damned)
SYNTAX ERROR - whiningly is not a valid adverb (Sinclair Lewis be damned)

More realistically...
Tyche seductively whispers, "Nancy you're an ugly mean nasty bitch."
Nancy(NPC), "Ooo I love it when you whisper seductively. Here's the key to the dungeon sweetheart."

Turning emotes into a limited guess the adverb/verb game is not my idea of advanced, nor is the reduction of player emotes/speech to that small subset which can be parsed and understood by brain dead npc's by a primitive infocom style parser particulary interesting.

There are a couple things wrong. First it doesn't solve any of the listed problems, even if one were to acknowledge the problems are valid. The solution to their "problems" is to take away all player input and replace it with handcrafted innocuous and inoffensive socials. Of course 1. translates to "let's reduce all our players to the same level of stupidity" anyway. Why do I say that? Because instead of addressing the emote interface, or adding new capability, they instead remove capability. Secondly, it's lazy and wholly unimpressive...Why not even attempt NLP, even crudely? There are a number of impressive algorithms for processing freeform text. There are even simple and fast ones that actually capture the same essentials without making the player a preprocessor.

No this is a giant leap backwards from freeform player creativity to Ultima I.

[rant off]

There I feel better now. Wink
Back to top
View user's profile Send private message Visit poster's website
Author Message
Gromble



Joined: 08 Oct 2005
Posts: 23

PostPosted: Sat Oct 08, 2005 3:56 pm    Post subject: Reply with quote

I've been thinking of ditching emote and static socials altogether and allowing every player to define their own custom socials.

So a player can be as expressive as they like through the range of custom socials they've defined. I've seen mud's with literally hundreds of socials available in a futile attempt to satisfy the expressive needs of every player. Why bother? Give the players the tools to handle it themselves.

There's a danger of a player defining obscene socials and such, but then that danger already exists via any communication command. Besides, you can always scan the socials offline and discipline the player according to your mud's policy on such matters.

-Gromble
Back to top
View user's profile Send private message
Author Message
Tyche



Joined: 13 May 2005
Posts: 176
Location: Ohio, USA

PostPosted: Sat Oct 08, 2005 6:54 pm    Post subject: Reply with quote

Gromble wrote:
I've been thinking of ditching emote and static socials altogether and allowing every player to define their own custom socials.


emote?


Edit: Sorry I'd didn't mean that to be funny but just had to laugh after I reread the thread title.
Back to top
View user's profile Send private message Visit poster's website
Author Message
Lared



Joined: 07 Oct 2005
Posts: 26

PostPosted: Sun Oct 09, 2005 1:47 pm    Post subject: Reply with quote

Gromble wrote:
I've been thinking of ditching emote and static socials altogether and allowing every player to define their own custom socials.

So a player can be as expressive as they like through the range of custom socials they've defined. I've seen mud's with literally hundreds of socials available in a futile attempt to satisfy the expressive needs of every player. Why bother? Give the players the tools to handle it themselves.

There's a danger of a player defining obscene socials and such, but then that danger already exists via any communication command. Besides, you can always scan the socials offline and discipline the player according to your mud's policy on such matters.

-Gromble


...Why bother with socials at all if a player does his own? Why not rely on aliases and make a smart-emote style command? I feel confident enough in my position on this one to make a blanket statement: removing emote always hamstrings RP.

The MUD I play regularly on, Lensmoor, does this. A-like so:

Quote:

help rmote
RMOTE
Syntax: rmote <message>

Rmote is a room-emote. It allows specification of up to 20 different
people replacements, and 20 different object replacements. Within a
rmote message, square brackets [] are used to enclose a specified person
and angle brackets <> are to specify an item in the room, or held.

When selecting a person, the first letter inside the brackets determines
what replacement will be used. A "N" is the name of the person, a "M"
is replaced by Him/Her/It, a "E" is replaced with a He/She/It, a
"S" is replaced with a His/Hers/Its, and a "Z" is replaced by the name of
the person followed with 's. The person specified will see a "you" or
"your", while the rest of the room sees the other replacement.

Example:
rmote [Ntestbob] smiles at [Narawn] and shows [Marawn] [Stestbob] <sword>.

Will replace with:
Testbob smiles at Arawn and shows him his longsword.

The speaker must include their own name in the text somewhere.


I have numerous custom socials designed using RMOTE. I'm coding a similar command in the MUD I'm currently hacking away at.
Back to top
View user's profile Send private message
Author Message
Gromble



Joined: 08 Oct 2005
Posts: 23

PostPosted: Sun Oct 09, 2005 3:33 pm    Post subject: Reply with quote

Lared wrote:
The MUD I play regularly on, Lensmoor, does this. A-like so:

Quote:

help rmote
RMOTE
Syntax: rmote <message>

Rmote is a room-emote. It allows specification of up to 20 different
people replacements, and 20 different object replacements. Within a
rmote message, square brackets [] are used to enclose a specified person
and angle brackets <> are to specify an item in the room, or held.

When selecting a person, the first letter inside the brackets determines
what replacement will be used. A "N" is the name of the person, a "M"
is replaced by Him/Her/It, a "E" is replaced with a He/She/It, a
"S" is replaced with a His/Hers/Its, and a "Z" is replaced by the name of
the person followed with 's. The person specified will see a "you" or
"your", while the rest of the room sees the other replacement.

Example:
rmote [Ntestbob] smiles at [Narawn] and shows [Marawn] [Stestbob] <sword>.

Will replace with:
Testbob smiles at Arawn and shows him his longsword.

The speaker must include their own name in the text somewhere.


I have numerous custom socials designed using RMOTE. I'm coding a similar command in the MUD I'm currently hacking away at.


This is pretty much where I am headed except that I'd want the player to be able to define these "rmote" strings ahead of time so that they can simply enter an alias for it (along with sufficient arguments for doing the appropriate substitutions).

Perhaps supporting both the pre-defined strings and the "on the fly" capability provides the most flexibility.

-Gromble
Back to top
View user's profile Send private message
Author Message
Lared



Joined: 07 Oct 2005
Posts: 26

PostPosted: Sun Oct 09, 2005 3:56 pm    Post subject: Reply with quote

Sure--but most MUDs already have it built-in. It's called an alias.

It's like building a wall and building a vertical weight support and elemental protection unit. They're the same thing. Razz
Back to top
View user's profile Send private message
Author Message
Gromble



Joined: 08 Oct 2005
Posts: 23

PostPosted: Sun Oct 09, 2005 9:48 pm    Post subject: Reply with quote

Lared wrote:
Sure--but most MUDs already have it built-in. It's called an alias.


No, I don't think it is because you may want to define multilple strings depending on desired detail and whether the social is targeted. My thinking is to let the player define these strings themselves rather than trying to statically define every possible social the players may want. In DIKUese...

selfWithTarg = "You smile at $n."
selfWithoutTarg= "You smile."
roomWithTarg = "$N smiles at $n."
roomWithoutTarg = "$N smiles."
targ = "$N smiles at you."

This is a very simple case where the strings could be reduced to a single string that the server can handle without much effort (e.g. knowing when to substitute "you" and "smile" vs "smiles"), but it may be preferable to give the player more flexibility and allow each one to be customized.

From your previous example, I didn't see how this could be done via an "rmote" alias. But, feel free to enlighten me and I'll use your approach instead.

-Gromble
Back to top
View user's profile Send private message
Author Message
Tyche



Joined: 13 May 2005
Posts: 176
Location: Ohio, USA

PostPosted: Sun Oct 09, 2005 11:20 pm    Post subject: Reply with quote

Gromble wrote:

In DIKUese...

selfWithTarg = "You smile at $n."
selfWithoutTarg= "You smile."
roomWithTarg = "$N smiles at $n."
roomWithoutTarg = "$N smiles."
targ = "$N smiles at you."

-Gromble


We had a OLC command, socedit, that allowed one edit socials online. So if you're working in Dikuese you might either:

A) Open up the OLC social editing commands to players.
B) Add magic ownership bits to it and then open it up to players to allow editting of their own socials only, but use of all.
C) Point the command from the global table to a local table in the players own structure. Save it, and scan both tables during parsing.
Back to top
View user's profile Send private message Visit poster's website
Author Message
Lared



Joined: 07 Oct 2005
Posts: 26

PostPosted: Mon Oct 10, 2005 3:24 pm    Post subject: Reply with quote

Gromble wrote:
Lared wrote:
Sure--but most MUDs already have it built-in. It's called an alias.


No, I don't think it is because you may want to define multilple strings depending on desired detail and whether the social is targeted. My thinking is to let the player define these strings themselves rather than trying to statically define every possible social the players may want. In DIKUese...

selfWithTarg = "You smile at $n."
selfWithoutTarg= "You smile."
roomWithTarg = "$N smiles at $n."
roomWithoutTarg = "$N smiles."
targ = "$N smiles at you."

This is a very simple case where the strings could be reduced to a single string that the server can handle without much effort (e.g. knowing when to substitute "you" and "smile" vs "smiles"), but it may be preferable to give the player more flexibility and allow each one to be customized.

From your previous example, I didn't see how this could be done via an "rmote" alias. But, feel free to enlighten me and I'll use your approach instead.

-Gromble


Well, for one...I still don't see the value of a no-target social not being coded, such as "smile." However, I use RMOTE on this particular MUD in pseudosocials all the time.

rmote [nLared] smiles at [n$]. ($ is the alias argument stand-in)

Room sees: Lared smiles at $.
Target sees: Lared smiles at you.
You see: You smiles at $. (The coder didn't grammarize it, but it's being sent to you alone, so I don't really see a problem with it.)

Basically...I'm just wondering about the efficacy of this, and "what's the point." For null-target socials, just emote it. This smells like a memory and disk-space hog if you've got serious RPers who'd define a large number of them, and a spurious feature if you don't.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    mudlab.org Forum Index -> Design All times are GMT
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

Powered by phpBB © 2001, 2002 phpBB Group
BBTech Template by © 2003-04 MDesign