Making Action Sprite Frames Hit on Time in Combat

Smooth animation playback does not equal a convincing combat presentation. What truly determines whether an attack feels impactful is whether all visible outcomes occur at the same causal moment.

From Character Concept Art to Animation Frames solved the asset production problem: how to obtain four addressable atlas types for idle, attack, hit, and fall-down states. Once assets are loaded, a more subtle problem emerges: the attacker has reached the contact frame, but the target hasn't been hit yet; numbers appear first, VFX lag by half a beat; if image loading is slightly slow, the character restarts from frame zero.

These phenomena are usually not caused by incorrect CSS animations, but by multiple clocks existing simultaneously in the system: atlases play at their own FPS, movement plays according to CSS duration, VFX appear via timers, and battle reports render immediately upon state updates. Each looks reasonable in isolation, but together they lack a common "now."

This article documents an event-driven combat presentation method. It does not require all action assets to have the same frame count or duration, but requires them to jointly adhere to a small time contract.

Separate Combat Results from Combat Presentation First

The combat kernel should calculate facts first, and the presentation layer should interpret these facts. A minimal event sequence could be:

Action  { at, actor, source }
Damage  { at, target, amount, critical }
Guard   { at, target, amount }
Recover { at, target, amount }
Defeat  { at, actor }

Events under the same at constitute a beat. The presentation layer derives from this beat:

• Who is the current actor;
• Which characters are targets, and who is the primary target;
• Whether the result is damage, guard, recovery, immunity, or positional change;
• Which type of action, hit VFX, and camera preset to use;
• Which text and values should appear at the contact point;
• What stable state to enter after this beat: return to idle, stay in fall-down final frame, or enter another stable state.

The most important invariant here is: the presentation layer only consumes established results; it does not submit damage backwards at the end of animation, nor does it guess gameplay conclusions from character names, image paths, or CSS classes.

This yields two direct benefits. First, skipping animation, switching to reduced motion preference, or losing page focus will not change combat results. Second, the same type of event can reuse the same presentation mapping across different combat scenarios, only replacing background, positioning, and camera.

Define Only Two Key Times per Beat

There is no need to design a complex cinematic timeline first. Most short combat actions only require two global quantities:

T_beat     Wall-clock duration of the entire beat
T_contact  The unified contact moment of this beat, 0 < T_contact < T_beat

For example, a beat is approximately 900 ms, and the contact point is around 420 ms. This is just an integer example for ease of understanding, not a universal parameter. It can be divided into:

Phase	Visible Content	Content That Should Not Appear Early
Wind-up	Camera push-in, attack preparation, target focus	Damage numbers, hit markers, result battle reports
Commit	Attacker approaches target along the combat axis	Hit posture after contact
Contact	Attack frame, hit frame, VFX, floating text all establish simultaneously	None
Settle	Recovery, fall-down, camera return	Premature return to idle

Unified duration does not mean all assets must be made to 900 ms. What truly needs unification is the semantic contact point.

Action Lists Save Semantic Frames, Not Guess Durations

Each non-looping atlas should declare several semantic cues in addition to frame count and FPS:

{
  "playback": {
    "frames": 24,
    "fps": 30,
    "loop": false,
    "end": "return-idle"
  },
  "cues": {
    "anticipationEnd": 7,
    "contact": 13,
    "recoverStart": 18
  }
}

contact is the most critical item. It should be annotated by someone who has seen the action, rather than simply taking the midpoint of the total frame count. The effective contact positions for sword swings, lunges, projectiles, hits, and fall-downs are not the same; after video frame extraction, the geometric midpoint has no reliable semantics.

The list should also validate:

• All cues fall within valid frame ranges;
• anticipationEnd <= contact <= recoverStart;
• Looping idle does not declare one-time contact cues;
• end clearly indicates returning to idle, staying, or hiding;
• The atlas actual dimensions match cells, rows, and columns exactly.

Without list validation, a damaged or old-format atlas can easily manifest as "sporadic rhythm issues," with troubleshooting costs far higher than rejecting it directly at load time.

Use Retiming to Compress Different Assets to the Same Contact Point

Let the action source contact frame be f_contact, and the source FPS be fps. Then the source time required for the source animation to reach the contact frame is:

S_contact = f_contact × 1000 / fps

If the atlas is advanced at runtime according to the following relationship:

source_elapsed = wall_elapsed × playback_rate

The attack action plays immediately from the start of the beat, and its rate can be taken as:

attack_rate = S_contact / T_contact

