Audit of PCAM-24

A Phase-Centric Action Model for Deterministic Interactive Simulation

Executive Summary

PCAM-24 (Phase-Centric Action Model) is a proposed simulation model that replaces continuous time with a discrete phase cycle as the fundamental coordinate for game actions and interactions. Instead of reasoning in seconds or variable frame timings, PCAM-24 defines a fixed cycle of 24 integer phases (numbered 0 through 23) that repeat cyclically.

Overview of PCAM-24

PCAM-24 (Phase-Centric Action Model) is a proposed simulation model that replaces continuous time with a discrete phase cycle as the fundamental coordinate for game actions and interactions. Instead of reasoning in seconds or variable frame timings, PCAM-24 defines a fixed cycle of 24 integer phases (numbered 0 through 23) that repeat cyclically. All action progress, interaction checks, and synchronization between subsystems are tied to this phase value, not to wall-clock time or delta-timers.

Core Problems Addressed

The motivation for this shift is to address several longstanding problems in game simulation:

Problem 1: Desynchronization Between Animation and Gameplay

In many games, animations advance in time (seconds or frames) independently of gameplay logic, which can lead to mismatches. For example, a 25-frame attack animation might not align with the intended attack duration if the frame rate changes^1.

PCAM-24 Solution: Tying simulation logic to a fixed phase counter (like a virtual "semantic clock" shared by animation and gameplay) ensures that animation frames and gameplay state progress in lockstep, avoiding such inconsistencies^1.

Problem 2: Brittle Timing Logic Using Floats or Frame Counts

Traditional implementations often rely on floating-point timers or hard-coded frame intervals to manage action timings. Floating-point timing can introduce nondeterminism due to precision and rounding differences across systems[^2]. Even using frame counts can be brittle if different subsystems use different framerates.

PCAM-24 Solution: The discrete phase model enforces integer progression (no partial phases), eliminating floating-point drift and ensuring all machines see the exact same progression^1. In essence, phase is authoritative – it is the single source of truth for ordering and timing in the simulation.

Problem 3: Ambiguous Interaction Under Latency

In networked games, when two events happen nearly simultaneously, it can be ambiguous which one "wins" due to network delay or tick misalignment. Traditional models often resort to timestamp comparisons or favoring one client (introducing potential unfairness).

PCAM-24 Solution: Instead asks "what phase of the action are we in?" and uses that to resolve conflicts deterministically. By having all clients advance actions in the same discrete phase steps (with possibly an input delay or rollback scheme), the outcome of simultaneous interactions can be made consistent^5[^6].

Problem 4: Lack of Explainability/Debuggability

When outcomes depend on subtle timing differences or unsynchronized clocks, it's difficult for both developers and players to reason about why a certain outcome occurred.

PCAM-24 Solution: Discrete phase semantics make the game state more transparent. Every action is always in a well-defined phase and set of phase windows (like "invulnerable now" or "active now"), which can be surfaced in debugging tools or even shown to players^7.

Phase Space and Actions in PCAM-24

At the core of PCAM-24 is the concept of a fixed phase space divided into 24 discrete steps:

Phase Space Definition

Phase ∈ ℤ₍₂₄₎ = {0, 1, ..., 23}

Advancing in integer increments and wrapping around modulo 24

This design choice of 24 phases for a full cycle is a compromise between granularity and simplicity – it's fine-grained enough to represent different stages of an action, but small enough to be reasoned about as a repeating cycle.

Action Characteristics

Actions are the fundamental units of gameplay behavior in this model (e.g. an attack, a dodge roll, a parry, a reload action, etc.). Each action in PCAM-24 is characterized by:

Component	Description
Current Phase Value	0–23 representing its progress
Phase Progression Rule	Dictates how it advances through phases
Phase Windows	Named subsets of the 24 phases with special gameplay meaning
Transition Rules	Deterministic rules for changing into another action or state

Key Insight

Actions are not measured in seconds or real time – they progress through semantic stages defined by phase. For instance, instead of saying "this attack lasts 0.5 seconds and hits at 0.3 seconds," one would say "this attack goes through phases 0–23; the hit occurs during phases 8–10 (the Active window), and it ends on phase 23."

