Combat Mechanics: the nitty gritty

View previous topic View next topic Go down

Combat Mechanics: the nitty gritty

Post by AlexFricke on Thu May 07, 2015 7:25 pm

Discussion for the core gameplay experience and combat mechanics.
(This post should be edited and kept up to date with the latest concepts.)

Hitboxes and Hurtboxes
Hitboxes are a type of collider that attacks use to detect what they are colliding with. There are a few different types of hitboxes, and they carry a number of properties that help to define the attack, along with the attack's animation. A single attack can use one or more hitboxes, usually, but not always, of the same type and with the same properties.

Hurtboxes are the most important subtype of the hitbox. They are the opposite type of collider; they are what hitboxes are looking to collide with. When a hitbox collies with a hurtbox, the attack is considered a hit. Hurtboxes are what allow something to be attacked; without a hurtbox, damage will not be registered, and whatever other properties the attack has will not take effect.

Hitbox Types
Hitbox TypeDescription
OffensiveThe standard type of attacking hitbox.
DamageableThe standard type of damageable hitbox; AKA the hurtbox.
InvincibleAttacks connect with an Invincible hitbox, but damage, flinching, knockback, and all similar properties are ignored.
IntangibleIntangible hitboxes cannot be hit by attacks; a standard offensive hitbox will completely ignore an intangible hitbox. Dodging/rolling will use an intangible hitbox, and certain attacks might change their type to intangible during an attack.
ShieldA defensive hitbox that blocks all attacks except for unblockable attacks.
UnblockableAn attacking hitbox that, in addition to the standard offensive characteristics, also bypasses a shield hitbox.
Reflective(Optional) Similar to a shield hitbox, except instead of blocking the attack hitbox, bounces it back towards its source, but only if the attack hitbox has the reflectiveness property.


Hitbox Properties
PropertyDescription
Damage
The base damage dealt by the hitbox. This value is created from the character's strength and the weapon's damage.
Angle
The direction the target is knocked back.
Knockback
The measure of how far an attack sends its target away from their initial position.
Knockback GrowthDetermines how the hitbox's knockback scales with the character's strength stat. Default value is 0.0; some weapons/attacks will have a greater value, allowing the attack to knockback more with greater strength.
Status Effect
Determines if anything extra happens when the hitbox connects: NoEffect, burning, freeze, etc.
Shield Damage
Modifies the damage of the attack when the hitbox connects with a shield hitbox instead of a hurtbox.
Clang/PriorityWhen attacks clash and their priority is determined to be equal, this determines if the attack's hitbox is cancelled out or if the attack continues.
Sound Effect
The sound effect played when the attack hits.
Reflectiveness
Determines whether the hitbox can be reflected. Used for projectiles. (Only applicable if reflective hitboxes are used.)

Attack's Damage Calculation
STRbase + STRstat * STRgrowth + lerp(WpnDmgMin, WpnDmgMax, TimeCharged / MaxChargeTime)

Start-up Lag
Start-up lag (or windup) is the period of time between the player inputting a command and the move having an effect. In the case of an attack, it's the delay between the player's input and the creation of the attack's hitboxes. This delay is linked directly to the animation's anticipation period. Moves and attacks with low start-up lag are generally considered faster, as they give the enemy less opportunity to react.
Example: the movement of raising a sword from its neutral "held" position to the "start of swing" position. Once the swing begins, the start-up lag has finished, and the attack is in progress.

Ending Lag
Ending lag (sometimes referred to as cool down) is the delay between a move's effect finishing and another action being able to be taken. In the case of an attack, it's the delay between the dangerous part of the attack finishing, and the character returning to a neutral/idle position. This delay is linked directly to the animation's follow through period. Generally, actions with short start-up lag will have more ending lag, and vice versa.

Light and Heavy Attacks, and their Start-up and Ending Lag
The purpose of light attacks is generally to be able to react quickly to things, take advantage of timing windows, and put out constant harassment on the enemy. As such, light attacks generally have low start-up lag. In general, light attacks should probably have more ending lag than starting-lag. Presuming light attacks follow the 3 hit combo structure, the 3rd hit will probably be he most powerful and have the longest ending lag of the 3 attacks.
Heavy attacks are characterized by their longer start-up lag, both in the initial windup of the attack, and because the attack can be charged. The longer start-up lag allows them to be more easily punished, but also be devastating if not punished. The flexible/controllable timing window of the charge portion of the start-up lag allows the character performing the heavy attack to try to psych-out the enemy, as once the charge is released, the attack immediately executes.

