|
Combat, Part 5: Combat Systems as User Interfaceby Travis S. Casey No, I'm not talking about using Doom for system administration... though that can be fun. Rather, I'm talking about the problem of making a complex combat system be easy for users to work with. Paper RPGs often have very complicated combat systems — but they have certain advantages in this area over computer RPGs, especially online ones: First, the player's "interface" to a paper RPG is usually another human — the gamemaster. Because of this, a player can simply describe what he/she wants a character to do. Indeed, a GM can (and often will) "fill in" things that a player leaves out. For example, take a situation where a sword is on the ground in the game, and the player tells the GM he wants to attack the orc he's fighting with the sword. Trying this with many text-based games will get you something like: > attack orc with sword You don't have a sword. The orc slices you with his battleaxe. > Most human GMs, however, will understand that the intent is to first pick up the sword... and will further understand that while the player may not be specifically saying it, the character is almost certainly going to try to dodge any attacks that get made while he/she is trying to get the sword. Second, paper RPGs rarely have any sort of time pressure on the players. Players tend to have plenty of time to think about what their character is going to do next, and can generally take as long as they need to describe it. Some single-player computer games provide the same luxury, but most multi-player ones do not. Combat generally isn't quite real-time, but it continues to progress whether the player is giving input or not. In particular, the issue of restricted time comes up with reactive actions. In many paper RPGs, there are actions which can only be done as a reaction to another character's action — e.g., a character might be able to try to catch a knife thrown at him/her... but the player can't choose that as an action unless and until a knife gets thrown at his/her character. These sorts of reactive actions require either that there be time between the declaration of an action ("the orc throws a knife at Morgan") and the effect (the knife missing or hitting), or that the system can "back up" ("The orc throws a knife at Morgan... <roll>... but it misses, flashing past her as she ducks..." "Hey, wait a second there... I want Morgan to try to catch it, instead of just dodging it!"). Most computer RPG systems are designed with neither one of these in mind. The combination of time pressure and needing to break down user input into something that a program can easily understand often means that although computer-moderated combat systems can in theory handle much more complexity than human-moderated ones, in practice, the complexity is often limited to "behind the scenes" things, with players having fewer options about what to do during combat than in paper games. What's Going On?But let's back up a step here. In order to make decisions about what you want your character to do, you need information about what's going on around your character. So let's talk about representation in interfaces. We'll start with the easy case: a fully graphical 3-D game. You see the area either in front of or around your character (depending on the point of view used), and the things in it. Indicating something tends to be a matter of clicking on it. Seeing that there are four orcs in front of you is... well, you just see them. And you can see such things as the fact that one of them is behind the other three, that they're a short distance away, that they're facing away from you, that two of them have axes and one has a sword, etc. All of this information comes at a cost, though — a cost in CPU cycles and memory spent figuring these things out and representing them, a cost in network bandwidth sending the information back and forth... and also costs in terms of hiring someone to make the art. But it can give a lot as well. Such things as positioning (am I behind this orc?), distance (am I close enough to hit him with a sword?), and line of sight pretty much come "free" with it — you're already keeping the data necessary for them. Graphical games tend to indicate action through animation — when one of those orcs attacks, you might see it take a swing. To provide additional information, there's often text as well, either in the form of a scrolling text window, or text "tags" on the objects on the screen. On the other end of things, we'll put text-based games using the traditional "room" concept. Your character is in a particular "room" (which may be an area outdoors, or part of a large room... and I'm going to drop the scare-quotes now that I've said that). Other objects and characters may be in the room. Generally you've got a room description and a list of what's in the room with you. There's no concept of distance or position within a room, nor of facing. Action in a text-based game is also indicated with text, of course. Such things as "The orc slices you with his axe!" or "Orc #3 exits to the north." Getting more advanced, a text-based game can implement a way for objects to be "close to" each other. Skotos' own in-house engine does this through its proximity system. Other games have other solutions — also here at Skotos, but not developed in-house, is The Eternal City, which allows characters to "approach" in order to enter close-combat range, and "retreat" back out of it. Going still further, one can have grid-based "overhead view" systems — which can either be truly graphical (e.g., the old "Gold Box" AD&D computer games, such as the original Pool of Radiance, or can be implemented using text, as the Roguelike games do. (If you don't know what a Roguelike is, and wonder how you can do an overhead view with text, there's a nice screenshot on the site for NetHack, one of the many Roguelikes). There's no facing here, but there is position and distance. As with a 3-D environment, action can be indicated either through animation (even with a text-based map... there's the things on the map moving to indicate movement, and there may be animation of spell or ranged weapon effects — e.g., drawing a line of dashes from source to target quickly, then erasing it again) or through text messages, or a combination of both. Of course, this isn't full coverage of the spectrum of possibilities — just a few examples to aid in talking about things. As I noted a couple of columns back, adding a map and positioning adds a considerable strategic element. In the above examples, both the 3-D and the overhead view games automatically have this. A proximity system can give some things, with clever coding — e.g., the ability to move "in front of" a doorway and thereby block it. One can create forms of positioning without a proximity system, though, by having special commands for it. E.g., a text-based game could have a "guard" command which allows a character to either guard an exit from a room, or guard an object or another character. Other commands could be implemented to allow different kinds of positioning — e.g., commands to get behind someone or something, or to form a shield wall with other characters, or to fight back-to-back with someone. Doing these sorts of things can be made the subject of skills or special abilities within the game, to add an extra dimension. (This is really the same sort of thing that paper RPG GMs often do when they're not using a map. If a player says he/she wants to guard the north door, most GMs aren't going to say, "you can't do that, we don't have a map". Rather, they'll say "Okay, you're guarding that door, and anyone who tries to go through the door will either have to be let through by that character, defeat him/her, or find some other way through.) To Be Continued...That's it for this time... but next time I'll be continuing on combat and user interfaces, and, if there's time, following that up with some thoughts on doing something different from the traditional "D&D" style of combat. See you in 14!
|
