Practice III · Game / system / interaction design
Designing the rules, then making them readable.
Mechanics, progression, economies, encounters, world rules, interaction systems, visual direction, and the working implementation. The medium might be a persistent world event, a dependency editor, or a tarot table. Either way, the design has to describe the system truthfully.
- Game systems
- Mechanics · progression · economy · encounters · multiplayer · world rules
- Interface systems
- Interaction · visual direction · authoring tools · spatial and data-rich UI
- Outputs
- System specifications · briefs · prototypes · working interfaces · content models
- Delivery
- Cross-discipline direction · implementation · live iteration · accessible fallbacks
01 / Game and system design
Economy, encounters, progression, multiplayer.
The NDA-safe studies cover endgame economy, encounter ecology, cross-system progression, and emergent multiplayer. Each starts with player behaviour, then follows the consequences through rewards, content, production, and the wider world.
- PLACE
The environment supplies design inputs; it is not applied as a skin after the encounter exists.
- DEPENDENCY
Resources retain value outside the encounter, connecting repeat visits to a wider craft loop.
- DIRECTION
Reference sets and briefs translate the same ecology into world, creature, and asset work.
02 / Interface design
Three systems; three different spatial grammars.
These interfaces are not skinned versions of the same layout. Digital Carnival is a staged ritual, Journey is a dependency editor, and Athena is an operational surface. Their structure follows what the user needs to perceive and change.
Six identities become a radial tarot table, then expand through selection, poster, and reading states.
Branching content becomes a graph; script-shaped logic stays editable; import and validation keep the output portable.
Routes, memory, integrity, cost, tools, logs, and conversation remain inspectable at the same time.
03 / Shared design grammar
A good concept still has to work.
A mechanic has to explain access, consequence, reward, failure, and repetition. An interface has to explain focus, progress, latency, navigation, and return. In both cases, atmosphere supports the rules; it does not excuse them.
- LOOPMechanics live inside loops
Access, action, reward, repetition, and recovery are designed together. A mechanic is never only the button that starts it.
- ECONEconomy is consequence management
Scarcity, cost, reward choice, and repeatability all change the same supply. They have to be considered as one system.
- WORLDPlace changes play
Biome, resources, geography, and local behaviour create rules and dependencies. The atmosphere comes from those conditions.
- STATEState decides the shape
A node graph for dependency, a stage for ritual, a dashboard for concurrent operations, a ledger for markets.
- ATMAtmosphere carries information
Colour, depth, sound, and motion mark state changes and carry part of the interface.
- MODELTools expose the model
Editors and operator views make the real system legible instead of hiding it behind a friendlier but inaccurate metaphor.
04 / Implementation
The handoff is often the working build.
I design mechanics in system maps and specifications, then prototype interfaces inside the material when that is the shortest route to the truth: React state for interaction, CSS and typography for rhythm, WebGL and GLSL for atmosphere, and real data models for authoring tools. That makes feasibility visible early and keeps the final behaviour attached to the original idea.