Attacks on Shield
Q: How should attacks made on a shield/block affect the attacking character? Who gains the frame-advantage, the attacker or the defender? How does perfect shielding affect this?

Hit Stun/Recovery
Hit stun is the period of time after being hit by an attack that a character is unable to act. Essentially, the time it takes a character to recover from an attack. This time period may be affected by the type of the attack (light/heavy/charged), the weapon used, the character's Health stat (maybe as a secondary affect, Health reduces hit stun?), etc.

Shield/Block Stun
Character's can normally drop their shield/block almost instantaneously. However, when an attack connects with their shield, they may experience a delay before they can drop their shield or otherwise act. This delay should probably be dependent on the type of attack (light/heavy) hit their shield, and perhaps even the weapon that hit their shield. Perfect shielding may also affect the amount of shield stun a character experiences. Shield stun in important because it

Attack Priority
(Will probably need to rethink this.)
When two attack hitboxes collide, the attacks need to be resolved in some way. To resolve what happens, the damage of the two attack hitboxes are compared. If their damage values are far enough apart, the attack hitbox with the greater damage value out-prioritizes (overrides) the other attack, effectively cancelling out its hitbox.
If the attack hitboxes' damage values are within a certain range (say, within 10 damage of each other), the attacks "clang." Usually, this will result in both attacks cancelling out their hitbox. However, if the attack hitbox's clang property is set to false (default value is true), the attack will instead follow-through. The hitbox's properties will not be applied to the other hitbox, but the attack's hitboxes will not disappear and its animation will finish (presuming no other collisions).

Weight
(Only applicable if character models have different base stats. Likely overscoped/unneeded.)
Only used on hurtboxes. When an attack with knockback lands, the base knockback is multiplied by the hurtbox's knockback susceptibility. Default value is 1.0; greater values means the character will be pushed further than normal when affected by knockback, and vice versa with values below 1.0.

Character Properties
Property
Description
WeightDetermines how susceptible a character is to knockback. When an attack lands, the attack hitbox's knockback value is multiplied by the victim's weight. Default weight is 100; the greater the weight, the less the character is affected by knockback. The hitbox's knockback value is multiplied by the weightAdjust = (100 – weight + 100) / 100. At 100 weight, the weightAdjust is 1.0, higher weight values make weightAdjust less than 1.0 (reducing the knockback value), and lower weights make weightAdjust greater than 1.0 (increasing the knockback value).
Base Speed
The base speed value of the character, unadjusted from stats, movement impairing affects, buffs, etc.
Speed Stat
The number of points the player has invested in their character's speed stat. An integer ranging from 0 to MaxStatValue.
Speed Growth
A value that determines how much a character benefits from their speed stat. The higher the value, the more speed they benefit.
SpeedThe character's current speed value. Speed = (SPDbase + SPDstat * SPDgrowth) * SPDbuff * Slow. Slow is a status effect that reduces a character's speed, with a value less than 1.0.
Base Strength
The base strength of the character, unadjusted from stats, status effects, buffs, etc. Most characters have a base strength of 0.
Strength Stat
The number of points the player has invested in their character's strength stat. An integer ranging from 0 to MaxStatValue.
Strength Growth
A value that determines how much a character benefits from their strength stat. The higher the value, the more strength they benefit.
StrengthThe character's current strength value, derived from the character's other strength properties. Strength is used in the damage formula for weapon attacks. Strength = (STRbase + STRstat * STRgrowth) * STRbuff.
Base Magic
The base magic of the character, unadjusted from stats, buffs, etc.
Magic Stat
The number of points the player has invested in their character's magic stat. An integer ranging from 0 to MaxStatValue.
Magic Growth
MagicThe character's current magic value, derived from the character's other magic properties. Magic is used in the damage formula for magic attacks. Magic = (MAGbase + MAGstat * MAGgrowth) * MAGbuff.
Base Health
The base (starting) health of the character, unadjusted from stats, etc.
Health Stat
The number of points the player has invested in their character's health stat. An integer ranging from 0 to MaxStatValue.
Health Growth
HealthThe character's current max health value, derived from the character's other health properties. Health determines how much damage a character can take before they are defeated and lose a life. Health = HPbase + HPstat * HPgrowth
Base Mana
Mana Growth
ManaA derived character property that determines how large the character's mana pool is, and increases with the character's magic stat. Mana = MANAbase + MAGstat * MANAgrowth. Most characters have the same mana base and mana growth.

