Imaginary Realities had a perpetual nonexclusive license to republish and reprint this article, and the same has been granted to Tharsis Gate.
The original article is Copyright 2000 by Darklock Communications
Let me start by saying that I am opinionated and obstinate. I will say several things in this article which imply or even outright state that something your favorite mud does is the wrong thing and a bad idea and no mud should do it. It is, however, perfectly okay for you to do something the wrong way just because you like it. Games, while we do not always acknowledge this (particularly we the designers and developers), are supposed to be fun; they are not necessarily required to be realistic, scientifically accurate, or theoretically sound. If a game is fun, then it has been done right. If a game is not fun, then it has been done wrong. All other measures of a games correctness are philosophical crap.
Many different sorts of fudge to help fill out your combat system. |
That said, I will proceed to spout a large load of philosophical crap.
Protracted combat and the uncertainty of success
Most Muds today use a very detailed, protracted combat system. This
system supposedly represents the way real combat works. To a degree,
it does, but it often neglects the real-world fact of combat -- most
combat is not protracted, does not involve more than a couple of
blows, and a winner is decided in virtually no time at all. The
experienced combatant can tell at a glance whether he will win or
lose in combat with a specific individual, as can most inexperienced
combatants (with a little less accuracy).
To some extent, blow by blow combat is exciting. There is a real sense of some kind of spectator sport, which you can kick back and enjoy much like boxing. But there is also the tedium of mud combat where you wander through place after place after place, looking for things to kill and spending two to three minutes killing each of them.
In my current project, combat is resolved instantly. Anyone can determine to a reasonable degree of accuracy whether he will win or lose a combat, and whether or not a given mob will be the attacker ('aggro' mobs, which attack anything they see) or the defender (normal mobs, which ignore players until they are themselves attacked).
That latter is another failing of many combat muds; it is important to know whether that huge minotaur will let you pass through on the way to the forest, or smash you with that big hammer on sight. As it stands, most muds leave this information a complete mystery, which can only be determined through trial and error. With the recent popularity of "permadeath" on muds (death which cannot be reversed by spells and/or items), this is an expensive error... especially after a character has been built up to a significant level of power. While it would be interesting to delve into ways this can be made more workable, and ways in which some current efforts are flawed or imperfect, this will be ignored at the moment.
Combat evaluation
The real keys here are that the possibility of combat should be something
that a player can evaluate and make an intelligent decision on instantly.
When you look into a room, you should be able to tell at a glance what
creatures there will or will not attack you, which ones you are likely
to be able to defeat, and which ones are likely to make you into an ugly
stain on the floor. Failing this, the player cannot intelligently determine
whether or not he should go into the room -- it is a crap shoot. Monster
descriptions fail miserably; we have all probably seen Monty Python and
the Holy Grail, and the killer rabbit. Most muds will provide a killer
rabbit somewhere, with a suitably innocuous description. Most muds will
also provide a normal rabbit somewhere, which is easily defeated. Given
the two instances of "small white rabbit", one a wimp and the other a tank,
the description becomes nothing less than a cruel trick.
I will pause here to deliver a short warning. If you are a long-time gamer who has been online for many years, you may recognize the terminology and displays below, thus discovering which game I am working on; it is not my own invention, but an exclusively licensed project from another company. I must caution you that the game is in a VERY early stage of development, and is not expected to be open to the public (or even on a publicly accessible server) for quite some time. I would greatly appreciate it if those who do recognize the game refrain from writing me with lots of questions about it. There is a LOT of work left to be done on this project, and there is a reason it has not been publicly announced. (There is also a reason I have begun serious work on updating a game which has been out of active development for nearly four years: it is the worlds greatest game.)
My game is reasonably different from the average mud, being a space
simulation. Rather than mobs, there is a simple concept of drones (fighter
spacecraft) and their owners. Drones are programmed to attack specific classes
of target; as the Federation is at war, it is common to set drones up to
attack only the enemy, but drones may also be programmed to attack everyone
except you, attack everyone not on your team (similar to the "group" command
on most muds), or even not to attack at all. Specific devices must be
purchased to see who owns the drones in a sector and/or what their
programming is. These devices are considered "standard" enough that they are
easy to acquire and virtually ubiquitous, but someone who just plain does not
go into sectors with drones (or is so powerful that their presence is
basically irrelevant) need not carry them. I will be assuming you have both
such devices in these examples. If you have neither, then you would see
sector 2119 on my current testbed server as:
Sector 2119
152178 Attack Drones
This is reasonably uninformative. It is roughly equivalent to seeing some random mob on any other mud. If you have only the owner identifier, you would see:
Sector 2119
152178 Attack Drones of the Cabal
Given that the Cabal are hostile, you can assume from this information that they will be jumping all over you as soon as you enter the sector. If you are new to the game, however, you may not make this connection. And if you have only the programming identifier, you would see:
Sector 2119
152178 Attack Drones [Attack all but Owner]
This is pretty obvious. If you are not the owner, you have a problem. But assuming you have both, you would see:
Sector 2119
152178 Attack Drones of the Cabal [Attack all but Owner]
You can immediately determine from the above display that if you enter this sector, you will be attacked by a hundred and fifty thousand drones. Another sample:
Sector 11
71178 Attack Drones of the Federation [Attack the Cabal only]
Assuming you are not part of the Cabal, it is evident here that you will not be attacked by the above drones. You can thus decide based on this information whether you want to enter the sector or not. Sector 11 is safe for everyone but the Cabal. Sector 2119, on the other hand, is safe only for the Cabal.
Attacking and game internals
Now, if you actually want to attack the drones in sector 2119, you can do
so. But in order to determine your chances of success, you need to consider
your own forces; checking my inventory, I note that I have 35,000 drones;
this is far fewer than the number I would be attacking. It is obvious,
assuming a statistically even distribution of drone ability, that the greater
numbers will win. If I decided to attack the Federation's drones, I would
still be outnumbered 2 to 1.
The game could, of course, use some sort of iterative comparison. Each drone could be given a skill of 50%; we could then alternate checking each drone, with a roll of 50 or less resulting in a kill on the opposite side. The chance of success would be minimal, but even a single drone could conceivably kill several thousand opposing drones. The strength of numbers, however, is still a reliable indication of how the battle will proceed -- and rolling 200,000 dice takes time.
As a result, it is reasonably futile to go through any sort of protracted battle procedure. We can assume that the greater attack force will win, suffering losses roughly equivalent to the numbers of the lesser attack force. However, we must account for some degree of randomness; so we assume that one out of every thousand drones might account for two kills instead of just one. This is not a statistically significant value. It will have virtually no bearing on the outcome of the fight in most cases.
So when I take 35,000 fighters up against the 71,178 drones of the Federation, a random number from 0 to 212 is generated; I then subtract 106 from this to determine a signed value to apply to the attacker. Assuming that I receive a random number of 200, I acquire a modifier of +94, which is applied to my forces. I therefore cause losses of 35,094 to the Federation, leaving the Federation at 36,084 and me at 0. The number of drones being roughly equivalent in operation to most muds hit points, I lose the battle and am destroyed.
The notable exception to the values statistical significance is when roughly equivalent forces clash. If I were to go and buy 117,100 drones in order to take on the Cabal in sector 2119, I would have 152,100 to their 152,178. There is a chance I may win; if any number over +78 is generated as a skew value (a 227/609 chance), I will eliminate all their drones without losing all of mine. If anything less than +78 results (a 381/609 chance), I will lose and be destroyed. If a result of exactly +78 is generated, we will stalemate and both forces will be destroyed. I have roughly a 35% chance of success. If I were to buy an additional 400 drones, I would be assured of success, no matter what the random factor is.
The random factor actually has another purpose, which is a little less exciting. If there were no random factor, then there would not be any indication that anything was happening except a direct "greater=greater-lesser, lesser=0" fight. It would then LOOK like nothing was happening and the outcome was never in doubt. Certainly, the outcome is never in any great degree of doubt and that doubt can be minimized or removed by tacking on a few extra drones on your end, but the appearance is that a huge battle has been resolved with blinding speed. The randomness primarily adds variation to the numbers for a general sense of chance, and is a user interface issue more than anything else. (I apologize if I have spoiled the magic for anyone.)
Other "instant" methods
One could, if desired, implement a statistical iteration: on each
run through the loop, half of each force is subtracted from the
other, until one of the forces drops to zero or below. A random
skew on each iteration would place the outcome in much more serious
doubt. I have seriously considered this sort of iterative algorithm
for a future version, but I am unsure whether I want to introduce
that sort of alteration to the game due to both speed and interface
concerns. (There is a certain value to everything working the same
way it has always worked, especially considering the dedication of
this game's followers.)
I could go on about this for a very long time if I let myself, but I think this covers all of the ground I originally expected to.
In closing, I would like to point out that what this comes down to is time and effort. For every second you spend in combat displaying neat little messages, you lose a second that the player could spend playing the game. If you talk to players, few of them are pleased to sit around watching combat results roll up the screen. They want the combat resolved quickly and efficiently. An instant combat process saves the player much time, and an obvious consideration method which lays the potential combat results out plainly and easily saves him much concern.
March 2000 Imaginary Realities, the magazine of your mind.
© Copyright Information