Phase Progression Properties

Phase progression in PCAM-24 is monotonic and discrete:

✅ Actions move forward only: 0→1→2...→23→0→...
❌ No backwards movement
❌ No fractional phases (never 7.5, only 7 or 8)
✅ Corrections via phase "snapping" when needed
✅ Explicit wrap-around behavior (23→0 means terminate, loop, or explicit state change)

This design has parallels in how classic game developers think in terms of frames. In many fighting games, an action (like a punch) is described by a sequence of frames: e.g. 5 frames startup, 3 frames active (can hit), 20 frames recovery. Those concepts map neatly onto PCAM-24's phases and windows[^9].

Phase Windows: Defining Gameplay Semantics

A phase window in PCAM-24 is a named subset of the 24-phase cycle that carries specific gameplay meaning. Essentially, it's a set of phase values during which a certain property holds true.

🗡️ ACTIVE Window

Phases during which an attack is capable of connecting/dealing damage. (Analogy: "active frames" in fighting game terms)

🛡️ INVULN Window

Phases during which a character or action cannot be hurt or interrupted by damage. Classic "invincibility frames" (i-frames)[^10].

⚔️ PARRY_PERFECT Window

Phases during which a parry move yields a perfect result. Often a very narrow window (1 phase) requiring skill.

🔄 RECOVERY Window

Phases during which the action is winding down or the character is committed and vulnerable (cannot act or cancel freely).

Formal Definition

Formally, each window is a subset W of the phase set {0,...,23}. An action can have multiple overlapping or distinct windows defined, and these windows drive all gameplay logic decisions.

PCAM-24 Axiom

"All authoritative gameplay decisions are reduced to window membership tests."

Instead of: if (time_since_attack_start < 0.3s and hit_detected) { deal damage }

PCAM uses: if (current_phase ∈ ACTIVE window of attack and hit_detected) { deal damage }

⚠️ Temporal Resolution Limit: The choice of 24 discrete phases inherently imposes a limit on temporal resolution. While sufficient for most action games, very fast actions or subtle timing differences might be challenging if confined to a window of just 1 phase (1/24th of a cycle). The system could be generalized to 48 or 60 phases if higher precision is needed.

Phase as Authoritative Coordinate and Determinism

PCAM-24 embraces a hard deterministic approach by elevating phase to the authoritative coordinate for all gameplay-relevant logic.

Core Axioms

Axiom	Description
1. Phase Governs Ordering	Every check that might use time is replaced by phase comparisons. No ambiguity due to clock differences or floating-point rounding[^7].
2. Discrete Semantics Only	All game logic must be expressible in terms of phase membership or transitions. No continuous timers allowed in authoritative logic[^7][^8].
3. Monotonic, No Rewind	Actions never go "back in time" in their local timeline. Corrections via phase snapping, not temporal reversal[^5].
4. Subsystems Subscribe	Animation, AI, VFX all follow phase—they don't drive it. Centralizes control of time progression to the phase clock.

Determinism Benefits

The determinism benefits of this approach are significant:

Integer-Based Logic: Since phase is an integer, the simulation behaves identically on any machine with the same input sequence^2
No Float Drift: Eliminates floating-point inconsistency across different CPUs or compilers[^2]
Perfect Reproducibility: The same inputs always produce the same outputs, enabling perfect replays^7
No Accumulation Errors: Two clients never drift apart over time – either they're in the same phase or not^8

Industry Recognition: The gaming industry has long recognized the perils of variable timesteps in deterministic simulations; using a fixed tick not only stabilizes physics but ensures reproducibility^7.

Action Lifecycles and Categories

PCAM-24 classifies actions by how they use the phase cycle in their lifecycle:

1. 💥 Impulse Actions

**One-and-done actions** (e.g., a quick melee attack or a single spell cast) - Start at phase 0 - Progress through 1, 2, …, up to 23 - Action terminates at phase 23 - Typical breakdown: Startup → Active → Recovery - Next execution creates a brand new cycle

2. 🔁 Sustained Actions