Weapon Attack Properties
PropertyDescription
AnimationThe animations to play for this attack.
HitboxesA data structure containing the hitboxes to create for the attack, including their hitbox type, properties, and local default position data for their placement in world space using the characters position and rotation.
Minimum DamageThe minimum amount of weapon damage this attack deals.
Maximum DamageThe maximum amount of weapon damage this attack deals. For light attacks, minimum and maximum weapon damage are equal.
Max Charge TimeThe maximum amount of time a heavy attack can be charged. Most weapons have the same heavy attack max charge time. (Light attacks, even though they cannot be charged, need a non-zero Max Charge Time to prevent division by zero in the damage calculation.)
Base Mana GainThe base amount of mana gained when the attack connects.
Mana Gain STR Modifier(Optional) Extra mana gained based off of the character's strength stat. Mana gained = BaseManaGain + ManaGainMod * STRstat

Weapon Properties
PropertyDescription
Light Attacks
A data structure to index through for each successive light attack.
Heavy Attack
The weapon's heavy attack.
Rolling Attack
The weapon's rolling attack
ModelThe model of the weapon.


Last edited by AlexFricke on Fri May 22, 2015 5:15 pm; edited 2 times in total

AlexFricke
Admin

Posts : 29
Join date : 2015-04-30

View user profile http://nogardgames.team-talk.net

Back to top Go down

Character Stats and Buffs / Debuffs

Post by Jeffrey Kumley on Mon May 18, 2015 1:19 pm

Typo?
I believe there is a typo (second SPDbase should be SPDstat?): Speed = (SPDbase + SPDbase * SPDgrowth) * SPDbuff * Slow

Buffs / Debuffs
Are there going to be different types (i.e. timed effects, effects that happen a certain number of times, permanent effects, status effects, area effects... etc.)? If so, which types? If not, how should they all behave? If a player receives multiple buffs of the same type / category, do they stack?

What about debuffs? Do we want to consolidate the two so that debuffs are just buffs with negative values?

Character stats
Health and mana are both unique from the other stats - Speed, Strength, and Magic - in that they can be "partially full". This was not addressed.