Thus, when the wall clock reaches T_contact, the source animation happens to reach S_contact. A long attack with a late contact will be appropriately accelerated; a short attack with an early contact will be slowed down. Assets retain their own frame counts and rhythms, aligning only at the common semantic point at runtime.

Hit and fall-down also need to satisfy two conditions simultaneously: the contact frame falls at T_contact, and the action end falls at T_beat. Let the source total duration be S_end:

reaction_rate = (S_end - S_contact) / (T_beat - T_contact)
start_delay   = T_contact - S_contact / reaction_rate

These two formulas map "source duration after contact" to "remaining beat length after contact," then reverse-calculate when the reaction action should start. The target can play a few pre-impact frames before the attack truly hits, but will not enter the hit posture too early; fall-down can also reach the final frame at the end of the beat.

Actual implementation should also set reasonable upper and lower bounds for the rate. If a certain asset must be accelerated or decelerated to an extreme degree to align, the problem likely lies in the action window or cue annotation; continuing to stretch will only disguise bad assets as runtime issues. When out of bounds, return to asset review, or degrade to a static pose.

A Beat Needs a Director, Not Multiple Components Guessing Targets Independently

The attacker, target, camera, VFX, and battle reports should all read from the same "director frame." The director frame is a pure derivative of the event sequence and does not save a second copy of the combat state:

DirectorFrame {
  beat_key,
  actor,
  targets,
  primary_target,
  source,
  motion_kind,
  impact_tone,
  critical,
  source_point,
  contact_points,
  camera_focus
}

This solves several types of problems that are difficult to eliminate through local patching:

• In multi-target attacks, the camera, VFX, and floating text have inconsistent understandings of the "primary target";
• Guards or immunities have no positive damage value, but are mistakenly judged as "no hit";
• Healing and movement actions reuse damage poses;
• Battle reports take the latest state, but character animation is still playing the previous beat.

When a new beat arrives, the presentation layer should use the latest revealed beat as the standard, cancel the old beat's presentation, rather than queuing to play back animations that are already outdated. Combat state is authoritative; animation is its projection at the current moment; especially after background tab recovery, do not block the latest state with seconds of playback backlog.

Final States Must Not Erase Immediate Causal Actions

This is a boundary condition that is easily missed in event presentations: a character triggers a counterattack during its own action and falls down within the same beat. In the state snapshot, its final health is already zero, but the causal order of this beat is still "it acted first, then received a response."

If components only select poses based on final health, the character will directly play the fall-down, and its own attack will vanish into thin air. The correct priority should be:

Current Beat Action Pose > Current Beat Target Reaction > Post-Beat Stable State

Therefore, the actor first fully expresses this beat's attack; after the beat ends, it transitions to fall-down based on the final state. Similar principles apply to same-beat healing, resurrection, transformation, and exit: the final DOM can immediately have correct data, but visible poses must preserve the minimal causal order.

Chase Current Frame for Late Resources, Do Not Replay from Start

Preloading can reduce latency, but cannot guarantee that images always arrive before animation. Network cache, image decoding, React commit order, and device performance can all cause atlases to arrive tens to hundreds of milliseconds late.

If the atlas records its own startedAt only when loading is complete, it will play from frame zero, while the camera, movement, and VFX are already halfway through. A more reliable approach is to let all one-time atlases read the same running beat clock:

elapsed = shared_beat_clock.current_time - start_delay
frame   = frame_at(elapsed, playback_rate)

The component calculates the current frame on the first draw after mounting. If the resource arrives after contact, it directly displays the pose corresponding to after contact; if the entire beat has ended, it completes directly and falls to the final state. Here, one cannot just "compensate for an initial offset once"; subsequent frames should also continue reading the common time source, otherwise browser scheduling jitter will still cause tracks to slowly drift apart.

Looping idle is an exception. It has no one-time beat start point, and can use an independent loop clock, giving a small phase and rate difference based on stable character ID to avoid the whole team breathing in sync like copy-paste.

Preload the Next Beat, Not Mount All Poses

The memory cost of large atlases is often masked by compressed file size. Before the browser draws, it needs to decode images into pixels. A rough budget is:

decoded_bytes = sheet_width × sheet_height × 4

For example, a 6×4 atlas composed of 1024×1024 cells occupies about 96 MiB after decoding. It may only be one or two MiB on disk, but if a character simultaneously mounts four atlases for idle, attack, hit, and fall-down, a single actor could occupy hundreds of MiB.

A more robust resource strategy is:

