The CMUd discussions gave me an interesting idea for an elaborate one-on-one melee combat system. It's probably more complex than anyone other than me would be interested in, so I didn't want to hijack the CMUd thread, but feel free to steal any parts of it you like.
As usual, each participant has one equiped or "active" weapon. Each body part has some type of armor equipped. The new (ok, it was suggested in one of the other threads) element of combat is that in addition to equipping weapons and armor, each participant selects a "stance". The stance determines what types of strikes the character will make, how effective those strikes are, and how effective their defense is against specific strikes.
Combat is a series of rounds (until I figure out how to add more participants). On each round, assuming that the first command in the queue is melee attack the current opponent, the character will make a single attack.
The first step in the attack is that based on the current stance, a vector for the attack will be determined. Vectors are things like thrust to the midsection or slash diagonally down from high right. Each stance would only be capable of attacking on some subset of the vectors. A fencing en guarde stance might be able to thrust high, mid and low. A two-handed overhead position might be able to do vertical slash from high or either diagonal slash from high. The particular vector is chosen randomly (it makes combat more visually exciting if the characters are switching attacks around). In a graphical client, the vector determines the first part of the animation of the attack.
In addition to choosing the vector, the game also computes the attack's base effectiveness. This is a function of the weapon (each weapon has some inherent accuracy). It's also a function of the attacker's skill with the weapon (the sum of their skill with that weapon-specific skill, the weapon group skill, and their overall melee accuracy "attribute"). It is a function of the weapon's suitability for the current stance (you can't fence with a sledgehammer). Optionally, the effectiveness may be penalized if the stance requires mobility that would be impaired by the current armor (you also can't fence in full plate).
Stance-based combat
Now, for defense, the game knows the following:
If the attack is along a vector to the defender's front, they have two extra chances to avoid it. First, they have a chance to dodge the attack. The dodge's effectiveness is a function of their stance's mobility (possibly penalized for wearing heavy armor or carrying a lot of gear). It's also a function of the defender's dodge "attribute". Some combination of the attack's base effectiveness, the dodge effectiveness, and a random number determine whether the character dodges (displaying an appropriate dodge animation).
If the dodge fails, the defender has a chance to parry with their weapon. The parry effectiveness is a function of the defender's skill with their weapon (and weapon group and overall parry skill) and the suitability of the weapon for parrying (main-gauche=good, whip=bad). It is also dependent on whether the defender can parry against the attack vector from their current stance. Each stance is only able to parry a subset of the attack vectors. An overhead grip would have no chance against a low blow, for example. It would perform poorly against a horizontal cut. However, it would do well against a downward slash or a high thrust. So each stance must have a table of effectiveness factors indexed by attack vector. Again, the total parry effectiveness is compared to the attack effectiveness and if it succeeds, the attack animation is aborted (or segued into a parried animation) and the defender does the parry animation corresponding to the vector.
If the dodge and parry both fail (or aren't possible due to the attacker's position), then the defender has one last chance to avoid damage--their armor. Using the attack vector, determine which part of the body will be hit by the attack. The chance of the armor deflecting the blow is based on the armor's effectiveness, penalized if the armor type is vulnerable to the attack type. Chain is weak against thrusts. Plate is weak against penetrating swinging attacks (like warhammers and certain spiked polearms). Again, determine the overall armor effectiveness vs the attack effectiveness. Abort the attack animation on success. No defender animation is necessary. [/list]
- The vector of the attack relative to the attacker
- The location of the attacker relative to the defender
- The base effectiveness of the attack
If the attack is along a vector to the defender's front, they have two extra chances to avoid it. First, they have a chance to dodge the attack. The dodge's effectiveness is a function of their stance's mobility (possibly penalized for wearing heavy armor or carrying a lot of gear). It's also a function of the defender's dodge "attribute". Some combination of the attack's base effectiveness, the dodge effectiveness, and a random number determine whether the character dodges (displaying an appropriate dodge animation).
If the dodge fails, the defender has a chance to parry with their weapon. The parry effectiveness is a function of the defender's skill with their weapon (and weapon group and overall parry skill) and the suitability of the weapon for parrying (main-gauche=good, whip=bad). It is also dependent on whether the defender can parry against the attack vector from their current stance. Each stance is only able to parry a subset of the attack vectors. An overhead grip would have no chance against a low blow, for example. It would perform poorly against a horizontal cut. However, it would do well against a downward slash or a high thrust. So each stance must have a table of effectiveness factors indexed by attack vector. Again, the total parry effectiveness is compared to the attack effectiveness and if it succeeds, the attack animation is aborted (or segued into a parried animation) and the defender does the parry animation corresponding to the vector.
If the dodge and parry both fail (or aren't possible due to the attacker's position), then the defender has one last chance to avoid damage--their armor. Using the attack vector, determine which part of the body will be hit by the attack. The chance of the armor deflecting the blow is based on the armor's effectiveness, penalized if the armor type is vulnerable to the attack type. Chain is weak against thrusts. Plate is weak against penetrating swinging attacks (like warhammers and certain spiked polearms). Again, determine the overall armor effectiveness vs the attack effectiveness. Abort the attack animation on success. No defender animation is necessary. [/list]
Now, as far as character stats go, this system requires the following:
I'm thinking that the skills/attributes would be purchased using skill points gained from experience or leveling. However, I think stances should be learnable from trainers (basically stores) or in some cases quests.
Now, when I said weapon, I actually meant the combination of whatever the character is weilding in both hands. It might be a two-handed weapon, two weapons, or a weapon and shield. Any given stance is only useable with one of those combinations, though there might be multiple versions of a stance that work for different combinations. Two weapon stances would probably have the most variety of attack vectors and would be able to parry most directions. However, they would have severe penalties to parrying attacks from heavy weapons (especially two-handed weapons). Two-handed weapons would have limited attack vectors from any given stance, but would do lots of extra damage and as mentioned before, get a bonus against parrying with with light weapons. Weapon+shield would have great parrying capability against almost any type or vector of attack, but would have poor offensive capabilities.
- Overall melee attack accuracy
Skill with weapon groups
Skill with specific weapons
Overall parry skill
Overall dodge skill
List of stances known
Equipped weapon, armor, and selected stance
I'm thinking that the skills/attributes would be purchased using skill points gained from experience or leveling. However, I think stances should be learnable from trainers (basically stores) or in some cases quests.
Now, when I said weapon, I actually meant the combination of whatever the character is weilding in both hands. It might be a two-handed weapon, two weapons, or a weapon and shield. Any given stance is only useable with one of those combinations, though there might be multiple versions of a stance that work for different combinations. Two weapon stances would probably have the most variety of attack vectors and would be able to parry most directions. However, they would have severe penalties to parrying attacks from heavy weapons (especially two-handed weapons). Two-handed weapons would have limited attack vectors from any given stance, but would do lots of extra damage and as mentioned before, get a bonus against parrying with with light weapons. Weapon+shield would have great parrying capability against almost any type or vector of attack, but would have poor offensive capabilities.
-
Peijen
- Minion to the Exalted Pooh-Bah
- Posts: 2790
- Joined: Fri Jul 18, 2003 2:28 pm
- Location: Irvine, CA
That's a pretty interesting idea. Have you ever played bushido blade from square? Your description reminded about that game. (if you play as one of the 'light' character you can't lift sledgehammer above your head hehe) I think you system would work every well for a single player game. If I ever finish the mud, you could probably implement the system on top of what I build.
Multiple attackers:
The attack vector concept generalizes to multiple attackers well since it already supports the idea of flank and rear attacks. Armor deflection also works well, since it only affects the attacker's animation without interfering with the defender's activity.
The problems are parry, dodge, and the round alternation. I have a sort of solution that might or might not work.
Every character has an additional state: prefer offense or defense. This could be a property of the stance or it might be independently settable. When a character is attacked from the front arc (i.e., they could dodge or parry), and they are not currently in the middle of their own attack, the parry or dodge as normal. If they are in the middle of an attack and they prefer defense, the attack is aborted and they parry or dodge as normal (if they fail to parry or dodge, their attack is still aborted). If they prefer offense, then no parry or dodge attempt is made and the attack is resolved just like a rear attack. The defender's own attack continues as normal, even if they take damage.
The attack vector concept generalizes to multiple attackers well since it already supports the idea of flank and rear attacks. Armor deflection also works well, since it only affects the attacker's animation without interfering with the defender's activity.
The problems are parry, dodge, and the round alternation. I have a sort of solution that might or might not work.
Every character has an additional state: prefer offense or defense. This could be a property of the stance or it might be independently settable. When a character is attacked from the front arc (i.e., they could dodge or parry), and they are not currently in the middle of their own attack, the parry or dodge as normal. If they are in the middle of an attack and they prefer defense, the attack is aborted and they parry or dodge as normal (if they fail to parry or dodge, their attack is still aborted). If they prefer offense, then no parry or dodge attempt is made and the attack is resolved just like a rear attack. The defender's own attack continues as normal, even if they take damage.
I was at work when I saw Peijen's attack resolution equation. I started thinking about how to extend it almost immediately, and it's just been percolating in the back of my head until now. I knew if I didn't write it down, I'd just keep thinking about it.Jason wrote:damn, I wish I had this kind of time.
I never played Bushido Blade, but I saw some of you playing it. Hopefully in an RPG, you'd be able to take more than one hit.Peijen wrote:That's a pretty interesting idea. Have you ever played bushido blade from square? Your description reminded about that game. (if you play as one of the 'light' character you can't lift sledgehammer above your head hehe) I think you system would work every well for a single player game. If I ever finish the mud, you could probably implement the system on top of what I build.
In a MUD, the multiple participant problem wouldn't be as severe since there aren't animations to worry about. Actually, in a pure text system, this would be pretty straightforward to implement.
I have more ideas regarding creatures using stances, ranged attacks, magic, command queueing, and probably other stuff that I've forgotten, but I guess I'll give up for tonight.
-
Peijen
- Minion to the Exalted Pooh-Bah
- Posts: 2790
- Joined: Fri Jul 18, 2003 2:28 pm
- Location: Irvine, CA
Regardless what Jason said I think you should write them down next time you have them!!George wrote:I have more ideas regarding creatures using stances, ranged attacks, magic, command queueing, and probably other stuff that I've forgotten, but I guess I'll give up for tonight.
You are probably right that it might not be that intensive in mud. We will see, part of the reason I am make a mud is to test out different ideas.
-
Jonathan
- Grand Pooh-Bah
- Posts: 6722
- Joined: Tue Sep 19, 2006 8:45 pm
- Location: Portland, OR
- Contact:
Since we're creating speculative combat systems, here's my contribution: more realistic game damage. Note that it is not realistic, just more realistic.
First off, standard D&D conventions apply. Use HP. At 0 char is incapacitated, at 1 char is at full ability. However, HP does not go up with level. Every char gets a certain amount at creation based on Constitution. Call base HP 100.
Regular hit does a few damage. Critical hit does approx 50-100. Critical hit chance is based on comparison between opponent's skill and your skill. With large level discrepancy, higher level scores lots of crits and low level does not. At same level, crit % is at some baseline.
I don't necessarily think this is more fun, but I like to kick around ideas to balance out D&D damage since higher levels completely own in falls, poisons, and other non-combatty things.
First off, standard D&D conventions apply. Use HP. At 0 char is incapacitated, at 1 char is at full ability. However, HP does not go up with level. Every char gets a certain amount at creation based on Constitution. Call base HP 100.
Regular hit does a few damage. Critical hit does approx 50-100. Critical hit chance is based on comparison between opponent's skill and your skill. With large level discrepancy, higher level scores lots of crits and low level does not. At same level, crit % is at some baseline.
I don't necessarily think this is more fun, but I like to kick around ideas to balance out D&D damage since higher levels completely own in falls, poisons, and other non-combatty things.
There have been similar ideas suggested before. WotC put one in Unearthed Arcana. However, any such system would be statistically far more lethal. For a tabletop RPG, you don't actually fight that many battles, so it might be survivable. For a CRPG, it's unuseable though. You'll probably fight a hundred or more versions of every monster. Even if the critical chance is only 1%, one of them is going to inflict it, regardless of relative levels and strategy. It's not fun dying every other battle because some low level creature got lucky.
As of DND 3.0, poison no longer deals HP damage, but rather ability score damage.
However, critical hits aside, a fixed HP number might be useable. Rather than boost the HP with each level, have higher levels (or better equipment) reduce the damage dealt. So even if a 20th level character still has only 100 HP, they can still have nothing to fear from a group of kobolds. I'll need to think this over further.
As of DND 3.0, poison no longer deals HP damage, but rather ability score damage.
However, critical hits aside, a fixed HP number might be useable. Rather than boost the HP with each level, have higher levels (or better equipment) reduce the damage dealt. So even if a 20th level character still has only 100 HP, they can still have nothing to fear from a group of kobolds. I'll need to think this over further.
I feel like I just beat a kitten to death... with a bag of puppies.
Hmm... if I make each weapon/stance's animation (or attack timer in a MUD) depend on the weapon, a heavier weapon will spend more time commited to an attack and will have less idle time to parry (unless preferring defense). I could also make the "return to ready" animations take a variable amount of time, so a rapier wielder could get back to en-guarde (and ready to parry or attack) very quickly after parrying or attacking, while a maul wielder would spend more time in an unavailable state/animation. This is interesting, but two-handed weapons are going to have to have huge damage levels to balance out all the disadvantages.Dwindlehop wrote:Group combat: use independent timers for each weapon (and armor and attribute). Fact is you can parry a lot fewer attacks per minute with a maul than with a rapier.
Ok, it's begun. I created a directory in the SVN repository to hold my work on the SBC engine (worst name ever). I've started to organize my ideas in a concept document, since I've found that writing out the design forces me to think through things that would otherwise bite me in the ass later. For those who want to see the work in progress, see SBC/Design/Concept.doc in the repository.
List of near term goals:
List of near term goals:
- Choose a programming language (Does this have to be done in C# or can I use C++?)
Create prototypes of the entity, weapon, stance, armor, and interaction classes
Create a test driver that creates two kobolds and arms them with sledgehammers
Subclass the "attack" interaction object.
Create a method/function to generate an attack interaction from an entity.
Create a method/function to resolve the attack interaction on a given entity by simply assigning damage (no dodge, parry, or block).
Extend the test driver to take turns generating attacks from each kobold and resolving them on the other kobold.
Be entertained by kobolds whaling on each other with sledgehammers.
-
Peijen
- Minion to the Exalted Pooh-Bah
- Posts: 2790
- Joined: Fri Jul 18, 2003 2:28 pm
- Location: Irvine, CA
If you would like to integrate C# could probably be easier, but we can convert C++ to C# pretty easily (or I hope). I say whatever gets the work done.
I am thinking about location based attack feats right now, but if are going to do that for your framework I might wait a little.
Actually, how about you do it in C# and extend the Game.Framework library. Part of the reason I am doing this is to test out different implementation of things. Modify the interface as you need, if I don't use it I will just put a do nothing function in place. Learn a new programming language!!
I am thinking about location based attack feats right now, but if are going to do that for your framework I might wait a little.
Actually, how about you do it in C# and extend the Game.Framework library. Part of the reason I am doing this is to test out different implementation of things. Modify the interface as you need, if I don't use it I will just put a do nothing function in place. Learn a new programming language!!
-
Peijen
- Minion to the Exalted Pooh-Bah
- Posts: 2790
- Joined: Fri Jul 18, 2003 2:28 pm
- Location: Irvine, CA
Damn, your document is certainly more interesting then mine. I think our system are not that much different. I like where this is going, this would be interesting.
Also you stole the parry magic idea from me!!
Also you stole the parry magic idea from me!!
I am not against this idea, put out some example.I still think strength should just be another skill, not attribute. Same with general accuracy (Dex), spell power (Int/Wis/Cha/whatever).
Ok, I will tentatively plan to do it in C# (using the original Visual Studio .NET). The only .NET functions I plan to use at this point are the XML serialization and (for testing) console output, so I hope that means my code will run under Mono without me actually having to test it.
At some point, I'll think through exactly what I need CMUd to provide besides I/O routing and persistant storage. I'm sure you have some plans for the architecture of the main game loop. Hopefully it will match what I need. I doubt there will be any similarities between our entity (damn it, I'm calling it an entity, not a creature), weapon, or armor class implementations since my system has a lot of factors you don't use.
I did notice you've been thinking about towns, guilds, and other non-combat stuff. I suspect I'll probably just inherit all of that functionality from you and not worry about it myself. I think I'll add a Purchasable interface so that all stores, auctions, transfers, etc, can be implemented generically to handle equipment for both systems. I'll probably use that interface for spells, spell elements, and stances as well as equipment since at least some of those will be buyable from a store in my system.
At some point, I'll think through exactly what I need CMUd to provide besides I/O routing and persistant storage. I'm sure you have some plans for the architecture of the main game loop. Hopefully it will match what I need. I doubt there will be any similarities between our entity (damn it, I'm calling it an entity, not a creature), weapon, or armor class implementations since my system has a lot of factors you don't use.
I did notice you've been thinking about towns, guilds, and other non-combat stuff. I suspect I'll probably just inherit all of that functionality from you and not worry about it myself. I think I'll add a Purchasable interface so that all stores, auctions, transfers, etc, can be implemented generically to handle equipment for both systems. I'll probably use that interface for spells, spell elements, and stances as well as equipment since at least some of those will be buyable from a store in my system.
I feel like I just beat a kitten to death... with a bag of puppies.
Hehe, I was just thinking that your documentation seemed a lot more extensive than mine, since mine only has two subsections actually complete. I like your idea of separating the ideas document from the actual working specs. I'll probably do that to mine tomorrow.Peijen wrote:Damn, your document is certainly more interesting then mine.
Just wait until my test driver is complete. Two kobolds with sledgehammers was a moderately cool idea, but I have a much, much better one now.Peijen wrote:I think our system are not that much different. I like where this is going, this would be interesting.
Could be. I didn't read most of the original MMORPG suggestion threads, but I might have come across your suggestion and just subconciously assimilated it.Peijen wrote:Also you stole the parry magic idea from me!!
I feel like I just beat a kitten to death... with a bag of puppies.
Yeah, I haven't really come up with any numbers yet, and haven't thought through what the non-combat effects are, but it seems to me that the difference between a character's inherent ability (like dexterity) and their training (skill) is purely conceptual, not mechanical. Mechanically, it doesn't have to matter whether you're good because you're nimble or well trained. My base weapon effectiveness equation is probably going to look something like :Peijen wrote:I am not against this idea, put out some example.I still think strength should just be another skill, not attribute. Same with general accuracy (Dex), spell power (Int/Wis/Cha/whatever).
(K1 + Dex + WeaponSkill + WeaponGroupSkill) * [K2 + Synergy(Stance, Weapon) * StanceSkill * MobilityPenalty(Stance, Armor)]
Where Kn is some as-yet undetermined constant. Note that the Dex "attribute" behaves identically to weapon skill and is just a more broadly applicable version of weapon skill. Disclaimer: Adds and multiplies may be replaced with other operations like exponentials or logs or whatever to make the statistics reasonable. More constants may be needed.
Similarly, for a spell's effectiveness, add the skill with the school (or style or element or something) to the Int "attribute".
I plan to not have character attributes in my system, but to instead have a couple skills like "Magical aptitude" (replaces Int or Spr or whatever), "Accuracy" (Dex), "Dodge" (Agi?). I'll probably also have a magic resistance skill to counter magic aptitude. I'm not sure where strength fits yet, but it will probably be purchased and displayed like any other skill. Same with Con.
I feel like I just beat a kitten to death... with a bag of puppies.