images from http://www.griatch-art.deviantart.com
The act of emoting, or posing, is an important part of many online text games, but the way emoting works varies quite a bit between games. This article lists and discusses some common options. It is mainly aimed at those interested in implementing their own game.
An emote should not be confused with other forms of in-game communication such as tells and channel messages. An “emote” is here defined as text displayed as originating from the in-game character only (usually only visible to those in the same game location).
When deciding on which emoting system to go for, it is important to consider appropriateness relative to the type of game. Emotes traditionally serve different roles depending on game (ordered roughly from least roleplay-centric to most roleplay-centric):
- They may act as a form of “smileys” to convey an emotion, emphasis or personal touch during play.
- They may act as quick ways to communicate in-game information, in-character or not.
- They may act as an actual extension of coded systems (such as being parsed for commands, language or offer in-emote command execution).
- They may act as a filler between what a charactershould realistically be able to do and what the game’s code actually allows the character to do. In some games this is only window dressing; in others, actions done in an emote are just as binding as an action done “in code”.
- They may be the only legal way to affect the game world, such as in many MUSH-style games.
Actor versus Director stance
You are emoting that you are standing in a bar. Consider the difference between these two emote returns:
1. You see:
You are standing by the bar, your eyes narrowed as you look around.
Others see: Griatch is standing by the bar, his eyes narrowed as he looks around.
2. You see:
Griatch is standing by the bar, his eyes narrowed as he looks around.
Others see: Griatch is standing by the bar, his eyes narrowed as he looks around.
(Just how the emote command syntax looks for each case is irrelevant at the moment.) The first of these is an example of Actor stance — you (the Player) “are” the character. You see and hear what the character experiences. The second represents Director stance (or “Author stance” depending on how strict you are with definitions). In the latter you are seeing your character from the “outside” and control it as a sort of puppet master or director. Apart from the obvious use of second-person “you”, there are some deeper philosophical differences between the two.
Most MUD-style games tend to use some variant of actor stance whereas MUSHes and other storytelling-focused games tend toward director stance. Many games also confuse the issue by using second-person form for coded messages (“You feel hungry”) even though roleplay is otherwise done in director stance.
The actor stance is the traditional stance in tabletop roleplaying. One common argument for using actor stance is that “being” the character and seeing what they see “aids immersion”. I personally think that this is a weak argument on its own. Books have been very successful at getting us to feel for and relate to characters without explicitly suggesting that we are that character. One could argue that interactive game avatars work differently — but when your character gets hit by a sword, jumps into a lava pit or has their head bit off by a dragon, you generally have no trouble recognizing that this happens to someone else and not to you. As a social species we are very good at putting ourselves in and out of other people’s shoes on demand, using “you” or not.
Vice-versa, the drawback of the director stance is that, taken to the extreme, there is no reason for the game to limit what you as the player know, only what your character knows. It may put a lot of strain on the player to separate player knowledge from character knowledge.
For example, if you go full-director stance, it would make no sense for the game to hide that another character, known to be an assassin, is secretly sneaking up on you. As long as the game makes it clear that your character has no clue (for example by telling you that you failed a detection roll) you are expected to act as though you are oblivious. For a game type where non-consensual character-killing is rare or impossible (such as many a MUSH) this is fine; it just leads to an interesting scene. But for games where a coded backstab could kill your character, this puts a lot of emphasis on the maturity of the player. What if the targeted player suddenly makes their character leave the room? Would they have done so regardless of the assassin, or are they wrongly using their player knowledge to cheat and get their character out of harm’s way? It can be very hard to tell. Simply hiding the information from the player as well as from the character sidesteps the problem entirely.
Technically, implementing the emote-handling for actor stance is more complex than director-stance parsing. Not only do you have to track who is seeing the text, your parser needs to know how to modify the grammar of your MUD’s language dynamically (“You are” versus “Griatch is”, for example). In many codebases, the combination of rigid coded systems (which often uses stylistic second-person by default) and director-style emotes leads to a somewhat disparate mix between the two.
The debate of whether to use actor or director stance is leaking over from the tabletop roleplaying world. Which to choose is very much a matter of preference, but when implementing your system, at least take the time to consider what you are aiming for and why.
In the MU* text-based gaming world there are a slew of common forms that an emote command may take. In the rest of this article I’ll try to list and discuss some common alternatives. Although I use “emote” as a command name here (I could also call it “pose”), the command is so ubiquitous that it’s often aliased to a single character like a colon or semicolon.
The pre-set emote produces a given (possibly randomized) output. This basic form of emote is often available even in the most hardcore hack & slash game. It is also the only emote commonly seen in graphical games.
Technically, this is by far the simplest type of emote to implement. It could look like this (example Python code for the Evennia MUD creation system):
import ev class CmdBow(ev.Command): key = "bow" def func(self): text = "%s bows." % self.caller.key self.caller.location.msg_contents(text)
Extended pre-set emote
> bows with a flourish.
Griatch bows with a flourish.
> say This is a good day.
Griatch says, “This is a good day.”
The say command is by far the most common form of extended emote, so traditional that it’s rarely identified as an emote at all. In some games the separation makes sense due to it being faster to type. In other games this traditional separation is unfortunate: there is no reason why saying something should be conceptually different from emoting (see the Language-parsing section of freeform emotes, below).
Offering the ability to expand on a pre-set emote is technically simple. It is also fast to type (skipping the extra info would just give the vanilla pre-set emote).
An example in Evennia code:
import ev class CmdBow(ev.Command): key = "bow" def func(self): if self.args: text = "%s bows %s" % (self.caller.key, self.args) else: text = "%s bows." % self.caller.key self.caller.location.msg_contents(text)
Commands with emote extension
> hit tom : with a swift downward blow!
Griatch attacks Tom with a swift downward blow!
This is the ability to tack an emote to a non-emote related command. There is little technical reason not to offer this in most games since the emote could be skipped completely for speed or used to add immersion and personality when needed. Implementation is mainly a matter of establishing a standard parsing of commands and figuring out just how to tag on the emote (in the above example, the emote is simply created by appending a colon to the end of a normal command). Of course, it helps if the game design takes this into consideration from the get-go.
Freeform emote, locked emoter
> emote stands by the bar, looking around.
Griatch stands by the bar, looking around.
This is a very common emote type, where the first word is always the name of the emoter. Many parsers also handle things like possessive form (emote’s → Griatch’s). Auto-including the emoter like this has practical reasons — it allows everyone to know who is emoting even if the emote doesn’t reference the emoter explicitly. It is also easy to implement:
import ev class CmdEmote(self): key = "emote" func(self): text = "%s %s" % (self.caller.key, self.args) self.caller.location.msg(text)
Freeform emote with dynamic parsing
> emote Standing by the bar, /self looks around.
Standing by the bar, Griatch looks around.
This is an emote that also incorporates a mini-language, here exemplified by the use of the /self keyword. Exactly which syntax is used varies, including, among others, single-characters like “@”, double-commas, /me, and #self.
If the player does not include a self-reference, the name can be auto-appended to the start or end of the emote. Alternatively, the emote can be logged to make sure the author of a given emote can always be identified should the need arise.
In the following we’ll try to look into some of the things one can do with dynamic emote parsing. This is general enough so that we won’t give code examples; how to implement these necessarily depends on the system.
> /self stands by the bar.
You see: Griatch stands by the bar.
Others see: A tall man stands by the bar.
A recognition system is a common system to embed into roleplaying MUDs, regardless of actor or director stance (although it technically belongs on the actor-stance side). A recognition system permeates the entire game, not only the emoting. The basic premise is that each character is only recognized by their description (or a shortened version of it) until they have been “recognized”. Recognition could be automatic (setting the real character name when you first talk to them) or arbitrary (assign whatever name you like to them). Some games also include features like cloaks and masks to temporarily make identification harder or impossible.
> emote Griatch says “[elvish]This is a good day.”
Elvish-speakers see: Griatch says “[elvish]This is a good day.”
Others see: Griatch says “Ni’ea fe dolae.”
This essentially deprecates the say command, making speaking a coded part of the emote while including (maybe optional) language parsing of everything within the quotes. Different levels of elvish skill level can be checked to determine if all words are understood or if some are scrambled.
Parsing for grammatical cues is mainly relevant for systems where different people see different things (actor stance). They allow the player to help the parser produce grammatically correct text regardless of who sees it. For English output it generally requires the involved character’s gender to be accessible by the parser.
> emote ~Griatch smiles, but ^Griatch hand is shaking.
You see: You smile, but your hand is shaking.
Others see: Griatch smiles but his hand is shaking.
> emote Shouting, /self #attacks /tom, aiming for his /head.
Shouting, Griatch attacks Tom, aiming for his head.
With clever parsing, entire command structures could be embedded into the natural language of the emote. In the example above, the command “ hit tom head ” has been embedded into the command through the emote mini-language.
> hemote Secretly, Griatch sneaks along the wall.
> memote In the matrix, Griatch’s avatar is glowing.
These are subtypes of emotes that affect how the emote is perceived codedly. A “hidden emote” could be used when the character using it is currently sneaking — some sort of detection skill check might determine which player wouldactually see it. Other variations might be emotes for actions that cause no sound or which are only visible to those of a particular magical aptitude or who are jacked into the matrix. See the section about Actor and Director stances, above, for a discussion on the rationale of hiding information from players in this way.
Games built around storytelling may allow you to “throw” your emote in order to make it seem to appear to come from an otherwise mute non-AI NPC, or to show an environmental event happening. This is often handled by a separate set of commands, such as “emit” or “spoof”. The emote can be parsed as any other emote or be completely freeform. The problem of attribution (which player is responsible for a given emote) is still there though, so having the game log who issues such commands is probably a good idea.
Freeform emote with quality evaluation
The very act of emoting can also be made a part of the game play. Some RP-heavy MUDs do this by letting some (or all) XP be gained on the basis of emoting. Depending on just how that XP can be spent, this could have the advantage of making sure any character archetype is viable. It can also potentially remove the concept of grinding certain skills (although some games combine skill-usage XP with emote-based XP).
Technically the evaluation is done by somehow assigning some sort of numerical “quality” to each emote. This quality could be found from a simple emote-length threshold or be determined via a series of measures such as minimal or optimal length, spell-checking, the avoidance of repeats, the number of people emoting back to you and so on. The exact algorithm is debatable. One could argue that judging quality based on spelling may be seen as excluding players with various writing disabilities.
Once the emote quality is determined, this could then translate directly into an XP gain per emote. Alternatively one could instead let the XP-gain be time-dependent and award a fixed amount as long as the player makes enough “quality” emotes in that time frame. One could also picture a system where, when attaching an emote to a command, the “quality” of the emote could help give a bonus to said command.
Needless to say, emote quality evaluation systems are mainly of interest to very roleplay-focused games. The drawback can potentially be emote-spamming if the system can be doctored or is not properly monitored.
At the far end of the scale we finally have the fully freeform emote without any bells and whistles. This is by far the simplest to implement and is something for pure storytelling games or “talker”- style servers. Even so, some sort of marker (or log) of who is responsible for each emote is probably useful to help keep order.
Whereas the choice of emote system may be a no-brainer for some designers, emoting is arguably the core mechanic for supporting any form of more advanced roleplay. When deciding what we want for our own games we tend to instinctively go with what we are most familiar with (i.e. what our favourite or first MUD uses). I hope this article will help give you some more ideas and allow you to at least make the choice consciously.