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?
Posts
No comments:
Post a Comment