My basic verbs for virtual worlds were a suitable set five years ago, when thinking of gameplay and what it can all be boiled down to. Now, however, I've seen one or two of today's MMOs, and as intimated in my last post, they can't just be summed up with the plain ideas of getting around in a virtual world -- they have needs that transcend the world of the character, to the world of the player. Chat is one of those things; it's all find and good to roleplay your characters talking in-world, even if out-of-context, but that still requires proximity to be heard, or some in-game mechanism to reach further, such as Ultima Online's communication crystals. These other features don't necessitate a new server, as the last post discussed, but just some in-game features -- reduced down to verbs, perhaps, -- that allow them to exist in any game developed in MMORF.
messaging
The chat server discussed before is useful for live communication with players in-world, or indeed, if external access is made available (which I think is necessary), then completely external live communication is supported, making it no different than your ICQ/MSN/AIM environments. But what about leaving messages, the in-game equivalent of email? Ultima Online had the idea of bulletin boards that you could leave on your in-game house, Dungeons and Dragons and World of Warcraft have a mailbox with which you can receive messages from friends, strangers, and perhaps just as importantly, from the game world, either in-context or not.
All three examples use an in-game object or person to get these messages, requiring characters to be in certain areas to receive them. This might not be required, however; a game world might break immersion by allowing access to these communications through some pop-up menu, being more communication for the player and not the character. This means not restricting the functionality just to objects and scripted behaviour, but as something that objects interaction OR the client itself can communicate. Indeed, in DDO, there's an icon that appears on the player's HUD that signals mail presence, thus combining the in-world mailbox for the character with the information provided to the player -- the fact that the character "knows" to go check the post office is only a slight break from immersion.
transfers
Transfers are different from a GIVE verb which is a live interaction between two characters. Instead, transfers are a way to transfer between two characters that aren't in proximity. DDO and WoW support mailing objects to others through the post office -- I don't know about WoW, but DDO has a fee system that provides a gold sink, based on the value of the object. Transfers are often used for two "non-standard" purposes -- transferring between a player's characters on the same account, and storing extra items beyond available in-game storage (character inventory, bank slots, housing). Not that these mechanics matter; what matters is that there's a method to transfer in-game objects, securely, to another character in the game, whether through an in-game system or right in the client. The allowed uses for such a system is up to the game designer.
auctions
MMOs are, to a lot of people, all about acquiring virtual goods. Sometimes this is out of necessity, to advance through the game with the best gear, and sometimes it's just for having the best, for having a whole set, or just for having. To facilitate the trading that goes on between characters/players that don't know each other, having a method to post an item for a specified price (or a minimum bid price) in a centralized location. UO did this by allowing players to purchase vendors, which were placed in player housing and handled the storefront of items priced at a set price; DDO and WoW allowed characters to put items into an auction house and hope that someone else wanted them. Again, each of these games uses an in-game concept for handling this offline transfer between characters, though this doesn't have to necessarily be the case - having a web interface into the auction house could be very useful for the player (and who knows, perhaps WoW offers this). Typically this mechanism also provides a goldsink for the game -- the vendors charge a rent, and the auction house takes a cut on the sale and/or a posting fee. This need means that the auction/vendor system needs to go through the game server to allow for the developer to provide the rules for transfer - to add on the fees, to restrict transfer of too-high items or bound items, etc.
In essence, each of these features could be added in-game using scripting and basic verbs such as USE on mailbox objects, or GET/PUT/SAY to a vendor as Ultima Online indeed does. But the idea of these features existing outside of the world, escaping the virtual to include actions that players might take, means to me that they are their own, albeit more complex, verbs of gameplay in today's virtual worlds. And there are more...
Showing posts with label verbs. Show all posts
Showing posts with label verbs. Show all posts
Monday, January 18, 2010
Wednesday, March 23, 2005
What's in a world, continued
Continuing on yesterday's discussion...
get/put
Finally the virtual world can go from the just a verbally-interactive world to a "physically" interactive one. Objects are now involved.
But why put group them together, when my list had them separate? I kept hemming and hawing about this, because
In a textual world, "get" implies into a backpack, or some form of inventory. If you can see the object in a text world, then you can probably reach it (by the rules of the world). Since most text worlds are based on rooms, it is assumed that you can move around the room freely to perform other actions, such as getting to the object in question. Movement, in the case, doesn't "count". "Put" in a simple text world would possibly be implemented as a "drop" command, and the floor of each room is a big list of items, in no particular order (or, maybe the order they were dropped there). More complex worlds might support putting onto something, or putting into something. You could even support putting in different locations (though in a textual world, this might be thought of as "throw" into an adjacent room.)
Graphical worlds, on the other hand, would usually support into, onto and the rest. The idea of range of reach is most likely introduced, since graphical worlds tend to provide a lot more information from "look" than their textual counterparts. Ultima Online, for instance, allows you to "get" an item up to two squares away, and only allows you to "put" an item the same distance. Here, though, they really are the same thing -- drag the item from ground/corpse/container into backpack, or the other way around.
Graphical worlds can also allow you to move things around on the ground, from one spot to another; this is just an abbreviated form of get and put in succession. Indeed, in Ultima Online, having an item "in your hand" (that is, being dragged by the cursor), counts against the character as weight, but does not exist in any place that any other character can see (for instance, a rogue snooping in that character's backpack cannot see it there). You can even walk around with this item "gotten" in this sense, in your hand (though you are then prevented from using your cursor to interact with the rest of the world, which makes sense).
This brings up another point, which you might have already questioned: what about inventory? In MUDs, you usually have an "inventory", "inv" or "i" command to get a list. In graphical worlds, it's either a window that can be popped up or a container you use (next section). While "get" might be thought of as a simple verb "get item", worlds can support more complex uses ("get item into backpack"). But yes, this just becomes "move item into backpack", because at what point are you still getting, and what point are you putting?
And what of equipping? This is just a special form of putting, with the destination being a "slot" on the character. It might be referred to as "wear" and "remove" instead of "put" and "get", and yes, again these could be generalized as "moveobject".
Even trading between characters can be seen as an act of putting an object "to" them; this might require some interaction on their part - whether or not they want to accept the item offered, or a way to have them trade something in return, where both items are traded at the same time, fairly. In this case, the "put" might actually put the item into a "trade window", which is also displayed to the other player, who can them "put" their own items in. This trade window (really a container that exists briefly during this interchange), may not allow any "get" actions at all, so players can't grab an item from it; perhaps the transaction has to be completed through another method, at which point the trade window does its own "put" into each player's inventory. This is how it's done in Ultima Online; I never had the opportunity to trade items in World of Warcraft, to see how they do it.
We won't, however, go so far as to say that swinging a sword is "put sword in monster" or firing an arrow is "put arrow in Joe".
use
Up to now, talking, moving and moving objects has allowed some interaction in our virtual world. We make changes to it from communication (we change what we know), from motion (as we move around), and object interaction (changing the location, and thus the state of the world's objects). Once we allow objects to have a useable property, however, we allow a lot more interaction because we now have a way to change the state of objects, which is a more subtle change compared to moving their physical location, but fleshes out the reality in our world. Having a lantern in a virtual world is nice, and being able to move it around is great and all, but if we can use the lantern to turn it on and off, then it becomes more than a word or a bitmap on the screen -- it becomes a useful object.
Some items might just have a single use, such as the lantern. "Use lantern", depending on it's current state, will either turn it off or on; "use apple" might eat it (and we might have a synonym of "eat" for certain objects).
Using an item might often require specifying a target. "Use sword" might prompt "on what?", whereas that could be avoided with "use sword on tree". Using an item might be more complex: "use hammer" might provide a list of things you can use the hammer for, and you would then need to choose. Indeed, one of the choices might be "repair", in which case you would then have to supply yet more information for the "use" to finally happen.
This is where the graphical worlds have a lot more power than their textual counterparts. We can use the hammer (which is there on the screen in my inventory, or in my hand, by double-clicking it, or clicking it for a context menu, or some other similar action. A window can appear to offer the choices of actions to perform with the hammer. If that choice (repair) requires more information, I can be told to click on the item to be repaired.
Doing this in a text world is possible, of course, but not nearly as fluidly as in with a mouse in a graphical world. If I type "use hammer", a dozen or so lines might appear offering my choice of hammer actions. I might select "6" (repair), at which point it might provide another list of items to attempt to repair (and, if we're lucky, the game engine was nice enough to prune the list down to just the items that are repairable (or even those that need repair), instead of every item within view.
Alternately, the text world, if equipped with a suitable parser, might support "use hammer to repair chair", or provide a "repair" synonym (which might look around for a suitable object that supports the "repair" action.)
Some actions might be very simple; "use door" (or an alias, "open door"), just changes the state of the door object, and affects other actions (such as moving through the doorway). Others might be more complex than just changing an object's state; using a crystal ball might call up a mysterious random image; using a teleporter pad will change the location property of the character itself; using a healing potion changes a different property of the character, their health; and using a lightning wand might cause visual effects for others, might reduce the number of uses in the wand, might drain some mana from the user, and might cause damage to one or more objects (including other characters and NPCs).
Other actions in virtual worlds can be mapped to the "use" command. In worlds with magic, characters might have an innate ability to cast spells; while there may not be an actual object in their inventory (it might be on a spell list window, or gump), they still want to "use" a fireball (at something). In this case, the object could be abstracted (in that it kind of exists in the game, but can't be picked up or put down); a synonym "cast fireball" might know to "use special pseudoobject 5". In Ultima Online, players have a spellbook, which is a special container with the spells within; here the object really does exist, and can be used much like any other (though the spell cannot be removed from this special container).
Games with skills and feats, or other inherent abilities, can also treat these as pseudo-objects that are used. A character with an affinity for taming animals may not have an "animal taming bauble" in their backpack, but if this non-physical object is accessible through a menu, an icon or a macro, then it can still be treated as an object to "use taming on horse". The character has no way to try and "put taming on floor", because the "put" command just don't know where that "taming" object is.
Some might say that this is a stretch, that these inherent abilities should be treated differently. I admit that treating them as any other object can stretch the imagination from a design point of view, but it makes engine design a lot easier. If these pseudo-objects (like animal taming) can have scripts attached to them just as "real" objects (such as a lantern), then game designers can have just a much logic and flexibility behind one as the other. The lantern script might simply flick the lantern on and off, no questions asked, or it might check lantern for a number of uses, before it fails to ever light again.
Or even go so far as to require fuel, and checks an internal property for the amount of fuel left. Likewise, our animal taming skill, as a pseudo-object that characters always "have", can determine whether you're of the right class to use the skill at all (if such restrictions exist in the world), whether the target is sensible ("you cannot tame the chef!") or if the skill level is too low ("you have no chance of taming that dragon"). Just because these pseudo-objects can't be picked up or put down, doesn't mean that they can't exist. Just because they're not in the character's backpack doesn't mean that they can't be in some other "container" that the character always carries -- their skills list, their paperdoll, or whatever.
As a matter of fact, Ultima Online recently added an item called a soulstone, which lets a player transfer a skill from one character to another. The one character takes their 56 points in Animal Taming and "puts" it "into" the soulstone; another character (on the same account) can then go to the soulstone and "gets" the skill into their own skill list. While it's not necessary that Ultima Online treats their skills as pseudo-objects in the game, it can be seen that if they were, these soulstones would be a very simple thing to implement.
It's true, I've lumped a lot of actions (the majority of what might make up a game world) under the "use" command. But that's the way I see virtual worlds; besides the obvious talking, walking and moving things around, the rest of the experience is through using the contents of the world. It could even, maybe, be argued that combat could just be "use sword at monster", but we'll not take that last step...
attack
Combat in virtual worlds really does require its own command, in my opinion. You can try to think of it as putting" someone to the sword, or "using" a blade on someone, but combat is usually more involved in virtual worlds than just repeated using of an item upon someone.
Many combat systems put you in a "combat mode". Often, these modes can "take over", in that your swings and parries are then done automatically, a dance of mathematical functions and randomness displayed on the screen. Interaction from the user might take on an assistant role, such as healing, activating special attacks, or backing off - these are just cases of "use" and "move" while in combat mode. Other games might require the user to make each swing, and in this case combat could be represented as multiple "use sword on target" commands.
Combat mechanisms can, for a lot of people, define the world. That is, for virtual worlds in which combat plays a large part (and I'd say this is the majority of them), the combat style is where a lot of thought and design is put in.
This means that very little of it should be in the engine -- that it should be all customizable using the scripting language. But what does the engine have to supply? What, beyond the previous commands discussed (and the inclusion of a scripting language), is needed?
Perhaps nothing. Perhaps when I type "attack Joe" or "use sword on Joe", the attack or use command launches a "combat script", which first determines if that's possible (are you close enough? Do the rules allow it? Does Joe have to accept this as a duel?), and then if the attack is allowed, informs Joe (maybe just pops up a message, maybe plays battle music on his client, maybe launches another script (if Joe is an NPC)).
So should "attack target" just be an alias for "useon target"? Maybe, but the item in hand might also have other "uses", and is it right to put have to attach a combat script to every item with which someone might club another? Instead, we could attach the combat script to the character (or NPC) itself, and have the attack command launch that. It seems ... messy to include combat-handling code for a skinning knife in the same script where we ask which fish you wish to fillet with it.
And really, that's what it all comes down to. For every command, the outcome is going to be decided by the game designer, and thus the scripts that are written for the game, and not really for the engine itself. The engine should be able to support passing these commands back and forth, but it is not up to the game engine to decide whether or not you can move north: the move script should check that the terrain is blocked or not, and decide for itself. The rules (embodied in the scripts) decide if you're allowed to pick up that item (because it's close enough, because it's not secured down, because it's not too heavy), and the engine just calls the item's "you'reBeingGotten()" function (or, more likely, calls the character's get() function, which would at some point call the isItOkayYou'reBeingGottenByMe() function).
So as a designer for a virtual world framework, I need to support the communication of these basic commands, and the ability to tie their appearances to attached scripts. That's it. But am I coding myself into a corner if I hard-code the set of commands that are allowed? Sure, I might think I've encompassed to whole of virtual world goings-on, but what if I've missed one? What if something new comes to the realm of the virtual experience?
get/put
Finally the virtual world can go from the just a verbally-interactive world to a "physically" interactive one. Objects are now involved.
But why put group them together, when my list had them separate? I kept hemming and hawing about this, because
- they are almost always two distinct commands, but
- they are just aliases for a "moveobject" command, yet
- "get" implies to the character, where "put" can be to many places, though
- a moveobject could handle both of these cases, however
- "get" usually requires a lot more "permission" checks, where "put" does not, and
In a textual world, "get" implies into a backpack, or some form of inventory. If you can see the object in a text world, then you can probably reach it (by the rules of the world). Since most text worlds are based on rooms, it is assumed that you can move around the room freely to perform other actions, such as getting to the object in question. Movement, in the case, doesn't "count". "Put" in a simple text world would possibly be implemented as a "drop" command, and the floor of each room is a big list of items, in no particular order (or, maybe the order they were dropped there). More complex worlds might support putting onto something, or putting into something. You could even support putting in different locations (though in a textual world, this might be thought of as "throw" into an adjacent room.)
Graphical worlds, on the other hand, would usually support into, onto and the rest. The idea of range of reach is most likely introduced, since graphical worlds tend to provide a lot more information from "look" than their textual counterparts. Ultima Online, for instance, allows you to "get" an item up to two squares away, and only allows you to "put" an item the same distance. Here, though, they really are the same thing -- drag the item from ground/corpse/container into backpack, or the other way around.
Graphical worlds can also allow you to move things around on the ground, from one spot to another; this is just an abbreviated form of get and put in succession. Indeed, in Ultima Online, having an item "in your hand" (that is, being dragged by the cursor), counts against the character as weight, but does not exist in any place that any other character can see (for instance, a rogue snooping in that character's backpack cannot see it there). You can even walk around with this item "gotten" in this sense, in your hand (though you are then prevented from using your cursor to interact with the rest of the world, which makes sense).
This brings up another point, which you might have already questioned: what about inventory? In MUDs, you usually have an "inventory", "inv" or "i" command to get a list. In graphical worlds, it's either a window that can be popped up or a container you use (next section). While "get" might be thought of as a simple verb "get item", worlds can support more complex uses ("get item into backpack"). But yes, this just becomes "move item into backpack", because at what point are you still getting, and what point are you putting?
And what of equipping? This is just a special form of putting, with the destination being a "slot" on the character. It might be referred to as "wear" and "remove" instead of "put" and "get", and yes, again these could be generalized as "moveobject".
Even trading between characters can be seen as an act of putting an object "to" them; this might require some interaction on their part - whether or not they want to accept the item offered, or a way to have them trade something in return, where both items are traded at the same time, fairly. In this case, the "put" might actually put the item into a "trade window", which is also displayed to the other player, who can them "put" their own items in. This trade window (really a container that exists briefly during this interchange), may not allow any "get" actions at all, so players can't grab an item from it; perhaps the transaction has to be completed through another method, at which point the trade window does its own "put" into each player's inventory. This is how it's done in Ultima Online; I never had the opportunity to trade items in World of Warcraft, to see how they do it.
We won't, however, go so far as to say that swinging a sword is "put sword in monster" or firing an arrow is "put arrow in Joe".
use
Up to now, talking, moving and moving objects has allowed some interaction in our virtual world. We make changes to it from communication (we change what we know), from motion (as we move around), and object interaction (changing the location, and thus the state of the world's objects). Once we allow objects to have a useable property, however, we allow a lot more interaction because we now have a way to change the state of objects, which is a more subtle change compared to moving their physical location, but fleshes out the reality in our world. Having a lantern in a virtual world is nice, and being able to move it around is great and all, but if we can use the lantern to turn it on and off, then it becomes more than a word or a bitmap on the screen -- it becomes a useful object.
Some items might just have a single use, such as the lantern. "Use lantern", depending on it's current state, will either turn it off or on; "use apple" might eat it (and we might have a synonym of "eat" for certain objects).
Using an item might often require specifying a target. "Use sword" might prompt "on what?", whereas that could be avoided with "use sword on tree". Using an item might be more complex: "use hammer" might provide a list of things you can use the hammer for, and you would then need to choose. Indeed, one of the choices might be "repair", in which case you would then have to supply yet more information for the "use" to finally happen.
This is where the graphical worlds have a lot more power than their textual counterparts. We can use the hammer (which is there on the screen in my inventory, or in my hand, by double-clicking it, or clicking it for a context menu, or some other similar action. A window can appear to offer the choices of actions to perform with the hammer. If that choice (repair) requires more information, I can be told to click on the item to be repaired.
Doing this in a text world is possible, of course, but not nearly as fluidly as in with a mouse in a graphical world. If I type "use hammer", a dozen or so lines might appear offering my choice of hammer actions. I might select "6" (repair), at which point it might provide another list of items to attempt to repair (and, if we're lucky, the game engine was nice enough to prune the list down to just the items that are repairable (or even those that need repair), instead of every item within view.
Alternately, the text world, if equipped with a suitable parser, might support "use hammer to repair chair", or provide a "repair" synonym (which might look around for a suitable object that supports the "repair" action.)
Some actions might be very simple; "use door" (or an alias, "open door"), just changes the state of the door object, and affects other actions (such as moving through the doorway). Others might be more complex than just changing an object's state; using a crystal ball might call up a mysterious random image; using a teleporter pad will change the location property of the character itself; using a healing potion changes a different property of the character, their health; and using a lightning wand might cause visual effects for others, might reduce the number of uses in the wand, might drain some mana from the user, and might cause damage to one or more objects (including other characters and NPCs).
Other actions in virtual worlds can be mapped to the "use" command. In worlds with magic, characters might have an innate ability to cast spells; while there may not be an actual object in their inventory (it might be on a spell list window, or gump), they still want to "use" a fireball (at something). In this case, the object could be abstracted (in that it kind of exists in the game, but can't be picked up or put down); a synonym "cast fireball" might know to "use special pseudoobject 5". In Ultima Online, players have a spellbook, which is a special container with the spells within; here the object really does exist, and can be used much like any other (though the spell cannot be removed from this special container).
Games with skills and feats, or other inherent abilities, can also treat these as pseudo-objects that are used. A character with an affinity for taming animals may not have an "animal taming bauble" in their backpack, but if this non-physical object is accessible through a menu, an icon or a macro, then it can still be treated as an object to "use taming on horse". The character has no way to try and "put taming on floor", because the "put" command just don't know where that "taming" object is.
Some might say that this is a stretch, that these inherent abilities should be treated differently. I admit that treating them as any other object can stretch the imagination from a design point of view, but it makes engine design a lot easier. If these pseudo-objects (like animal taming) can have scripts attached to them just as "real" objects (such as a lantern), then game designers can have just a much logic and flexibility behind one as the other. The lantern script might simply flick the lantern on and off, no questions asked, or it might check lantern for a number of uses, before it fails to ever light again.
Or even go so far as to require fuel, and checks an internal property for the amount of fuel left. Likewise, our animal taming skill, as a pseudo-object that characters always "have", can determine whether you're of the right class to use the skill at all (if such restrictions exist in the world), whether the target is sensible ("you cannot tame the chef!") or if the skill level is too low ("you have no chance of taming that dragon"). Just because these pseudo-objects can't be picked up or put down, doesn't mean that they can't exist. Just because they're not in the character's backpack doesn't mean that they can't be in some other "container" that the character always carries -- their skills list, their paperdoll, or whatever.
As a matter of fact, Ultima Online recently added an item called a soulstone, which lets a player transfer a skill from one character to another. The one character takes their 56 points in Animal Taming and "puts" it "into" the soulstone; another character (on the same account) can then go to the soulstone and "gets" the skill into their own skill list. While it's not necessary that Ultima Online treats their skills as pseudo-objects in the game, it can be seen that if they were, these soulstones would be a very simple thing to implement.
It's true, I've lumped a lot of actions (the majority of what might make up a game world) under the "use" command. But that's the way I see virtual worlds; besides the obvious talking, walking and moving things around, the rest of the experience is through using the contents of the world. It could even, maybe, be argued that combat could just be "use sword at monster", but we'll not take that last step...
attack
Combat in virtual worlds really does require its own command, in my opinion. You can try to think of it as putting" someone to the sword, or "using" a blade on someone, but combat is usually more involved in virtual worlds than just repeated using of an item upon someone.
Many combat systems put you in a "combat mode". Often, these modes can "take over", in that your swings and parries are then done automatically, a dance of mathematical functions and randomness displayed on the screen. Interaction from the user might take on an assistant role, such as healing, activating special attacks, or backing off - these are just cases of "use" and "move" while in combat mode. Other games might require the user to make each swing, and in this case combat could be represented as multiple "use sword on target" commands.
Combat mechanisms can, for a lot of people, define the world. That is, for virtual worlds in which combat plays a large part (and I'd say this is the majority of them), the combat style is where a lot of thought and design is put in.
This means that very little of it should be in the engine -- that it should be all customizable using the scripting language. But what does the engine have to supply? What, beyond the previous commands discussed (and the inclusion of a scripting language), is needed?
Perhaps nothing. Perhaps when I type "attack Joe" or "use sword on Joe", the attack or use command launches a "combat script", which first determines if that's possible (are you close enough? Do the rules allow it? Does Joe have to accept this as a duel?), and then if the attack is allowed, informs Joe (maybe just pops up a message, maybe plays battle music on his client, maybe launches another script (if Joe is an NPC)).
So should "attack target" just be an alias for "use
And really, that's what it all comes down to. For every command, the outcome is going to be decided by the game designer, and thus the scripts that are written for the game, and not really for the engine itself. The engine should be able to support passing these commands back and forth, but it is not up to the game engine to decide whether or not you can move north: the move script should check that the terrain is blocked or not, and decide for itself. The rules (embodied in the scripts) decide if you're allowed to pick up that item (because it's close enough, because it's not secured down, because it's not too heavy), and the engine just calls the item's "you'reBeingGotten()" function (or, more likely, calls the character's get() function, which would at some point call the isItOkayYou'reBeingGottenByMe() function).
So as a designer for a virtual world framework, I need to support the communication of these basic commands, and the ability to tie their appearances to attached scripts. That's it. But am I coding myself into a corner if I hard-code the set of commands that are allowed? Sure, I might think I've encompassed to whole of virtual world goings-on, but what if I've missed one? What if something new comes to the realm of the virtual experience?
Tuesday, March 22, 2005
What's in a world?
This project aims to ultimately reduce all MMOs down to their bare essentials, to their common ground.
I posit that all MMOs are the same; they just differ in graphics, text, and play interface. Sacrilege, some might cry, but it's all in the presentation, I say.
So what's in a world? What can you do? Here's a list off the top of my head; I'm sure I could find a similar list in literature about virtual worlds if I just went looking.
LOOK (around, at this item, at that mobile)
SAY (or whisper, or yell, or private-message)
EMOTE (bow, yawn, laugh, cry...)
MOVE ("go north", "go to room 5", "run this way")
GET (this or that item)
PUT (this item)
USE (this item)
ATTACK (that target)
These are in order of "difficulty" or "complexity", in that simple worlds might just implement the first few, but more complex worlds would have the later commands. Let's look at each in detail.
look
This command would get information about your location, about objects nearby, or about other characters or NPCs in the area. You could implement a virtual world that has nothing but this command, though it would be very limiting indeed.
In a text world (MUD), you might use "look", "look [at] Joe" or "look [at] sword". As you enter a room, you might automatically be given the results of a "look" command, or perhaps that only happens the first time you enter a given room. Some systems will give you the full description the first time, and an abbreviated version the next; typing the "look" command at any time after that might re-iterate the full description. Looking at an object or mobile will return information about it, though perhaps not all - I might be able to see how many uses are left on my magic wand, but other people can only see that it's a magic wand. I might see Joe, that he's a human barbarian, and that he's got a shield, but his guildmates might also get to see his guild title, and the amount of stamina he has left. Looking can have very different results based on the looker.
In a graphical world, there is no explicit "look" command - the graphics are there to constantly show you what you see. Some games (World of Warcraft) might not only show you the terrain, and the objects, and the mobiles nearby, but the names of them above their heads. Ultima Online, on the other hand, shows you the names as they enter your view, but they vanish after a few moments -- an "all names" macro can be set up so you can "look" once more at these specifics.
Looking at an object in a graphical world might involve passing the cursor overtop it, prompting a "tooltip" to appear with the object's information, it might require clicking once on an object; or it might require bringing up a context menu for the object, and viewing the properties that way. In the case of mobiles, one might be able to bring up a separate window that continually updates with the "look" information about it, so you could watch the health of a monster as you fought it, or the health of an ally as he was being attacked. This information might also be constantly present (as I believe it is in WoW) as a statbar above or below the mobile.
As for implementation, the server might send a certain set of information to the client in anticipation of the user asking to look at this or that object. Alternately, the server may send nothing up until the client (by way of the user) explicitly asks for it; this could also allow every object to have a "look" script attached to it, so a character that looks at the crystal ball is teleported inside, or anyone that looks in the mirror is paralyzed by their true reflection.
Interestingly, you *can* implement a world without this command; I would say that a chatroom would almost be such a world, except most chatrooms have a "user list", and that itself is a "look" in the room.
say
Communication is probably the most important part of a virtual world; it's what makes it a community.
A world could, I suppose, function without any way of characters to communicate directly to each other -- they could run around, attack each other, pick things up, and perhaps try to spell messages on the ground with items, but it wouldn't be very immersive if basic communication is missing. And, in my opinion, that communication should be immersive. In Ultima Online, a player types in the game window, and their words appear above their heads; the conversation appears where the player is looking, and associating the text with the character is simple. In World of Warcraft, however, there was a text window on the bottom of the game window in which all communication took place.
To know if someone in front of you was talking to you, you would have to look in the main screen to see the name of the character that walked up, and then watch the chat window to see if any messages came in with that name. I did not like this method of communication at all.
Granted, the WoW method is useable across vast game distances, where the UO method is not. In UO, you must be on the same screen to communicate with people. There is another method in-game in UO that allows a similar chat window to the one in WoW, and it has the limitation of having to "enter" a room to chat with people you probably know. WoW has the idea of rooms, too; your guild, public channels, and probably "area" rooms too.
Talking can also include "tells" or "whispers", where communication is directly to one individual, perhaps in the same vicinity, perhaps not. In virtual worlds where everyone has a unique name, you can attempt to "/tell Joe" and be guaranteed to get the Joe you know, not a stranger. In games that do not prevent name collisions (Ultima Online), this mechanism isn't available, though there is a way to whisper to a person nearby, by being within a couple of spaces of them and starting your conversation with a "; ".
Because speaking in world is a textual affair, the keyboard is involved whether the client is a text-only one or a graphical one. Whether communication happens directly (just start typing) or requires a prefix ("/tell", "say ") or requires typing into a separate window, is up to the designer of the client, not necessarily the game.
But is communication solely text? With Teamspeak and Ventrillo, two popular voice-chatting programs over the internet, more and more players are able to communicate with each other without using in-game mechanisms, and certainly more quickly than having to type. This can lead to an eerie feeling from observers, as they watch a whole guild of characters swarm into an area, fight for a bit, then leave, all without a single word to each other. They just seem to move as a hive mind. While being able to speak directly to the "character" right beside you is great for immersion for the players involved, it can prevent immersion for those nearby.
So perhaps, in these days of high-speed connectivity, a game could support this natively (as many games are starting to do), and audio can be passed back and forth from client to server and to other "nearby" clients. This would just be a version of the "say" command that has a binary stream of digitized voice instead of a string of characters. Players could hold down a key on the keyboard, or the mouse, if they wish to speak to their guild (a party chat) versus "out loud" in the game.
Of course, profanity, slurs and the like are less likely to be screened in this scenario, but that's not the concern of the designer of the game framework -- that's up to the administrators. *:^)
emote
This should, perhaps, be a sub-command of say, though with graphical worlds, the outcome can be quite different than the spoken word.
Emotes are ways to portray emotions or actions. Early chatrooms used "<laugh>" or "*grins*" or "*:^)" to demonstrate that the user is laughing, grinning or smiling. Acronyms appeared (LOL, ROFL, etc.) to denote more complex feelings and actions. Internet Relay Chat (IRC) supports a "/me" command, where "/me grins" will say "* Crwth grins" to others in the room. This is usually highlighted in a different color, and is preceded with special characters (an asterisk and a space) to let others in the room know the difference between an emote and a typed message.
Textual worlds might have a generic command (like /me or /emote), and might also have shortcuts for many of the popular ones (/grin, /laugh, etc.) They might allow the character to use a macro to insert their name in a different part of the action ("/emote you made $$ cry!"), making it more powerful than the IRC "/me" command which always puts the user's name first. In all cases, the other characters in range will be told in words what the other character is doing.
Graphical worlds might support something similar. In Ultima Online, text preceded with ": " will be surrounded by asterisks and possibly shown in a different color, above the character's head (": grins" will show "*grins*"). While a person could just as well type the asterisks to the same affect, the use of a different color for emotes allows those viewing the emote to tell the difference.
Additionally, graphical worlds allow for animation, so common emotes can not just be told, but seen. Ultima Online has support for a few, including bowing, so there is no need to use ": bows", when your character can actually be seen doing it. World of Warcraft has many as well, and perhaps too many; for some reason, the designers thought it would be amusing to allow some characters to make a train-like motion with their arms while their character says "chooga chooga chooga chooga! WOO WOO!" And in the beta test, at least, the players were just as amused. I suppose that beats having "*choochoo*" above your head?
Emotes are, of course, not necessary. In the early chatroom days, as mentioned, people parenthesized their actions well enough, and email still has this type of emote within. But for those who want to be immersed in their world, these are an easy enough addition to any game, and with graphical clients, they're even more so.
move
Before I sorted the list above, this was the first command I typed in. You would think that movement is the fundamental action in a virtual world. How else do you get around the virtual world??
But, from the simplest example, a chatroom, you don't. Okay, perhaps that's not quite true, as even in IRC you can "/join" a different room, and this is just like moving from one to another (or, being in two places at once -- not something you do in most MUDs!)
Text-only worlds typically have a "go" command, such as "go north". This is usually also available as the shorter "north", and most likely "n". Newer ones might support the special keycodes of the arrow keys on the keyboard, so the up-arrow can send a "go north" command automatically. As mentioned above, this usually returns the result of a "look" command explicitly, as you're now in a new location (provided there wasn't a wall). Veterans of a virtual world may not need (and may wish to remove) the explicit "look", because they have a map of the world in their head. The old game InFiNiTy CoMpLeX didn't have such a device, but the software on which it ran (MajorBBS), supported the CTRL-O character as a "flush anything you were going to send me" code, so you could send ten or twenty movement commands rapidly, and instead of waiting for ten to twenty room descriptions to appear on the screen (over a nice, slow modem), you could send this "abort" command and you would suddenly be 20 rooms away, ready to give more commands.
Early multiline bulletin board systems, such as MajorBBS, had their chatrooms as well, in which you could only be one at a time. The command was probably something like "/room" (it's been a long time) and this could be seen as an absolute movement, where "go north" is a relative movement.
I would say that relative movement is the norm, and absolute movement not. You could, of course, support "go to blacksmith", where the game then tries to figure out the best path from where you are to the blacksmith, but this is just shorthand for "go north; go north; go west; go west; go north". The point of a virtual world, at least one with a large expanse, is probably to have things in the spaces between A and B, and thus the world designer is most likely to want the character to traverse that space.
Note that there can be in-game methods of performing absolute movement, but these are not actual "absolute movement" commands. Ultima Online has moongates in which you can step to transport yourself around to one of the other moongates scattered across the land. It also allows mages to "mark" a runestone and use it at another time to "recall" back the spot on which it was marked. Instant transportation, true, but not as a simple command -- it's objects in the game that do this for them.
Graphical worlds, and their close tie to the mouse, don't require these obvious commands. Sure, early graphical games, before the mouse (early Ultima or any other Computer Role Playing Games (CRPGs)) still had the arrow keys or something similar to move them about on the colorful screen. But some modern clients now let you click on the screen to tell your character to walk there, or you hold down a mouse button and your character walks in the direction of your cursor. Other graphical games have stayed with the keyboard interface for movement, leaving the mouse available for every other action (coming up in the list).
Variations on movement my be supported in the world as well. Running might be possible, but then your character most likely has some sort of stamina attribute which will wear down as you continue to do so. Worlds might also support "crawl", "sneak", "tiptoe" or some other form of movement, either for roleplaying purposes or actual in-game effect.
The rest of the list will be continued tomorrow...
I posit that all MMOs are the same; they just differ in graphics, text, and play interface. Sacrilege, some might cry, but it's all in the presentation, I say.
So what's in a world? What can you do? Here's a list off the top of my head; I'm sure I could find a similar list in literature about virtual worlds if I just went looking.
LOOK (around, at this item, at that mobile)
SAY (or whisper, or yell, or private-message)
EMOTE (bow, yawn, laugh, cry...)
MOVE ("go north", "go to room 5", "run this way")
GET (this or that item)
PUT (this item)
USE (this item)
ATTACK (that target)
These are in order of "difficulty" or "complexity", in that simple worlds might just implement the first few, but more complex worlds would have the later commands. Let's look at each in detail.
look
This command would get information about your location, about objects nearby, or about other characters or NPCs in the area. You could implement a virtual world that has nothing but this command, though it would be very limiting indeed.
In a text world (MUD), you might use "look", "look [at] Joe" or "look [at] sword". As you enter a room, you might automatically be given the results of a "look" command, or perhaps that only happens the first time you enter a given room. Some systems will give you the full description the first time, and an abbreviated version the next; typing the "look" command at any time after that might re-iterate the full description. Looking at an object or mobile will return information about it, though perhaps not all - I might be able to see how many uses are left on my magic wand, but other people can only see that it's a magic wand. I might see Joe, that he's a human barbarian, and that he's got a shield, but his guildmates might also get to see his guild title, and the amount of stamina he has left. Looking can have very different results based on the looker.
In a graphical world, there is no explicit "look" command - the graphics are there to constantly show you what you see. Some games (World of Warcraft) might not only show you the terrain, and the objects, and the mobiles nearby, but the names of them above their heads. Ultima Online, on the other hand, shows you the names as they enter your view, but they vanish after a few moments -- an "all names" macro can be set up so you can "look" once more at these specifics.
Looking at an object in a graphical world might involve passing the cursor overtop it, prompting a "tooltip" to appear with the object's information, it might require clicking once on an object; or it might require bringing up a context menu for the object, and viewing the properties that way. In the case of mobiles, one might be able to bring up a separate window that continually updates with the "look" information about it, so you could watch the health of a monster as you fought it, or the health of an ally as he was being attacked. This information might also be constantly present (as I believe it is in WoW) as a statbar above or below the mobile.
As for implementation, the server might send a certain set of information to the client in anticipation of the user asking to look at this or that object. Alternately, the server may send nothing up until the client (by way of the user) explicitly asks for it; this could also allow every object to have a "look" script attached to it, so a character that looks at the crystal ball is teleported inside, or anyone that looks in the mirror is paralyzed by their true reflection.
Interestingly, you *can* implement a world without this command; I would say that a chatroom would almost be such a world, except most chatrooms have a "user list", and that itself is a "look" in the room.
say
Communication is probably the most important part of a virtual world; it's what makes it a community.
A world could, I suppose, function without any way of characters to communicate directly to each other -- they could run around, attack each other, pick things up, and perhaps try to spell messages on the ground with items, but it wouldn't be very immersive if basic communication is missing. And, in my opinion, that communication should be immersive. In Ultima Online, a player types in the game window, and their words appear above their heads; the conversation appears where the player is looking, and associating the text with the character is simple. In World of Warcraft, however, there was a text window on the bottom of the game window in which all communication took place.
To know if someone in front of you was talking to you, you would have to look in the main screen to see the name of the character that walked up, and then watch the chat window to see if any messages came in with that name. I did not like this method of communication at all.
Granted, the WoW method is useable across vast game distances, where the UO method is not. In UO, you must be on the same screen to communicate with people. There is another method in-game in UO that allows a similar chat window to the one in WoW, and it has the limitation of having to "enter" a room to chat with people you probably know. WoW has the idea of rooms, too; your guild, public channels, and probably "area" rooms too.
Talking can also include "tells" or "whispers", where communication is directly to one individual, perhaps in the same vicinity, perhaps not. In virtual worlds where everyone has a unique name, you can attempt to "/tell Joe" and be guaranteed to get the Joe you know, not a stranger. In games that do not prevent name collisions (Ultima Online), this mechanism isn't available, though there is a way to whisper to a person nearby, by being within a couple of spaces of them and starting your conversation with a "; ".
Because speaking in world is a textual affair, the keyboard is involved whether the client is a text-only one or a graphical one. Whether communication happens directly (just start typing) or requires a prefix ("/tell
But is communication solely text? With Teamspeak and Ventrillo, two popular voice-chatting programs over the internet, more and more players are able to communicate with each other without using in-game mechanisms, and certainly more quickly than having to type. This can lead to an eerie feeling from observers, as they watch a whole guild of characters swarm into an area, fight for a bit, then leave, all without a single word to each other. They just seem to move as a hive mind. While being able to speak directly to the "character" right beside you is great for immersion for the players involved, it can prevent immersion for those nearby.
So perhaps, in these days of high-speed connectivity, a game could support this natively (as many games are starting to do), and audio can be passed back and forth from client to server and to other "nearby" clients. This would just be a version of the "say" command that has a binary stream of digitized voice instead of a string of characters. Players could hold down a key on the keyboard, or the mouse, if they wish to speak to their guild (a party chat) versus "out loud" in the game.
Of course, profanity, slurs and the like are less likely to be screened in this scenario, but that's not the concern of the designer of the game framework -- that's up to the administrators. *:^)
emote
This should, perhaps, be a sub-command of say, though with graphical worlds, the outcome can be quite different than the spoken word.
Emotes are ways to portray emotions or actions. Early chatrooms used "<laugh>" or "*grins*" or "*:^)" to demonstrate that the user is laughing, grinning or smiling. Acronyms appeared (LOL, ROFL, etc.) to denote more complex feelings and actions. Internet Relay Chat (IRC) supports a "/me
Textual worlds might have a generic command (like /me or /emote), and might also have shortcuts for many of the popular ones (/grin, /laugh, etc.) They might allow the character to use a macro to insert their name in a different part of the action ("/emote you made $$ cry!"), making it more powerful than the IRC "/me" command which always puts the user's name first. In all cases, the other characters in range will be told in words what the other character is doing.
Graphical worlds might support something similar. In Ultima Online, text preceded with ": " will be surrounded by asterisks and possibly shown in a different color, above the character's head (": grins" will show "*grins*"). While a person could just as well type the asterisks to the same affect, the use of a different color for emotes allows those viewing the emote to tell the difference.
Additionally, graphical worlds allow for animation, so common emotes can not just be told, but seen. Ultima Online has support for a few, including bowing, so there is no need to use ": bows", when your character can actually be seen doing it. World of Warcraft has many as well, and perhaps too many; for some reason, the designers thought it would be amusing to allow some characters to make a train-like motion with their arms while their character says "chooga chooga chooga chooga! WOO WOO!" And in the beta test, at least, the players were just as amused. I suppose that beats having "*choochoo*" above your head?
Emotes are, of course, not necessary. In the early chatroom days, as mentioned, people parenthesized their actions well enough, and email still has this type of emote within. But for those who want to be immersed in their world, these are an easy enough addition to any game, and with graphical clients, they're even more so.
move
Before I sorted the list above, this was the first command I typed in. You would think that movement is the fundamental action in a virtual world. How else do you get around the virtual world??
But, from the simplest example, a chatroom, you don't. Okay, perhaps that's not quite true, as even in IRC you can "/join" a different room, and this is just like moving from one to another (or, being in two places at once -- not something you do in most MUDs!)
Text-only worlds typically have a "go" command, such as "go north". This is usually also available as the shorter "north", and most likely "n". Newer ones might support the special keycodes of the arrow keys on the keyboard, so the up-arrow can send a "go north" command automatically. As mentioned above, this usually returns the result of a "look" command explicitly, as you're now in a new location (provided there wasn't a wall). Veterans of a virtual world may not need (and may wish to remove) the explicit "look", because they have a map of the world in their head. The old game InFiNiTy CoMpLeX didn't have such a device, but the software on which it ran (MajorBBS), supported the CTRL-O character as a "flush anything you were going to send me" code, so you could send ten or twenty movement commands rapidly, and instead of waiting for ten to twenty room descriptions to appear on the screen (over a nice, slow modem), you could send this "abort" command and you would suddenly be 20 rooms away, ready to give more commands.
Early multiline bulletin board systems, such as MajorBBS, had their chatrooms as well, in which you could only be one at a time. The command was probably something like "/room" (it's been a long time) and this could be seen as an absolute movement, where "go north" is a relative movement.
I would say that relative movement is the norm, and absolute movement not. You could, of course, support "go to blacksmith", where the game then tries to figure out the best path from where you are to the blacksmith, but this is just shorthand for "go north; go north; go west; go west; go north". The point of a virtual world, at least one with a large expanse, is probably to have things in the spaces between A and B, and thus the world designer is most likely to want the character to traverse that space.
Note that there can be in-game methods of performing absolute movement, but these are not actual "absolute movement" commands. Ultima Online has moongates in which you can step to transport yourself around to one of the other moongates scattered across the land. It also allows mages to "mark" a runestone and use it at another time to "recall" back the spot on which it was marked. Instant transportation, true, but not as a simple command -- it's objects in the game that do this for them.
Graphical worlds, and their close tie to the mouse, don't require these obvious commands. Sure, early graphical games, before the mouse (early Ultima or any other Computer Role Playing Games (CRPGs)) still had the arrow keys or something similar to move them about on the colorful screen. But some modern clients now let you click on the screen to tell your character to walk there, or you hold down a mouse button and your character walks in the direction of your cursor. Other graphical games have stayed with the keyboard interface for movement, leaving the mouse available for every other action (coming up in the list).
Variations on movement my be supported in the world as well. Running might be possible, but then your character most likely has some sort of stamina attribute which will wear down as you continue to do so. Worlds might also support "crawl", "sneak", "tiptoe" or some other form of movement, either for roleplaying purposes or actual in-game effect.
The rest of the list will be continued tomorrow...
Subscribe to:
Posts (Atom)
Posts
