The everyday blog of Richard Bartle.
RSS feeds: v0.91; v1.0 (RDF); v2.0; Atom.
11:25am on Thursday, 1st October, 2020:
Comment
This is a very long post about the combat mechanics in role-playing games.
At its heart, RPG combat is unidimensional. It's enlivened by adding multiple dimensions, in somewhat predictable ways.
Let's start by looking at the minimum that's required for combat: two participants (an attacker and a defender) and a combat action. The attacker performs the action on the defender and by virtue of doing so wins. This is one-shot, single-blow combat, which isn't generally regarded as being fun unless you're the one doing the one-shotting.
The next step is to give the attack a value and oppose it with another value. These values are usually numerical. If my attack equals or exceeds your defence, I win. Otherwise, nothing happens.
This isn't exactly competitive, so let's introduce the idea of an exchange of blows. We simultaneously take a pop at each other: in one half of the exchange, I attack and you defend; in the other, you attack and I defend. If my attack equals or exceeds your defence, you lose; if your attack exceeds or exceeds my defence, I lose. That's it. If only one of us loses, the other wins; if neither of us loses, it's stalemate; if we both lose, we both lose.
This is shaping up, but the victor remains predetermined because the attack and defence ratings are static. The first dimension we can add that makes things interesting is randomness. Attack values are modified by random amounts such that while the raw value would always either hit or miss, the modified value may do the opposite. The comparison is between modified attack and unmodified defence. You might have won against me every time before, but now you'll only tend to win against me most times.
Yes, I know that we could modify the defence, but the effect on possible outcomes is the same.
Yes, I know that if we use different randomness curves then I could win far more often than you, but the principle is the same.
Adding randomness means that in the event of a stalemate, it's possible to re-run the exchange and obtain a different result. This leads to the next dimension to add: time. If neither of us hits, we repeat the exchange until at least one of us does hit. As designers, we may or may not choose to allow combatants to withdraw between exchanges. We may or may not choose to allow any such withdrawal to be a unilateral decision rather than a mutual decision.
So far, then, we have a ticking clock. Each time it ticks, an exchange of blows takes place. Each participant takes on the role of attacker for one blow in this exchange and defender in the other; both blows in the exchange are undertaken in parallel. The success or otherwise of a blow is determined by comparing the attacker's attack value plus a (possibly negative) modifier to the defender's defence value. The combat ends when one or more of the combatants lands a blow on (that is, hits) the other.
We can complicate this by giving combatants more than one life each. They could have the same number of lives or they could have different numbers of lives. This extends the duration of the combat, turning it into a best-of-three, best-of-five or best-of-whatever series (treating a player with fewer lives as having pre-lost some exchanges).
The players will naturally see each loss of a life as a step change. This may be no bad thing, but conventional wisdom is that they prefer the boundaries to be blurred so that combat feels as if it's a more graduated activity. This is achieved by quantising the damage each blow does if it hits and further quantising the number of lives that the character has. For example, instead of having 10 lives and each hit doing 1 life of damage, characters can have 100 lives and each hit does 10 lives of damage. To achieve the necessary blurring, a bounded random amount is added to the damage done: instead of 10 lives lost per hit, it's a random number between 5 and 15 inclusive. We now stop calling them lives and start calling them "hit points". We start calling exchanges "rounds".
The new, finer-grained method of deciding how much damage is done allows for tuning. We can give combatants different base damage values ("strength") so that some combatants tend to do more damage when they hit than do others. We can give combatants different base hit-point values ("constitution") so that some can take more damage before losing than can others. The next natural step is to extend this to the base chance to hit ("dexterity"); we can oppose this by a similar value that determines the opponent's chance to avoid being hit ("dodge", which may be or be derived from dexterity).
So, at this point there is a series of simultaneous exchanges. Each exchange consists of two simultaneous blows, with each character acting as the attacker in one and the defender in the other. For each blow, a random number is generated for the attacker and added to (or conceivably multiplied by) their base dexterity. If this exceeds their opponent's base dexterity, the blow hits. The damage done is calculated by adding a random number to the attacker's base strength. This is then subtracted from the defender's current health (which at the start of the fight is equal to some function of their constitution). When a character's health reaches or goes below zero, that character loses.
Note that there's no interaction between the players yet. What we have at the moment is effectively a race.
Now that we have numbers set up for the basics, we can add further modifiers under player control. The most obvious way to achieve this is to associate different modifiers with different items of equipment. Doing so introduces an element of pre-combat choice for the player. For example, different weapons and pieces of armour can modify any of the calculations we have so far: the attacker's chance to hit; the damage the attacker does when they hit; the defender's chance to be hit; the damage done to the defender when hit.
Having categories of modifier allows us to make modifier-bearing items relevant in other ways. We can begin by connecting modifiers to other properties of combatants. The base damage done by a warhammer is 0 if the attacker's strength is below 25, otherwise 40. We can extend this to categories of combatants. The base damage done by a warhammer is 0 if the attacker's strength is below 25, otherwise 5 if the defender is of type jelly, otherwise 100 if the defender is of type skeleton, otherwise 40. We can further extend these to the categories themselves. The base damage done by a warhammer against plate armour is 50, but against padded armour it's 30.
Every time we add a new dimension, everything in that dimension can potentially affect the way that the dimensions we already have work.
This gives rise to the notion of effective values, which are values that are modified before they are used. The effective dexterity of a combatant is their base dexterity modified by, say, a value based on the category of armour they are wearing (heavier armour makes you less dextrous). The effective strength of a combatant is their base strength modified by, say, a value based on the armour and weapon they are using (and anything else they're carrying if you want to include non-combat factors such as encumbrance). These effective values can be combined: the effective damage of a weapon is its base damage modified, say, by the category of the target's armour and by a value dependent on the effective strength of its wielder.
Whether these modifications are positive or negative is determined by where you put the baseline. Traditionally, players like positives, so will like it if do +4 damage against skeletons even if this is the same mathematically as saying warhammers do -4 against everything else. Similarly, they can be multiplicative rather than additive, but players like seeing large additive numbers (+20) rather than smaller multiplicative numbers (+3%), even when the multiplier works out to a larger additive (3% of 800 is +24).
Having introduced the concept of more fine-grained combatant attributes and associated modifications of these by and to equipment (weapons, armour and what have you), the next obvious step is to make rounds themselves more fine-grained. We no longer have blows coupled to exchanges: they're independent events. There are still ticks, but there are more of them per unit of real time. This means we can say that to swing a longsword takes 10 ticks but to stab with a dagger takes only 5 and to whack with a battleaxe takes 15. Players now have to perform calculations: if a dagger does half the damage of a battleaxe but is three times as fast, perhaps that makes it a better weapon. However, if the battleaxe has a base 75% chance to hit and the dagger has only a 50% chance to hit, perhaps they're about the same. If the opponent is wielding a wooden shield that is transparent to battleaxes but not to daggers, the battleaxe will definitely be better.
We're now entering theorycrafting territory. Roll out the spreadsheets.
What we have so far is still a straight race: combatants compete to reduce their opponent's hit points to zero before their own hit points are reduced to zero. This happens automatically: combatants configure their modifiers pre-fight, then sit back and watch how it all unfolds. It could happen manually, though: combatants could be required to spam their "attack the opponent" action until one of them is dead. Either way, whether they win the fight or not is purely a matter of statistics.
In other words, after you've set up your pre-fight configuration, the combat phase itself could be reduced to a single, weighted coin toss.
For combat to introduce some level of skill, players need to be able to make decisions while it is taking place that can influence how it unfolds. This is achieved by allowing them to undertake other actions while the automatic actions are ongoing (or, if they're not automatic, then instead of the action they would normally be spamming). Providing players with such actions finally opens up the possibility of having limited interactions. This is because the effect of an attacker's actions may be contingent on the defender's actions. For example, if I see that my opponent is undertaking an action that raises a magical shield which will absorb all incoming damage for the next three ticks, I may decide to delay using my heavy-damage attack until the shield has dissipated. What I do depends on what you have done, are doing, and might yet do. My actions respond to your actions dynamically, and vice versa.
Rock/paper/scissors relationships between opposing actions can thus develop. If you begin a slow attack, I begin a fast one; if you begin fast one, I begin a parry; if you begin a parry, I begin a slow attack. These can be either organic or explicitly designed-in. Jab beats uppercut; uppercut beats hook; hook beats jab.
Rock/paper/scissors relationships eventually come down to "choose one at random". They can be obfusticated, so you don't know exactly how many rocks you should throw for every paper or scissors, but ultimately there's not much look-ahead. Actions are more powerful when they are used to change the values involved in calculations. For example, an action to adopt an offensive combat stance might increase the chance of hitting an opponent at the expense of increasing the chance of being hit; you'd use this if you were likely to be hit every round anyway. An action to deal negative damage to yourself (that is, "heal") might be worthwhile if you were out-damaging your opponent but had a smaller pool of hit points. An action to target the opponent's head ("hit location") might drastically reduce the chance of hitting, but massively increase the damage done if it succeeds; you'd use it if you were almost certain to lose, because it offers the hope of a victory that would otherwise not be forthcoming. Location-specific defences (such as a strong helmet) now become rational additions to the system.
Any of the numbers involved in combat calculations can potentially be modified by the appropriate use of combat actions. We can do much more with actions, however, because actions imply functionality. Not only can actions weight parts of up-coming combat calculations in different ways, but they can also introduce new steps of their own.
As I have described combat the moment, every one of the calculations involved is attached to a single piece of functionality. There is a calculation to see if you land a blow, then a calculation to figure out how much damage is dealt. Nothing else can happen if the attacker's to-hit calculation succeeds except that the process continues to the damage calculation; nothing else can happen if the damage calculation returns a value except that this value is applied to modify the hit points of the defender. There could be interesting consequences, but it's all very smooth and mechanical.
Actions allow for us to attach different functionality to the effect of a calculation.
We can do this by allowing the effects of a calculation to vary depending on the result of that calculation. For example, if the way the random numbers pan out result in the attacker's to-hit value being the maximum possible, then the usual next step (that checks against the opposing value) could be skipped. This would mean that if the random numbers fall your way (for example "rolling a natural 20") you always hit, regardless of your opponent's defences. This isn't the only functionality you could attach, of course. A to-hit roll above a certain threshold could influence the damage calculation (a critical hit); below a different threshold could also influence it (a fumble).
These checks don't have to be made for just the attack calculation. They could be applied to the defence calculation, or to any sub-calculation. You could look at the mitigation provided by armour and if it exceeded a certain threshold then double it as some kind of critical defence; this would then play into the overall calculation to see if an otherwise fatal blow had landed.
Actions allow for such one-off changes to combat calculations to be introduced consciously by the player. Armour may mitigate a certain amount of damage from every blow, but if the player executes some kind of bracing action then it may mitigate a much larger amount for only one blow, or a total amount across several blows. Actions also allow for repeated effects, such as causing an independent combat event to take place every so many ticks ("damage over time"). This facility enables actions to step outside of the tick regime being used for automated combat. I may only hit you every 8 ticks with my whip, but if I get a critical hit on you then I could cause additional damage every 3 ticks on top of that ("bleed").
Speaking of ticks, we can extend their use to action invocation. Actions don't have to complete on the same turn they begin: they can require several ticks of preparation ("casting time") before they are executed. This gives an opportunity for other actions (or background combat events) to interrupt them, resetting the timer. Action effects can also take time to complete: a grenade may explode ten ticks after the tick in which it was thrown.
Because they're so wide-ranging, actions can throw wrenches into otherwise fairly predictable combat, so causing new and interesting situations to arise. They're a big part of what makes combat fun.
Actions can chain together, such that each one enables a new one ("combos"), which can multiply their overall effects. Unfortunately, this can lead to a geometric increase for powerful actions that are used too frequently or that have effects which stack with those of other actions, so usually they will be limited to one use every so many ticks (their "cooldown"). They may be further restricted to be used no more than a certain number of times (possibly only once) per combat. Even so, if there is a large number of actions with process-altering effects in play, there is a danger that they may collectively add too much variance to combat; players can't plan ahead when the combat landscape completely changes every time their opponent does something.
What we have at the moment, then, is something like as follows. There is an automated combat stream going on, which if neither player does anything will play out over time in a manner determined basically by statistics. The players can perform actions that affect this automated combat, by changing the numbers used in calculations and by introducing new one-off or over-time functionality to it.
It's possible that the effects of the actions performed by players to modify the background combat stream are so great that the stream itself is mere noise. If our automated blows are doing 1%-3% damage but our action combos are doing 10%-30% damage, then the fight becomes more about the players' actions ("foreground combat") than the underlying automated process ("background combat"). In such a situation, we could switch off background combat entirely.
In practice, RPGs usually retain the background combat stream. This is because not all combatants are necessarily players: some may be under AI control. It's less computationally intensive to have these use background combat most of the time, with occasional pieces of foreground combat when particular, easy-to-test conditions are met (such as being reduced to half their hit points).
If players can perform actions, so can AI opponents. If AI opponents are largely automated, why can't background combat (which is also largely automated) also perform actions?
Well, it can. This adds yet another dimension to combat, which I hinted at earlier when talking about critical hits. The output of any piece of functionality can be compared against a threshold (which itself can be modified, so is properly called an "effective threshold") and if it meets a given criterion (higher, lower or some other function) then it triggers an action to take place. For critical hits, this action is specific to damage (or sometimes to-hit) values and its effect is simply to increase the damage output for this blow. However, having established the concept of associating multiple functionalities to calculations depending on their result, it is now a relatively easy leap to add new calculations that are there specifically to introduce the possibility of new functionalities. One blow in ten, some property of you (or of your weapon, your location, your faction, the weather, the world in general, whatever) causes a function to fire. This is called a "proc" (short for "process"). Its functionality can affect any aspect of combat, or indeed of non-combat. For example, if your warhammer procs then for the next ten ticks your opponent might be slowed down, taking an extra tick to perform every action.
Procs, as with other alterations to the combat stream, can sometimes be so frequent as to become the stream themselves. Indeed, it's possible to look at the basic exchange-of-blows background combat stream as a sequence of events (attempts to hit) with associated procs (damage is caused when the to-hit threshold is exceeded). With foreground combat, player actions are effectively player (as opposed to character) procs.
Taking this proc-oriented view frees up further dimensions for change. Action combos, as opposed to the actions themselves, can be given procs. Such combos can have starter and finisher components to them that together proc in different ways to independent actions. They can also be cyclical. Managing chains of combos to best effect, subject to all the other contraints that apply (such as cooldowns) allows for the development of standard sequences ("rotations") that can be treated as units by the player. In other words, these too can proc.
The effects of a proc can apply either to the combatant whose calculations are being made or to the other combatant. For example, a damage proc need not apply its effects to the defender of an attack: it could instead apply to the attacker. This could take the form of a reduction in hit points on the part of the attacker (cursed weapons often do this), but it could equally well do the opposite: a negative-damage attack on the attacker is effectively a heal. If this repeats every few seconds, it's a heal over time. An attack proc could cause a defence barrier to erect, or the maximum number of hit points the attacker has to rise, or any number of other favourable or unfavourable results that could come from changing any of the variables and values involved in combat calculations.
Procs serve to illustrate the point that functionality can be associated with anything to do with combat. Any change to any combat-related variable could cause a proc, which could in turn make changes that cause other procs, possibly cascading in a fashion satisfying if you're on the delivering end and unsatisfying if you're on the receiving end. I'll briefly return to this idea later.
First, however, what I've described so far is all about adding functionality. Actions are performed that change combat-related values or enable other actions. This suggests that it should be possible for actions to disable other actions, too. The crudest approach is to allow certain actions (possibly procs) to prevent an opponent from doing anything at all for a certain number of ticks ("crowd control"). This is effectively an extended interrupt. Players don't like it one iota when it happens to them; furthermore, they'll fly into a rage if, while they're unable to act, their opponent performs another action that extends the duration of the period of action-suppression (a "stun lock"). Stun locks are therefore to be avoided in combat situations except for those in which it's clear who's going to win anyway and it's a kindness not to drag it out.
A more subtle approach to the disabling of actions is to forbid players from performing only certain ones for a period, allowing all others as normal. This works especially well with hit locations, which is possible when actions can target (or randomly strike) a specific part of the body, for example as a result of some "aim high" or similar combat stance. If you were to whack me on my sword arm, say, then I may for several ticks be unable to wield my sword (that is, perform any actions, foreground or background, that use the weapon). This can add an element of quick-thinking to combat to cover for the emergency, which players can enjoy; however, it has to be obvious that it's happened and it can't occur so often as to be pretty well permanent. Also, if the combat is to maintain fictional integrity, the effect should make sense; for human combat, this reduces the possibilities somewhat, as there aren't many different locations for players to target. Hit location is therefore not used a great deal for player characters in RPGs. The idea works much better for vehicle combat, though, because there are more opportunities to relate action-(or effect-)suppression to damaged locations. A critical hit on a spaceship's port shields could knock out the shield generator; a second hit while the shields are down could knock out the port thruster, or the port lasers, or the life-support systems. Players don't like it if their character loses a hand in combat, but they don't mind so much if their car loses a door.
Speaking of fictional integrity, actions that players can execute directly are usually given evocative names. Players can use these to refer to said actions in discussions. Common effects of actions are also given names. This mere action of naming suggests natural categorisation of actions and effects, which if implemented make them more situational. For example, a damage-over-time effect could be called a bleed (which can be addressed by a cure wounds spell or a bandage) or a poison (which can be addressed by a cure poison spell or an antidote); the effect is the same, but in preparing for a fight with a creature that causes lacerating damage you would be advised to stock up on bandages rather than antidotes. Resistances can also be categorised: you could be immune to poison but susceptible to cuts. If there are too many different categories of effect, though, then remembering which actions address which conditions becomes tiresome.
Another problem with categorised effects is that of the implied category that doesn't exist. Surprisingly often in RPGs, actions are given names that are not properly reflected in their functionality: they don't behave how their names suggest they should. For example, a spell called "exanguinate" should do full damage to opponents that have a bloodstream (such as mammals), minor damage to opponents with no blood but something like it (such as plants with sap) and no damage at all to anything without a liquid to be sucked out of its innards (such as rock golems, ghosts and skeletons). Even though paying attention to such details makes for better immersion and more interesting gameplay, they can be very finicky to program. Categorisation is therefore usually only in place for certain designer-prescribed categories (often related to fire, earth, water and air, plus occasional other such "elements" such as life and death, light and dark, ...).
Up until now, what I've described is fairly system-independent. When we consider system-dependent dimensions, further opportunities for adding wrinkles to combat present themselves. I won't go into great detail here as it depends on the system, but I'll outline some examples of what I mean for the main two cases: spatial and interface characteristics.
Spatial characteristics introduce new dimensions literally. They allow for: actions to have ranges; positioning of combatants to matter; actions to have areas of effect; actions to be targeted (arrow flies at opponent) or untargeted (arrow flies at where you hope opponent will be when arrow lands). Therefore, movement becomes important. If there are so many different area-of-effect actions that it's hard to remember which does what damage where, telegraphs can be introduced to help. This calls for awareness and good reactions, which can be fun until it becomes repetitive.
Interface characteristics can also make a difference. In particular, the set of available actions can be limited to a number of slots. These slots can be categorised such that only certain classes of actions (or action proxies such as weapons) can occupy certain slot ranges. You may be allowed, say, eight active slots (click to perform the associated action) and eight passive slots (actions that are part of the pre-combat set-up, like armour but with a wider range of effects possible). There may also be a limit on the number of slotted actions of a particular type allowed (only one frost-effect spell, only two single-handed items, only one level 3 martial arts attack).
OK, so we've covered most of the RPG combat possibilies now. However, as I've described it, combat is between two combatants. What happens if there are more than two combatants?
In the simplest case, each opponent can only fight one opponent at a time. When we had this, players had to queue up to take on the same enemy. The first advance was therefore to allow for multiple fights involving different opponents to occur at the same time, with each one handled without reference to the others. If A attacks C and B attacks C, there are two fights ongoing (AvC and BvC). Assuming for the moment that A and B are roughly on a par, C is taking twice as much damage as they would from one fight — but they're also dealing twice as much damage. Although the former makes sense (the fight is two-on-one), the latter doesn't. This is corrected by associating with each combatant a number of attacks that can be executed simultaneously.
The nature of the attacks now becomes a dimension in itself. A giant scorpion has two pincers and a tail, so can attack three times independently. The tail does a different kind of damage to the pincers (it's poisonous) and it prioritises different hit locations (higher up rather than lower down). It may have a better chance to hit someone who is gripped by a pincer than it does someone who is still mobile. The pincers can only attack opponents directly in front of the scorpion, but the tail can strike anywhere except directly behind. The pincers can each attack a different opponent, unlike a lion's front paws which both have to attack the same opponent and are therefore effectively a single attack.
If the number of attacks a combatant can make can be constrained, so can the number of attacks made against that combatant. This is usually only applicable for melee combat, but it can apply to ranged combat too. In the general case, the typical method used to calculate the number of opponents who can attack a combatant at once is to introduce a size value. A large (size=8) creature can be attacked by a single creature of size large or greater, but by four medium (size=2) creatures or eight small (size=1) creatures (or some combination of the latter two that adds up to no more than 8). Any number of tiny (size=0) creatures, such as mosquitoes, can participate. This allows for size to become a factor in calculations, too, so a larger creature may be easier for a smaller creature to hit but it will in return deal more damage, possibly to more individuals, than it would to a single creature of its own size.
Depending on the geometry of the RPG's environment, spatial factors can replace a size abstraction. Combatants have collision boxes, and the larger the creature then the larger its collision box; smaller creatures can therefore surround it in number. Terrain effects can also come into play here: if a troll has its back to a wall, fewer creatures will be able to surround it than if it were standing in the open.
In practice, the more players an RPG has, the less likely it is that collision boxes will be used to limit the permitted number of attackers. This is because if player characters have universal collision boxes then griefers can block access to bosses (and to the entrances to important locations such as shops). Collision boxes are therefore often turned off for characters who aren't fighting each other. For similar reasons, the possibility of friendly-fire damage may also be removed: toss a grenade into a mass brawl and the resulting explosion will somehow manage to assail only those combatants on the opposing side.
Player characters do not usually have the ability to undertake more than one attack at once. This is for interface and targeting reasons. AI-controlled combatants are not so constrained, so the question can then be asked: which of the multiple possible targets available does the AI choose? The answer is found by introducing another suite of mechanics ("threat") that manage the AI's target-choosing functionality. This affects not only the targeting used by the AI for voluntary actions, but also the targeting employed in its automatic, background combat stream.
In summary, then, combat takes place as a series of blows between combatants, tied to ticks. When a combatant has the opportunity to act, they choose a target for that action (if required). One, background series of attacks is in essence the repetition of a complex set of largely unchanging statistical equations. It is moderated by a second, foreground series of dynamic attacks that carry the gameplay.
I could at this point create a large flowchart for each tick. Am I able to attack? Is my preferred attack off cooldown? If so, whom do I attack? Has my attack completed? If so, does it terminate a combo? Does anything proc? Is my attack on target? Does anything proc? Does my opponent dodge my attack? Does anything proc? How much damage do I do? Does anything proc? To what do I do the damage? Does anything proc? While addressing the consequences of a proc, does anything proc? Is my opponent dead? Am I dead?
I shall not be creating a flowchart, however. I leave it as an exercise for those who want to learn how much fun it is to create one.
Instead, I'll briefly return as promised to the subject of procs. As the description in the previous-but-one paragraph suggests, these can be called in an alarming number of places an alarming number of times. I hit you — proc! You take extra damage. Your magic armour receives this — proc! It reflects the damage back to me. My shield deflects it — proc! It sends a plasma bolt at you — proc! Double-damage, critical-hit head-shot! Woohoo!
One way to look at this is to consider procs as being the creation of new participants in the fight. There could be such participants anyway (environmental factors such as lightning may be able to swing a fight), but procs are more fight-specific. They create an entity (a "daemon") which, when it gets a chance to act (this could be immediately upon creation) does its job then disappears. In doing its job, it could cause a proc that introduces another daemon, and so on until nothing procs and the processing for that tick can end.
This same mechanism can be used to explain non-proc behaviour. For example, if you cause someone damage over time, that's like creating a daemon that waits out the ticks until it can act, whereupon it causes damage to its target (if they're still alive); if its counter isn't zero, it creates a copy of itself (identical but with a decremented counter), then it dies.
Player actions are just daemons invoked by players. Each tick, all extant daemons are examined and their ticks-to-execute count is decremented. Those with a zero or negative tick count are then taken in turn and considered for execution, lowest-first; this is so some daemons can execute before others (you'd want a player's cure poison spell to kick in before the poison daemon can do its dirty work). I say "considered for execution" because you might wish to give some daemons only a chance of executing (the firework may not go off) and may intend other daemons to be able to interfere with this possibility (give the otherwise-certain paralysis daemon a certainty of only 50%). You can do this by putting guard daemons on other daemons if you prefer; the approaches are equivalent.
Very few systems use this daemon-chaining approach, because "the time budget for this is 4ms", and it's hard to debug. What it buys you is the ability of code to look at other code as data. This allows for some extremely powerful effects, but they can almost always be handled in other ways and they tend to be used rarely anyway. It's a high-cost luxury for very little gain, so can reasonably be ignored. File it under "experimental".
The flowchart stage is pretty well where we are today with RPG combat. As you can see, the whole system the result of a series of incremental changes that over the years have accreted to the basic mechanic of person-with-gun-shoots-and-person-hit-by-bullet-dies. It's quite sophisticated and in general is oodles of fun.
None of this is how combat actually works in real life, though. It's just what's evolved in games.
Latest entries.
Archived entries.
About this blog.
Copyright © 2020 Richard Bartle (richard@mud.co.uk).