|
Combat, Part 6: Battle Stancesby Travis S. Casey Last time, we started considering how combat systems relate to user interfaces; in particular, how a user interface can make certain elements easier or harder to work into a combat system. One idea that some games implement is that of different combat "stances" — offensive, defensive, and so on. The Eternal City here at Skotos does this, with [check and insert] as the different stances available. This set of stances forms a continuum, from fully defensive to fully offensive. Seen this way, they've equivalent to setting a slider — and in a game with a GUI, a setting like that could be substituted with a slider. Using a slider could also easily allow for a more finely-grained division between attack and defense. The paper RPG Rolemaster uses a "percentile" system for skills, with skill ratings generally ranging from 0 to 100. In combat, players decide how to divide their character's combat skill between attack and defense, giving a very finely-grained possible division. In a computer game, such a calculation could easily be performed based on the setting of a slider. However, this is another sort of setting for combat stances, which can't be represented as a simple continuum from attack to defense. Namely, stances with regard to the desired outcome of combat. On the offensive side, killing, knocking out, or capturing might be the desired outcome. On the defensive side, one might wish to restrain an opponent to stop him/her attacking, to get away, to knock out... or even still to kill. Most online games only have combat with the intent to kill, but adding other options to a combat system can add many possible setting elements. For example, if it's possible to engage in combat for more limited purposes than killing an opponent, then certain kinds of character conceptions become easier (or, in some cases, possible). For example, a bounty hunter ought to be able to capture a target and bring him/her back. A non-violent sneak thief who, if confronted, simply tries to escape or to tie up opponents is another example. On the reverse side of things, a classic element of many stories is for some or all of the heroes to be captured at some point, then have to escape or be rescued by the non-captured heroes. Sometimes heroes in stories allow themselves to be captured, so they will be taken somewhere. Without a combat system which allows for capturing, these things aren't possible. Text-based AdvantagesSo, far, it's looking like a GUI (even a text-based 'GUI', like those of the Rogue-like games) has a lot of advantages over a text-based system. So, since a lot of Skotos' games are text-based, and since text-based games are generally easier for those without large budgets to set up, let's look at some things that text-based games do better. The use of text instead of artwork can make adding certain sorts of features much easier. For example, consider adding the ability for a character to get knocked down in combat. In a GUI, you'd want to add some depiction of a knocked-down combatant. Note that this might require a lot of artwork — a "knocked-down" version of each creature in the game, for example. In a fully-animated GUI, you might want to add animations for falling down and standing up — and again, this might have to be done for each creature in the game. (Of course, there are ways to reduce this effort — for example, making each creature be an articulated 3-D model means you don't need new artwork — you just have to tell it how to move. However, that raises the requirements for your user's systems.) In contrast, in a text-based system, a simple "X is knocked down" and "X stands up" takes the place of all that. The creatures' descriptions might have a tag added to them as well — e.g., (knocked down). The simplicity of such notifications and "status displays" can free the game's designers and implementors to focus on other aspects, such as the underlying systems. This isn't the only case where a seeming lack in one area can make things easier in another. For example, consider a swashbuckling game in the vein of The Three Musketeers and the like. In an environment which attempts to show exact positioning, implementing a "swing on the chandelier" command and making it even somewhat believable is going to require giving the chandelier a location, then having swinging on the chandelier change the character's location. Further, how swinging changes the character's location will need to make some degree of sense. Without positioning (e.g., in a "room-based" environment), all of this can be ignored. You want to swing on the chandelier and hit Cardinal's Guard #3? Go ahead and try it — without positioning, there's no reason to even worry about where the two of you are relative to the chandelier. Player/Character SplitSuch abstraction can feed into something else — the split between player skill and character skill. In theory in an RPG, one should be able to play a character who is an expert at combat without having to be an expert at combat yourself — either at real-life combat or at the game's combat system. The more detailed positioning and such is, the more players are going to expect it to make a difference — and their suspension of disbelief will be disturbed if it doesn't. For example, in a room-based system, it's accepted that any character in a "room" can attack any other character in the same "room". Once positioning is added, however, players are going to expect that someone will not be able to punch a character who's standing on the other side of a large room. It may seem that not having detailed positions limits the factors one can add to combat greatly, but there really are quite a few ways that one can get around it. In the forums for this column, one reader mentioned the idea of forming a shield wall, and stated that this could only be done with exact positioning. However, that's not true — in a room-based game, one could simply add commands for characters to form a shield wall — e.g., "form shield wall with X". Whether this can be done successfully could depend on skills (e.g., on a "group tactics" skill and/or a "shield use" skill) and could be modified by the relative number of allies and opponents. More generally, one could instead have a "stand with X" command. Such a command could interact with others. For example, if someone uses a "guard" command to guard an exit, and then someone else used "stand with" to stand with the character doing the guarding, then the system could note this and require defeating or slipping past both of them before being able to get to the door. Choosing a room-based interface doesn't have to require getting rid of things which seem to require positioning — it just means that the ability to successfully do them will become more dependent on character skill rather than the player's ability to maneuver. (Indeed, one could add a generic "maneuvering" skill to represent how good the character is at getting around in combat. In a text-based environment, one could easily change messages for this to add to a game's flavor — e.g., for Hong Kong-style combat, print descriptions of the character jumping over foes and the like.) Next time, I'm going to talk about D&D-style combat — what it is, what it's good for, and ways to get away from it. See you in 14!
|