1. Actors only mount the atlas for the current pose;
2. The stage looks at the next unrevealed beat, only warming up the next actor's attack, one primary target's reaction, and corresponding VFX;
3. Identical list requests reuse the same loading Promise;
4. Cache records reference count, last used order, and decoded byte size;
5. Only evict resources with a reference count of zero, and set an LRU budget for idle resources;
6. When the preloader hands over resources to actors, defer eviction to the microtask after the current commit, to avoid clearing resources just after warming them up.

The budget object must be decode memory, not WebP file size. The latter is suitable for evaluating downloads, but cannot predict browser peak memory.

Reduced Motion Preference is a Stable Presentation, Not Setting Duration to Zero

If all animation durations are simply set to zero under prefers-reduced-motion, it often leaves semi-transparent layers, incorrect first frames, or empty fields without hit feedback. Reduced motion mode requires explicit static mapping:

• Standing and one-time non-fall-down actions display a stable first frame or equivalent static pose;
• Fall-down displays and holds the last frame;
• Characters stay at formation anchor points, without executing camera push/pull or dash;
• Hit VFX use static freeze frames;
• Result text and final values still appear completely;
• Animation completion callbacks settle presentation state immediately, preventing the interface from waiting forever.

Missing resources, list parsing failures, or image decoding failures should also follow this same static degradation path. Animation is an enhancement layer and should not become a single point of failure for combat readability.

Acceptance Checks Should Inspect Semantic Time Points

Just watching a complete recording, it is easy to let dozens of milliseconds of misalignment slide by based on overall feel. A more effective regression method is to enter the same deterministic combat beat in each test, pause the common time axis, and capture several semantic time points:

Checkpoint	Main Assertion
Initial	Characters, positioning, and final data are readable
Wind-up	Result text and hit VFX have not yet appeared
Approach	Attack and reaction atlases have not crossed the contact cue
Contact	Attack, reaction, VFX, floating text, and secondary battle reports are simultaneously visible
Settle	Characters have not jumped back to idle too early
Beat End	Camera returns, fall-down reaches final frame, final state is stable

Also cover separately:

• Melee movement actually approaches the target, but does not cross the combat axis;
• The target set and VFX positions for multi-target events are consistent;
• Actors still express their own actions first when falling down in the same beat;
• After intentionally delaying atlas loading, the first frame directly catches up to the current beat;
• No combat animations are still running in reduced motion mode;
• Static characters, values, and results are still understandable when atlases fail;
• After consecutive multiple beats, idle decode memory drops back within budget.

The value of such tests is not just in screenshots. It converts "feeling that hits are not solid enough" into a reproducible time contract: results cannot leak before contact, they must establish simultaneously at contact, and the correct final state must be entered at beat end.

Sound Clocks Still Need Separate Handling

Sound is easily mistaken as "just play when receiving the event." If combat events are revealed at the start of a beat, and sword sounds or hit sounds play immediately, they will still be a bit earlier than the visuals around T_contact.

For sound to truly synchronize, it must also read the same beat start point and schedule according to the contact point; when the page resumes, the audio context is not yet unlocked, or the contact point has already been missed, definitions for skipping or limited playback must be established. The visual timeline in this article does not automatically solve browser audio scheduling, so "consistent event source" cannot be written as "sound is already synchronized."

Minimal Implementation Checklist

• Combat kernel first produces typed events; presentation layer does not write gameplay results backwards;
• Each beat has only one T_beat and one T_contact;
• Non-looping atlases explicitly annotate anticipation, contact, and recover cues;
• Attack, hit, and fall-down are retimed via cues, without forcing unified source FPS;
• Camera, movement, atlases, VFX, and text read the same beat clock;
• Late resources chase frames according to the current beat, do not replay from frame zero;
• Current causal actions take priority over post-beat final poses;
• Only mount current atlas, perform reference counting and LRU based on decode size;
• Next beat only warms up the most likely needed attack, primary reaction, and VFX;
• Reduced motion preference and resource failures both have complete static presentation;
• Regression asserts at wind-up, approach, contact, settle, and final state respectively;
• If sound effects are integrated, sound must also obey the same contact clock.

Conclusion: Action Resources Truly Enter the Event System

A set of action frames only becomes combat presentation when, at runtime, it knows "who is acting, when contact happens, who the result affects, and what remains after the beat."

What is most worth preserving is not a 900 ms constant, but four invariants: events are the only source of truth, the contact point is the common semantic anchor, late resources follow the current clock, and final states do not erase immediate causality. As long as these four points are stable, action frame counts, model sources, VFX styles, and cameras can be gradually replaced without recreating multiple clocks that drift from each other.

Keywords: game development, combat animation, sprite frames, sprite sheet, event timeline, contact cue, animation synchronization, reduced motion, atlas preloading, decode memory