Pokémon Legends: Z-A: How One Battle Logic Supports Two Paces

Pokémon’s Battle Rules Were Already a Massive Systems Problem

Pokémon combat has spent decades accumulating exceptions. A move can change under weather, an Ability can interrupt it, a held item can modify the damage, a status can alter timing, and a field effect can keep working after the Pokémon that created it has left. The modern series has more than 1,000 Pokémon, 900 moves, 300 Abilities, and 200 items feeding into that same rules stack. Rebuilding that web from scratch whenever the battle presentation changes would be an engineering disaster.

Pokémon Legends: Z-A changes the pace rather than throwing away the logic. Battles run in real time: trainers and Pokémon reposition, attacks have wind-ups and active windows, and actions return on cooldown instead of waiting for a menu-driven turn order. Yet familiar Pokémon concepts — damage categories, status conditions, weather, switching, moves, Abilities, and items — still need to resolve consistently.

A CEDEC 2026 presentation from Game Freak’s Pokémon Battle System team describes the high-level answer: a shared battle-logic architecture built around Sections and an Event/EventHandler mechanism. The important lesson reaches beyond Pokémon. A game can support radically different combat pacing without splitting its combat rules into separate, increasingly incompatible codebases.

The Design Target: One Rules Library, Different Clocks

The clean separation is between three jobs that games often tangle together: what an effect does, when it is allowed to happen, and how the player sees it. Damage calculation and a burn chance belong to the first category. Turn order, a cooldown, or a 25-frame wind-up belong to the second. Animation, camera work, interface feedback, and sound belong to the third.

That division matters because real-time combat is mostly a timing problem. A classic turn-based attack can resolve once during a Resolution phase. Its real-time equivalent might start with a wind-up, create a hitbox for a brief active window, check whether a target is still in range, and then enter recovery and cooldown. The underlying effect can remain the same while the scheduler around it changes.

Combat concern	Turn-based expression	Pokémon Legends: Z-A-style expression	Shared rules requirement
Action timing	Action selection and priority/Speed resolution	Input availability, wind-up, active frames, recovery, cooldown	One move definition must expose timing data without duplicating its effect logic.
Attack delivery	Target chosen during resolution	Range, facing, area shape, projectile path, hit checks	Damage and secondary effects resolve through the same reusable handlers.
Status effects	End-of-turn checks or action restrictions	Continuous timers and altered cooldown behavior	Status rules need a common event hook rather than a mode-specific rewrite.
Field effects	Weather, terrain, entry, and switch triggers	Timed environmental ticks and spatial entry/exit triggers	Field state must remain independent of camera, UI, and battle pace.

Sections Turn “A Turn” Into a Flexible Timeline

The Section model is the temporal abstraction. Rather than wiring combat code directly to a global turn or directly to a real-time cooldown, battle state is partitioned into discrete logical windows called Sections. A Section establishes a span in which certain events are scheduled and certain constraints apply.

In a traditional Pokémon battle, a high-level turn can be represented by a Planning Section, a Resolution Section, and a Cleanup Section. Players choose commands during planning; actions resolve in priority and Speed order; weather, poison, and other end-of-turn effects process during cleanup. That is familiar territory.

In Legends: Z-A, the same abstraction can operate on much smaller slices of time. A Section can cover an attack wind-up, the moments a hitbox is live, a cooldown interval, a swap window, or an environmental tick. The engine does not need to decide that one is “real combat” and another is “turn combat.” It only needs to know which events may fire during the current Section and which conditions they require.

This is a deceptively useful piece of design. Consider a trap effect such as Toxic Spikes. In a classic battle, its trigger is naturally framed around an opposing Pokémon entering the field. In a spatial real-time battle, the equivalent rule can listen for a Pokémon entering a trap volume. The trigger differs; the poison application itself does not need a second identity.

Event Handlers Keep Moves From Becoming One-Off Scripts

Sections answer when battle logic gets evaluated. The Event/EventHandler layer answers what reacts when something occurs. Instead of treating Flamethrower, a burn-inducing Ability, a held item, and sunny weather as one giant bespoke script, the system can express them as modules subscribed to meaningful combat events.

Those events can cover player commands, move starts and completions, successful hits, damage application, status changes, knockouts, swapping, area entry, and weather ticks. A move can then carry a bundle of handlers: one launches its attack effect when the move executes; another checks for a secondary status effect after a confirmed hit; another responds to a relevant field condition. The move’s spatial profile and timing values sit alongside those effects rather than being fused into their logic.

The practical benefit is composability. A handler that applies a burn, modifies damage, or responds to weather does not need to care whether the player reached it through a turn queue or a cooldown timer. It receives the event context it needs — attacker, target, move parameters, current field state — and produces the appropriate result.

Priority Did Not Disappear; It Changed Shape

Real-time Pokémon battles can look like a break from the franchise’s old logic, but much of that logic has simply been translated into timing and spatial language. Priority becomes who can act first inside a contested window. Move commitment becomes wind-up and recovery. Accuracy and targeting become questions of distance, facing, projectile travel, and whether a target remains inside an active area of effect. End-of-turn pressure becomes periodic events over time.

This translation has consequences for players. Positioning matters because attacks occupy space and opponents can move. Timing matters because a cooldown-ready move is not automatically a safe move to use. The player still manages the familiar Pokémon toolkit, but each choice has an execution layer attached to it. A powerful attack can be a poor answer if its wind-up leaves the user exposed or its area fails to catch a moving target.

Why a Mode Adapter Is the Crucial Middle Layer

The shared engine still needs a mode adapter: a layer that converts the pacing rules of a specific battle format into Sections and scheduled events. In turn-based play, an input command can schedule move execution for a later Resolution Section once both sides have committed. In real-time play, that same input can attempt an immediate move start if the Pokémon is able to act and its cooldown is complete.

The distinction is substantial at the input level, but contained at the rules level. The move does not become “Turn-Based Flamethrower” and “Real-Time Flamethrower.” The adapter determines its timing pathway; the handlers determine the damage, targeting consequences, and secondary effects after it executes.

That containment also makes hybrid designs possible. A boss battle could use real-time movement and cooldowns during its opening phase, then switch into a structured duel after a stagger or scripted threshold. The player experiences a dramatic mechanical shift, while the game continues drawing from the same move, status, item, and environment library.

The Failure Point: Duplicating Effects by Mode

The architecture earns its keep by avoiding a familiar live-service and sequel-development trap: separate effect implementations for separate modes. The moment a team creates a “turn-based poison” class and a “real-time poison” class, every balance change and edge-case fix becomes two changes. Add weather modifiers, immunity checks, Ability interactions, item interactions, animation hooks, and field rules, and the divergence compounds fast.

Pokémon is especially vulnerable to this because its battle system is defined by interactions rather than isolated attacks. A move’s base power is the easy part. The difficult part is preserving all the modifiers, triggers, and exceptions that players expect to work everywhere. Separating effects from their time containers is the sensible way to protect that accumulated logic while giving a new game room to experiment with combat feel.

What Pokémon Legends: Z-A Demonstrates

Pokémon Legends: Z-A is useful as a combat-systems case study because it treats real-time battling as an alternative way to schedule established Pokémon logic. Cooldowns, timing windows, and live positional checks alter the rhythm of a fight. They do not require the franchise to abandon its move data, its interaction rules, or its immense archive of special cases.

For developers, the durable takeaway is less glamorous than a flashy combat trailer: build the clock separately from the effects. Sections provide the clock. Event handlers provide the effects. A mode adapter decides how an individual game asks those two layers to work together.