Reuse does not mean writing a generic system before understanding the problem. It means preserving a gameplay decision while controls, content, presentation and platform change around it.
The portfolio projects cover microphone, touch, keyboard, gamepad, local multiplayer, connected services, mobile and PC. The technology changes, but systems that survive share one principle: the central rule does not depend on one input method or one screen to exist.
Separate intent from device
Raw input answers “which button, gesture or frequency appeared?” Gameplay answers “which intention did the player express?” Mixing those questions makes every new platform contaminate rules that already work.
In Radgear, short swipes change the skater’s trajectory. In Resonance: The Lost Score, pitch ranges break, move and transform obstacles while keyboard or gamepad still handles movement. These are unusual interfaces, but both benefit from the same conceptual boundary:
- capture and normalize the signal;
- convert it into a stable intention;
- validate that intention against game state;
- execute the consequence;
- publish feedback for player and tools.
That sequence lets the team calibrate sensitivity, replace a device or block an action without spreading conditions across animation, UI and match rules.
Make state the source of truth
When several screens or players need to agree on a match, presentation cannot own the rule. It observes state, communicates possibilities and requests transitions.
In SLEIGHT, two asymmetric roles read the same mansion in opposite ways. Crowds, alarms, footprints, focus and cooldowns change what each player can hide or confirm. The system remains understandable because those tools participate in one round — time, roles and consequences — rather than operating as isolated visual effects.
In connected products, that boundary becomes even more important. CryptoFights combined combat, matchmaking, inventory and external services; DATA2073 connects battle, collection, tutorial, rewards, events and transactions. The more surfaces exist, the higher the cost of letting every screen rebuild its own version of state.
Treat feedback as part of the API
A gameplay system does not end when it changes a value. It ends when other participants can react to the change without knowing its internal implementation.
An important transition should expose enough information for:
- presentation to choose animation, audio or camera;
- interface to explain availability and blocking;
- tools to record sequence and context;
- networking or persistence to serialize only what matters;
- manual testing to reproduce the condition.
That does not require an event for every line of code. It requires clear contracts at points that matter to the experience: round started, objective completed, action denied, inventory updated, session interrupted.
Data should represent adjustable decisions
Moving numbers into a file does not make a system data-driven. The gain appears when designers and developers can change expected behavior without changing the structure of the rule.
Speed, duration, cost, pitch range, cooldown and content composition are good candidates when they vary between characters, levels or platforms. Scene references, service dependencies and control flow usually need more explicit boundaries.
A useful question is: “does this change represent balance/content, or does it change the nature of the system?” The first tends to be data. The second deserves code and architectural review.
Plan failures as valid states
Mobile loses focus. A controller disconnects. The microphone receives noise. A service slows down. A multiplayer session ends. If the system only knows the ideal path, the platform becomes a collection of exceptions.
Treat unavailability, waiting, reconnection, cancellation and resumption as named states. The UI can then explain what happened, gameplay can preserve what remains valid, and tools can distinguish a real error from an expected interruption.
This discipline also reduces coupling: recovery stops being an improvised reaction in every screen and becomes part of the system lifecycle.
Extract after the second variation
Before the first implementation, an abstraction describes a hypothesis. After the second real variation, it can describe a proven difference.
When adapting a system, observe what stayed the same and what had to change. Extract the stable boundary; keep the variation near the context that requires it. Healthy reuse does not eliminate particulars — it provides an explicit place for them.
The final test is simple: a new platform or rule should require a new edge implementation, not a chain of conditionals inside the core. When that happens, the system remains specific enough for the game and flexible enough for production.
