IAttackPotential

While attempting to sort out the Full Attack Budget issues (which I surfaced to priority while working on making UI for Choice Actions), I started refactoring IFullAttackBudget, which is implemented on action budget items that provide information during a full attack action. My refactoring led me to create IAttackPotential, and an emphasis on item slots (holding slots mostly, but also natural weapon slots) and weapon-heads rather than weapons as in the original implementation.

This seemed to work well for me through two-hand wielding, double-weapon wielding (with a few twists that I had to amend to my initial design), and natural weapon wielding (such as claws [potentially] in a holding slot).

Then I got to rapid shot. It is defined as providing an extra ranged attack, but for some reason I thought it only allowed an extra projectile weapon attack. The distinction is that a ranged attack can be a thrown weapon, and since I was focused on weapon-heads and item slots, holding a throwable dagger (or improvising a thrown anything else) would be blocked because the weapon head’s weapon wasn’t a projectile weapon.

And this will lead to a few further problems with my (new) current implementation…mainly I have to isolate any attack that uses rapid shot from sequence interference; that is, the extra attack should be at “full” attack bonus, not affected by iterative penalties, but affected by off-hand penalties. If the hand has run out of sequential attacks, the rapid-shot attack is still allowed.

Choices

I set myself on the task of implementing choice actions, and quickly came upon the “problem” of showing the choices when the action is no longer available. Solved with a LocalActionBudget “Choices” list that tracks the last choices for choice actions (for UI display and default when the choice action becomes available).

But this led me to full attack sequencing (especially with two-weapon and multi-weapon fighting), and all the problems with dropping, quick drawing, two-hand wielding, double weapon wielding, natural attacks, thrown, splatter and projectile weapons. Then trying to build a process to determine whether an attack is allowed, and what penalties apply.

I believe it will all come down to tracking “holding slots” rather than weapons or weapon heads.

Assume the first attack (as a regular action) is with a weapon wielded one handed, and the other hand is free (unarmed), wielding a shield, or wielding a weapon. Without two-weapon fighting turned on, only the one hand can attack, and possibly get multiple attacks if the base attack is high enough. If the weapon is dropped, a new one can be drawn (with quick draw) and continue attacking through the progression. This should be true whether the newly drawn weapon is one-handed, light, or two-handed.

Now assume two-weapon fighting is turned on when the first (regular) attack is made. The main hand attacks, the off-hand attacks, the combatant drops all weapons so that all hands are free, then draws a great-sword (two handed). If the base attack bonus is high enough for iterative attacks can the combatant make a second “main hand” attack even though the off-hand attack was used (assuming no improved or greater two-weapon fighting feats)? If the off-hand attack wasn’t used before drawing the great-sword, could the combatant then drop the great-sword, quick-draw a new weapon in the off-hand then continue with the off-hand attack?

So…not as easy as I first thought. Will take some noodling…

Home on the Ranged Target Cover

I had gotten to the point over the weekend where I was fairly comfortable with the final state of melee cover checks (with its weird alternate source points when attacking downward while standing on a ledge), and really began testing the ranged cover checks. What helped me in testing was adding the interaction alterations (for the attack interaction) to the status feedback so that the client could see cover and concealment affecting the attack. I’m going to need to examine the StepStatus a lot more closely to “pretty-up” the structure, and ensure that the right amount of information is sent to each client. I’m also going to need to put a facility to always send observed-activity info to various clients when an actor acts (right now, I only use ObservedActivityInfo when making an OpportunisticInquiry).

But anyway, back to ranged attacks. I noticed that a creature whose feet were blocked by only a small step was getting a lot of cover lines flagged (so that they could get a +4 cover bonus to armor-rating). I tried to compensate for this at first by proportionally moving the bottom points of the lowest cells upwards towards the top points, but this still kept them behind the step in certain cases.

Then, I planned to do some magic with checking the back-most low point(s) if the front-most low points were blocked. But I finally decided on boosting the low points upward again by an “absolute” amount relative to a fraction of the creature size (similar to how land movement has a maximum up-step size beyond which a climb check is needed, and representing the “bulk/core” of the creature’s body), rather than a fraction of the vector between low and high. If the low point boost is longer than the vector between low and high points, than the low point is simply omitted from the target corner set.

In the light amount of testing I performed, this seems like the best balance so far. But I’ll need more testing, and ultimately I need to vary the amount of low-point boost by creature body type, and whether the creature is prone or not.

(Slightly) Uphill Battle

Returning to the Ikosa Framework’s rules for cover; in addition to the special point identification mechanism for downward melee strikes, there are some special adjustments made to melee source corner points when melee attacks are made on the same level.

The main reason for adjustments to handle the cases when the source and target cell are on the same level, but the target is on a “slightly” higher step. In this case, the “front”-lower corner(s) of the source cell must go through the low step, creating cover. When attacking a target cell on the same level (based on cell-specific gravity), Ikosa adjusts the lower corners upward by 30% towards the upper corners on the same up-down edge. (It also adjusts the upper corners down 5%).

Currently these percent factors are hard-coded, but may likely be calculated by other factors in the future.

The “modeled” result is that a melee attack against a target on a platform less than 1.5 feet higher than the attacker does not automatically get penalized by cover.

(Note: when any component of a melee attack is upward or downward, these adjustments are not applied. Also, reach/ranged attacks originate from a single point, so there is no need to adjust source corners).

Covering Melee Corners

Traditional PnP tactical cover rules have some gray areas when it comes to complex 3-dimensional topography and large creatures. Mostly these are swept under the generalizations from the “flatness” of tradition PnP play. However, the Ikosa Framework must calculate cover within predictable constraints and more highly variable conditions.

For instance, melee cover (which can only occur when attacking into an adjacent cell) generally requires all “corners” of the source cell to have unhindered line of effect to the target cell. Assuming an attacking creature stands on a block of solid ground 5 foot higher than an adjacent target creature (such that the target creature is “diagonally-down” from the attacker), then lines from the back of the attacker must be blocked by the solid ground to attack the target; in exactly the same way as when attacking around a corner. It is unlikely that a game-master would rule the lower target had cover from the attacker standing on a higher platform, especially since attacking from higher ground typically gives a +1 to attack.

The Ikosa Framework has strategies to deal with this situation (and some processing optimizations).

Optimization first: When calculating cover (melee or reach/ranged) Ikosa must check lines between “corners” of the source (cell or point) and target (cell or cells) for terrain blockage or cover inducing effects in the cells being traversed by the lines.

To reduce processing, Ikosa only examines points that will reach from source to target without going through the source or target (thus culling certain points from consideration). This can be determined by looking at the relative integer cell coordinates between source and target cells to determine which faces are exposed to each other. When two cells are face to face, 4 points from the source and 4 points from the target are considered. When edge to edge, 6 and 6, and when corner to corner, 7 points each. Also, for reach/ranged attacks, there are additional target points possible (since for larger creatures the entire creature is being targeted, which spans many cells), but also additional culling (so that only points exposed to the source point) are considered.

For the downward attack mentioned above, Ikosa detects the gravity direction of the attacker and whether the terrain supports the attacker (thus creatures in flight above the surface are excluded from this test) and then excludes those faces from consideration if they would otherwise be needed. As a result, only attacker points that face-outward toward the target on the non gravitationally bound attacker face are used. In this case, only 4 points are considered (if the target is adjacent and down) or 6 (if target is diagonal and down).

If the attacker were in a cell 5 feet lower, however, the gravitationally bound face isn’t facing the target anyway, and since the all the target’s points are still usable, the higher target would have cover.