**Continuous actions** maintained by input (e.g., blocking, sprinting) - Loop through 24 phases repeatedly - Continue while condition is maintained (e.g., button held) - May have periodic effects or gaps in protection - Exit when input released or canceled - Wrap behavior: 23→0 with continuation, not termination

3. ⚡ Reactive Actions

**Short-lived with narrow success windows** (e.g., parry, counter) - Very small "perfect" window (often 1-3 phases) - Success: beneficial result if attack lands during window - Failure: extended recovery/vulnerability if whiff - Deterministic outcome based purely on phase alignment - Example: PARRY_PERFECT at phases 2-3, Recovery at 4-23

4. 🏃 Evasive Actions

**Maneuvers to evade attacks** (e.g., dodge rolls, teleports) - Typically implemented as impulse actions - INVULN window during middle phases - Startup phases: vulnerable, beginning movement - Mid phases: invulnerable - End phases: transition back to vulnerable - Movement tied to phase progression

Design Requirement

PCAM-24 demands that each action explicitly defines what happens at phase wrap (phase 23 → 0) for its lifecycle. This removes any guesswork about long actions or looping behavior.

Cancels, Transitions, and Buffering in Phase Terms

Competitive games often allow action cancels (interrupting one action to start another), combos, and buffered inputs. PCAM-24 incorporates these concepts with strict rules tied to phases:

Cancel Windows

**Definition:** Specific phase windows where an action can be interrupted to switch to a new action **Example:** An attack might allow a cancel into a special move only during phases 10–12 (right after it hits, representing a combo opportunity) **Traditional Parallel:** Fighting games specify certain frames as cancellable[^9] – PCAM-24 ensures this logic is expressed with phase numbers instead of raw frame indices **Benefit:** Deterministic and tool-visible – designers and players can see "move X can be canceled during phase Y"

Buffered Inputs

**Definition:** The game registers an input before the current action is ready to transition, then executes at the first valid moment **Implementation:** Store input if it occurs during phases leading up to a cancel window. Execute when cancel window opens. **Example:** Press next attack at phase 8, cancel window opens at phase 10 → input queued and executed at phase 10 **Network Benefit:** All clients handle identically because everything is deterministic and quantized[^5]

Deterministic Priority

**Challenge:** Multiple transitions possible at the same phase **Solution:** Explicit priority rules **Example:** If Attack→Dodge and Attack→Attack both possible at phase 10, define which wins (e.g., "Block checked before Dodge") **Outcome:** Given same scenario, result is always identical – no nondeterministic outcomes

What This Achieves

PCAM-24 replaces myriad ad-hoc conditions and magic numbers with a clear phase-driven scheme. It formalizes what fighting game designers have been doing for years with frame data and cancel rules[^9].

Interaction Adjudication and Fairness

One of the most critical aspects of game simulation is how interactions between entities are resolved. PCAM-24 mandates explicit interaction precedence rules based on phase and action state.

Canonical Ordering for Contested Interactions

⚖️ Priority Hierarchy

🏃 Evasion (INVULN) - Highest priority
⚔️ Perfect Defense (Parry) - Second priority
🛡️ Mitigating Defense (Block, Armor) - Third priority
💥 Hit (Full damage) - Default outcome

How It Works

Example Scenario: Attacker's hit lands at phase 8, defender's action is at phase 5

Check INVULN: Is defender's phase 5 in an INVULN window? → Yes? Attack misses (evasion wins)
Check PARRY_PERFECT: Is defender's phase 5 in PARRY_PERFECT window? → Yes? Attack parried (perfect defense)
Check BLOCK: Is defender in a BLOCK window? → Yes? Attack hits but mitigated (reduced damage)
Default: None of above? → Full hit registered

Fairness Through Determinism

By strictly ordering outcomes, PCAM-24 ensures that even in seemingly simultaneous situations, all machines and subsystems resolve identically. There is no race condition[^6].

Player Experience

Without PCAM-24	With PCAM-24
❌ "I swear I dodged that on my screen!"	✅ Both clients agree on exact phase → consistent outcome
❌ Outcomes feel random or laggy	✅ Outcomes are learnable and consistent
❌ Can't explain why something happened	✅ Clear: "You weren't in protected phase"