From an implementation point of view, we could have an accrued damage property, or a remaining health property. I would suggest that we go with a remaining health property. Then health could be treated similarly to mana (it doesn't really make sense to have an accrued lack of mana, but it does make sense to have a remaining mana property). These "partially full" stats would be reset to their calculated maximum every time the players' finish a level, correct?

Also, if I'm understanding this correctly, Mana derives its maximum value from its own base value and growth rate, but from the Magic stat upgrade value. Is that accurate?

Jeffrey Kumley

Posts : 3
Join date : 2015-05-12

View user profile

Back to top Go down

Re: Combat Mechanics: the nitty gritty

Post by AlexFricke on Mon May 18, 2015 6:34 pm

Yeah, typo in the Speed calculation.

Buffs/Debuffs: Don't know exactly yet. We need to sit down at some point soon and discuss spells, which will give us a better idea of what buffs/debuffs will look like. At a minimum, I'd say Strength, Speed and Magic can all be buffed (and debuffed as well, because it's just a negative buff), and the buff/debuff will be timed. (No permanent buff/debuff.)
Buff/debuff stacking: I don't know, but a status effect system would be in charge of that, I'd imagine.
Other status effects: Again, don't know exactly; will depend mostly on the spells we settle on. Some sort of damage-over-time seems likely though.

Character stats: Yeah, there should probably be a HealthCurrent and ManaCurrent, or something to that affect. Don't know if the data structure that stores these stats should also store these values, or it should be somewhere else. We need to have a data storage/serialization discussion soon, anyway, and we can talk more then.

Lastly, yes, Mana derives its stat scaling from the Magic stat. I have plans for the other primary stats to have secondary scaling effects as well, but they're not as hammered out yet. I'll post my thoughts on that soon, I'd love for some feedback on that as well.

AlexFricke
Admin

Posts : 29
Join date : 2015-04-30

View user profile http://nogardgames.team-talk.net

Back to top Go down

Thursday Meeting Whiteboard Summary / Annotation

Post by Jeffrey Kumley on Fri Jun 05, 2015 10:17 am

This seemed the best place to put the summary / annotation of the whiteboard from the Thursday meeting. If it needs to move or something, it can. I just figured most of this stuff -- if not all -- is on combat mechanics.


STUFF WE AGREED ON:

1. Nathan wants really cool evade attacks
2. Thomas wants sweep (wide) attacks and focused (narrow) attacks
3. Alex wants the "Go to" attack to be the sweep attack --> Amended: Double check after implementing
4. Alex wants all "attacks" to be block-able --> Amended: Need to be able to absorb 2 (or maybe up to 4) heavy attacks
5. Reese + Jeffrey want block to end when the player has no more energy
6. Perfect Blocking is a thing
7. AOE Perfect Block Knockback is a thing
8. Combos are a thing

OTHER THINGS ON THE BOARD:

Controls (Heavily endorsed by Reese, Alex, and I):
Shield LT + RT
Evade LB + RB
Focused 'Y'
Sweep 'X'
Magic 'B'
Sprint Press and hold 'A'
Interact Tap 'A'

Alternate controls 1 (Endorsed by Alex and I as viable):
Same as above except
Sweep Tap 'X'
Sprint 'A'
Interact Press and hold 'X'

Alternate controls 2 (Endorsed by me as viable):
Shield 'B'
Evade 'A'
Focused 'Y'
Sweep Tap 'X'
Magic RT + RB
Sprint LT + LB
Interact Press and hold 'X'

Power gauntlets:
Each of the player characters has a power gauntlet on their left bracer, which powers their energy shield. If you need a frame of reference, think lantern ring things in DC Comics.

Also, I continued my thoughts on power gauntlets after Reese, Alex, and I left, and if we also gave the enemies power gauntlets, then whenever an enemy dies, that could act as a reward for killing the enemy. The enemies’ power gauntlets could become sparkly thingamajigs, fly to the player who killed the enemies, and then give bonus energy and spell casting power to the player. This gives the players a visual representation of what the "energy" bar and the "spell casting power" bar mean. It also explains why these bars fill up during combat and why it allows the player to shield.

I haven't decided if I think the drop should automatically fly to the player who kills the enemy or whether it should be picked up like gold, because I have no preference. I think it might be some good variety to have it automatic. It would also empower Gandalf builds. However, it would also not provide the same co-optional teamwork that the gold does. It would also not actively encourage melee combat over spell casting (although it won't discourage it either).

ALL that aside... SPARKLY LIGHTS ON CHARACTERS AND EVERYWHERE!!! <3 Smile

Heavy attack:
Easily punishable.
Good for punishing long openings.

Evade:
Time based (I don't know what this is, but Reese wrote it up there I think)???
Does not use resources (Nathan wrote this).

Shield:
High strength attacks on shields lead to greater punishment by defender.
Perfect shield allows even greater punishment.
Perfect shield stuns light attacks and gives window for counter.
Perfect shield stuns heavy attacks while simultaneously stunning defender.

Energy:
Used for evade, shield, and sprint.
Regenerates over time.
Energy slowly depletes while shielding.
Blocking attacks with a shield depletes energy (higher strength attacks deplete more).
Blocking is not possible without energy.

Spell Power:
Used to empower spells (spells can be cast without spell power, but spell power increases the potency / level of spell).
Uses a point system.
Spells consume spell power points based on charge time.

Edge Cases:
Light and heavy attacks collide. What happens?

Jeffrey Kumley

Posts : 3
Join date : 2015-05-12

View user profile

Back to top Go down

Re: Combat Mechanics: the nitty gritty

Post by Sponsored content


Sponsored content


Back to top Go down

View previous topic View next topic Back to top

- Similar topics

 
Permissions in this forum:
You cannot reply to topics in this forum