Real-World Example: For Honor uses a similar deterministic synchronous simulation to maintain fairness in complex melee fights[^6].

Networking Implications

One of the strongest practical arguments for a phase-centric model is how it simplifies deterministic networking and state synchronization across clients.

Network Benefits

📊 Minimal State Sync

Send only: Action ID + Phase value + start parameters

No need for continuous floating-point timestamps or sub-frame timing[^2][^5]

🔮 Client Prediction

Clients predict by advancing phase locally using deterministic rules

Corrections via phase snapping when discrepancies occur

🕐 No Time Reconstruction

Deal in phases and ticks, not milliseconds

Rollback = just rewind N phases and re-simulate

🎬 Deterministic Replays

Record input sequence → perfect replay offline

Useful for QA, debugging, and esports[^7]

⚡ Latency Tolerance

Framework supports both lockstep and rollback approaches

Small divergences auto-correct, large ones trigger correction[^5]

📉 Low Bandwidth

Share high-level events rather than full physics states

Similar to input-only networking in lockstep games[^2][^5]

Network Modes

Lockstep Mode:

- Delay input execution until all clients have input for same phase
- All clients simulate identically
- Input delay = latency, but perfect consistency

Rollback Mode:

- Allow immediate local input execution
- Rewind N phases and re-simulate when correction needed
- Low perceived latency, occasional visual corrections

Determinism by Design

Many developers have learned that making a game deterministic after the fact is hard if it wasn't designed for it^5. PCAM-24 is a determinism-by-design approach.

Caution

Physics and continuous movement are not fully dictated by PCAM-24. Character positions or physics objects might still need traditional interpolation and sync if not fully governed by phase logic. However, in many action games, character motion is tied closely to action state (e.g., during attack or dodge, movement is scripted), which can be integrated with phase.

Tooling and Explainability

The authors of PCAM-24 emphasize that such a system is only as good as its tooling support.

Proposed Development Tools

#### 🔍 Phase Inspector Real-time display of each entity's current action and phase

Entity: Player
Action: HeavyAttack
Phase: 17/24
Current Window: Recovery

#### 🎨 Window Highlighter Visualize which phase windows are currently active

✅ RECOVERY window (10–23): ACTIVE (phase 17)
❌ ACTIVE window (5–8): inactive
❌ INVULN window (2–4): inactive

#### 🔀 Transition Visualizer List pending transitions or buffered inputs

Buffered Input: Attack2
→ Queued, will execute at phase 12 when cancel window opens

#### 📝 Interaction Log When interactions occur, log phases and outcomes

[Frame 1234] Attack hit at phase 8
Defender: INVULN window active
→ Result: Attack whiffed (invuln)

#### ✏️ Authoring Tools Visual editor to define action timelines

Phase:  0  1  2  3  4  5  6  7  8  9  10 11 12 ... 23
        [Startup  ][  ACTIVE  ][    RECOVERY      ]
                   [CANCEL_OK]

Benefits of Tooling

✅ Timing bugs → State bugs Easier to reproduce and analyze	✅ Transparent to players Can surface frame data officially
✅ Data-driven design Paint windows on timeline, not code	✅ Validation built-in Tool can warn of conflicts/issues

Industry Parallel

Fighting game communities already manually create frame data tables^11[^12]. A game built on PCAM-24 could surface this data officially, making the game more analyzable and learnable.

Benefits and Implications of PCAM-24

By replacing time-centric simulation with phase-centric simulation, PCAM-24 offers several advantages:

Primary Benefits

#### ✅ 1. Consistency Across Systems All subsystems (animation, gameplay, AI, networking) share one "clock" (phase). Eliminates desync scenarios[^8]. #### ✅ 2. Determinism Given same inputs → exact same outcome on all machines. Crucial for peer-to-peer and replays[^2][^7]. #### ✅ 3. Explainability Outcomes decided by phase windows and explicit rules. Easy to explain "why" something happened. #### ✅ 4. Authorability Designers work with meaningful stages (startup, active, recovery) instead of microseconds. More intuitive[^9]. #### ✅ 5. Extensibility New systems hook into existing phase model without reinventing timing. Common language for all features.

Trade-offs and Limitations

What PCAM-24 Doesn't Do

❌ Doesn't replace low-level continuous physics systems
❌ Not suggesting to change engine tick loops (works on top)
❌ Not focused on performance optimization (focused on robustness)
❌ Doesn't solve design problems (designers still need to balance)
⚠️ May impose rigidity (actions must fit 24-phase template)

Comparison: Traditional vs PCAM-24

Aspect	Traditional Time-Based	PCAM-24 Phase-Based
Timing Coordinate	Seconds, milliseconds, variable frames	Discrete phases 0-23
Determinism	Float drift, platform differences	Perfect, integer-based
Subsystem Sync	Each system has own timeline	Single shared phase clock
Network Bandwidth	Timestamps, positions, velocities	Action ID + Phase only
Debuggability	"Heisenbug" timing issues	Explicit state inspection
Design Language	Magic numbers, scattered logic	Data-driven windows

Conclusion

🎯 The Paradigm Shift

PCAM-24 reframes the concept of time in interactive simulations from a question of "When did something happen?" to "What stage is the action in?"

By elevating discrete phase to a first-class primitive, it offers a unified semantic timeline that all parts of the game can follow. This model brings determinism, fairness, and explainability to the forefront by eliminating hidden timing inference and replacing it with explicit state-based logic.

The Core Problem

In traditional game development, different systems speak different "timing languages":

🎬 Animation frames
🤖 AI ticks
⚛️ Physics seconds
🌐 Network ping

Much of the engineering effort is spent translating between them and coping with mismatches.

The PCAM-24 Solution

One language for all: Phase

This drastically cuts down on uncertainty and complexity:

Networking doesn't transmit arbitrary timestamps – just phase counts^7
Players don't deal with unpredictable outcomes – rules act consistently
Developers get reproducible bugs and predictable design tweaks

Fundamental Change in Assumption

❌ Traditional Assumption

Underlying continuous clock

→ Build gameplay on top

→ Convert between systems

→ Handle desync constantly

✅ PCAM-24 Assumption

Underlying cyclic phase sequence

→ Everything built on phase grid

→ Single source of truth

→ Deterministic by design

Best-Fit Game Genres

PCAM-24 aligns particularly well with:

⚔️ Fighting games
🎮 Character action games
🏆 Competitive multiplayer games
🎯 Any game valuing deterministic fairness and explainable mechanics

Indeed, many of those games have unwittingly been doing something similar by manually counting frames; PCAM-24 formalizes and generalizes that approach.

Future Outlook

As networking and cross-platform play become ever more important, such deterministic models might very well become the standard approach under the hood, even if players remain blissfully unaware of the 24-phase dance orchestrating their game.

Final Assessment

PCAM-24 represents a compelling approach to simulation where "phase is law." It offers a path to simulations that are:

✅ Deterministic – No more one-in-a-million desync bugs
✅ Inspectable – State understood in human terms
✅ Intuitive – Actions have stages, not arbitrary durations

While not suitable for all game types (purely physics-driven or heavily continuous simulations), for its target domain—real-time interactive games with emphasis on fairness and clarity—it provides a robust foundation.

References

[^2]: Fiedler, G. (2014). Deterministic Lockstep. Gaffer On Games – on the challenges of float precision and the need for fixed-step determinism. gafferongames.com

[^6]: For Honor GDC Talk (2019). Deterministic Simulation in 'For Honor'. Highlights importance of deterministic architecture for fairness in melee action games. gdcvault.com

[^9]: Wagar, C. (2023). Frame Data Patterns that Game Designers Should Know. CritPoints – explains fighting game concepts like active frames, recovery, cancels. critpoints.net

[^10]: Gaming StackExchange (2014). What is an invincibility frame? Defines invincibility frames as periods during which a character cannot be damaged. gaming.stackexchange.com

[^12]: Facebook Gaming Community. Fighting Game Frame Data Discussion. Community analysis of frame data for competitive play. facebook.com

This audit was prepared as an independent analysis of the PCAM-24 specification and its implications for game development.