System Design by LLM, Creative Design by Human: A Case Study in Game Development

System Design by LLM, Creative Design by Human: A Case Study in Game Development

The Game at a Glance

Chessfall Ascension is a strategy puzzle game built on classical chess movement rules — but placed inside a vertically falling world. The board continuously descends, and the player must guide one or more chess pieces upward while capturing all required flags before they fall out of view.

Each piece moves exactly as it would in chess, but the environment is dynamic. Some cells harden over time, some decay, some teleport pieces, some force directional movement, and others alter the speed of gravity itself. In advanced levels, players must coordinate multiple pieces, manage timed transformations, and even sacrifice pieces to progress.

The game is not about checkmate. It is about planning under pressure — making irreversible decisions in a system where space, time, and movement rules interact.

Special Tile Types in Chessfall Ascension

Barrier (Wooden Tile)

A solid obstacle that blocks movement and line-of-sight. It shapes paths and forces detours.

Hardening Cell (Empty → Solid)

An initially empty tile that becomes a Barrier after a short countdown, gradually closing available paths.

Decaying Barrier (Solid → Empty)

A solid tile that disappears after a countdown, temporarily opening new routes.

Wormgate (A/B Portal)

A paired teleportation tile. Entering one instantly transfers the piece to its linked partner.

Arrow Tile

Automatically shifts a piece in a specified direction upon entry, creating forced and often irreversible movement.

Sacrifice Tile

Removes a piece that enters it. Used strategically to reduce complexity or unlock progress.

Transmutation Tile

Transforms a piece into another chess type, changing its movement capabilities mid-level.

Slow Tile (Sc)

Reduces the board’s falling speed while occupied, allowing temporary control over time pressure.

Claim Tile (Pr)

Captures all visible objectives (flags) when activated, often serving as a final checkpoint mechanic.

Clock Tile (Timed Trigger)

Represents time-based mechanics that influence when certain events activate or expire.

To better understand the gameplay and see these mechanics in action, watch the following video:

Design Approach: LLM Vs Human

Enough of gameplay rules and mechanics — let us shift focus to the design and development journey behind the game.

For the initial detailed prompt and a handful of follow-up instructions, a coding agent powered by modern large language models (OpenAI and Claude) was able to generate a working version of the game surprisingly quickly. The agent produced functional gameplay, gravity logic, board rendering, and movement rules in a short span of iterations.

From a purely execution standpoint, this was impressive.

However, what became evident soon after was a structural pattern typical of agentic AI code generation: the model optimizes for working output, not for extensibility, modularity, clarity, or long-term maintainability. It jumps directly toward a potentially functional program, often intertwining logic and representation in ways that make future evolution harder.

This became especially visible in how the game board and levels were represented.

The Board Representation

At a glance, the level format appears simple. A world contains multiple levels, and each level contains parameters such as board dimensions, player pieces, flags, obstacles, and speed settings.

A simplified extract from a level file illustrates this structure:

{
  "id": 2,
  "name": "Mind the Gravity",
  "boardWidth": 8,
  "visibleRows": 6,
  "totalRows": 8,
  "fallSpeed": 50.0,
  "player": [...],
  "flags": [...],
  "cells": [...]
}

On-Disk Representation (JSON)

On disk, the board is not stored as a two-dimensional matrix. Instead, it is stored as a declarative description:

• `boardWidth`, `visibleRows`, and `totalRows` define the geometry of the board.
• `fallSpeed` defines the gravity parameter.
• `player` defines one or more pieces with type, color, and position.
• `flags` define objectives.
• `cells` define obstacles and specialized mechanics (Barrier, Steel, Wormgate, etc.).

This format is intentionally sparse. It does not store every tile explicitly. Only meaningful elements are described. Empty space is implicit.

From a storage perspective, this is efficient and readable. From a design perspective, it makes levels editable, portable, and generatable.

The game dynamics

The gameplay in Chessfall Ascension can operate in two modes:

1. Fixed Board Mode

A self-contained puzzle built from the available game elements.

1. Falling Board Mode

A vertically falling board where gravity continuously pressures the player.

Dynamic System Behavior

In both modes, the system is dynamic. Several game elements evolve over time:

• Hardening cells transform from empty to solid after a countdown.
• Decaying barriers disappear once their timer expires.
• Falling levels continuously shift the board downward.
• Reactive tiles respond to interaction events rather than remaining static.

These behaviors are not static properties of a grid — they are time-driven state transitions.

Initial LLM-Generated Architecture

In the initial implementation generated by the LLM, the runtime model handled updates in a monolithic manner.

On every tick of the game loop:

• The entire board state was recomputed.
• The whole board was re-rendered.
• Gravity shifts were applied globally.
• Counters were decremented collectively.
• Cell transitions were processed in one large update cycle.

Architectural Observation

While this approach produced the correct visual effect, it revealed a deeper architectural limitation.

The LLM did not model each game element as an independent entity with its own lifecycle and update logic.

Instead of designing self-contained, stateful components that update independently, it simulated dynamism by recalculating and redrawing the entire board on each tick.

Functional vs Architectural Reality

• Functionally: The system worked.
• Architecturally: The board was treated as a single mutable surface rather than a collection of interacting objects.

This distinction is subtle — but critically important when designing extensible and maintainable systems.

Design Principles: Independence, Hierarchy, and Modularity

Below I describe the concrete architectural choices used to make the game maintainable, extensible, and easy to reason about. The guiding idea is to treat the game as a small ecosystem of independent, interacting parts rather than a single monolithic state machine.

From Monolith to Ecosystem: The Refined Architecture

After analyzing the generated structure and refactoring the implementation inside the `lib/` folder, the architecture evolved into something fundamentally different from the initial LLM-produced monolithic loop.

The project now follows a layered, component-driven architecture with clear separation between:

• Rendering
• Game state
• Rules
• Level data
• Design tooling
• Runtime behavior

1. Layered Rendering Architecture

The board is no longer a single mutable surface. It is divided into conceptual layers:

• Board Layer
• Tile Layer
• Piece Layer
• Overlay Layer

Each layer is responsible only for its domain:

• The board layer handles spatial structure and grid positioning.
• The tile layer manages environmental mechanics.
• The piece layer manages chess pieces and movement.
• The overlay layer handles visual feedback and UI state.

This prevents unnecessary global redraws and reduces coupling.

------------------------------------------------------------------------

2. Component-Based Game Elements

Game elements are modeled as independent entities with lifecycles.

Pieces

Each chess piece encapsulates:

• Movement logic (delegated to the rule engine)
• Rendering
• Interaction hooks

Instead of recalculating the entire board, each piece updates

independently.

Tiles

Each tile type encapsulates:

• Internal timer logic (if applicable)
• Entry behavior
• State transitions
• Rendering updates

A hardening cell is not just a grid value --- it is an object with its

own countdown lifecycle.

------------------------------------------------------------------------

3. Rule Engine Separation

Chess movement logic is abstracted from rendering and state storage.

• Pieces request valid moves.
• The rule engine computes legal moves.
• The board validates against environmental constraints.

This allows extensibility without rewriting rendering logic.

------------------------------------------------------------------------

4. Explicit Game State Management

Game state is modeled explicitly rather than inferred from grid redraws.

GameState tracks:

• Board position
• Active pieces
• Remaining objectives
• Timers
• Gravity speed
• Win/loss conditions

State changes become intentional events rather than side effects.

------------------------------------------------------------------------

5. Event-Driven Interaction Model

An event emitter enables decoupled communication.

Instead of tightly coupling tiles and pieces:

• Events are emitted (e.g., piece entered tile).
• Subscribed systems react accordingly.

This allows features like teleportation, slow tiles, and claim tiles to

function without cross-layer entanglement.

------------------------------------------------------------------------

6. Declarative Level Loading

Levels are stored as sparse, declarative JSON.

Runtime flow:

1. JSON file
2. Parsed into structured models
3. Instantiation of tiles and pieces
4. Placement into layers

This keeps levels readable, editable, and scalable.

------------------------------------------------------------------------

7. Integrated Level Designer Tooling

The architecture includes validation and design utilities.

This allows:

• Safe level creation
• Structural validation
• Coordinate abstraction
• Repository-managed persistence

The system supports scalable content creation rather than one-off

prototypes.

------------------------------------------------------------------------

8. Time as a First-Class Concept

Time affects only components that require it:

• Timed tiles manage their own countdown.
• Gravity speed is state-driven.
• Slow tiles conditionally modify fall speed.

Time becomes a parameter influencing entities --- not a reason to

rebuild the world every tick.

------------------------------------------------------------------------

9. Platform Service Separation

Platform-specific services (such as audio) are abstracted.

Game logic remains independent from OS-specific implementations,

improving portability and maintainability.

------------------------------------------------------------------------

10. Architectural Summary

LLM Prototype Characteristics

• Global recomputation per tick
• Board treated as mutable canvas
• Logic and rendering intertwined

Human-Refined Architecture

• Independent entities
• Clear rule separation
• Explicit state management
• Layered rendering
• Event-driven communication
• Declarative levels
• Scalable tooling

------------------------------------------------------------------------

Final Insight

The board is no longer:

A 2D array that changes over time.

It is:

A living system of interacting components, each with its own

responsibility and lifecycle.

Functionality alone is not system design.

Extensibility, clarity, and independence are.

Lessons Learned: Designing with AI, Architecting as a Human

Building Chessfall Ascension using an LLM-assisted workflow was not just a technical experiment — it was an architectural education. Below are the key lessons that emerged from moving from AI-generated prototype to sustainable system design.

1. Working Code Is Not the Same as Good Architecture

Large language models are excellent at producing functional output.

They optimize for:

• Immediate correctness
• Visible behavior
• Passing the implicit “does it run?” test

But long-term systems demand something different:

• Clear separation of concerns
• Extensibility
• Replaceability
• Scalability

The first version of the game worked visually, but the board was treated as a single mutable canvas. That decision would have made future mechanics increasingly fragile.

Takeaway:

> “It works” is the beginning of engineering — not the end.

2. Recalculation Is Not the Same as Modeling

The monolithic tick-based update loop recalculated everything every frame.

It simulated dynamism by brute force.

However, simulation is not modeling.

Real modeling means:

• Hardening cells know when they should harden.
• Decaying barriers know when they should disappear.
• Slow tiles influence gravity without rewriting the world.
• Pieces request movement rather than hardcoding movement paths.

Once entities were given independent lifecycles, the system became predictable and composable.

Takeaway:

> Systems scale when behavior belongs to objects, not to a global loop.

3. Time Must Be Treated as a First-Class Concept

Time-driven mechanics are deceptively complex.

When time is treated as “just a loop tick,” logic becomes scattered and implicit.

When time becomes a parameter influencing entities, behavior becomes localized and controllable.

In Chessfall Ascension:

• Gravity is a state variable.
• Slow tiles conditionally modify that variable.
• Countdown-based tiles manage their own timers.

This shift reduces cognitive load and improves reasoning about state transitions.

Takeaway:

> Time should influence components — not rebuild the universe every frame.

4. Declarative Data Enables Creative Design

The sparse JSON level structure turned out to be one of the most powerful architectural choices.

Instead of storing full grid matrices:

• Only meaningful cells are declared.
• Geometry is parameterized.
• Mechanics are composable.

This enabled:

• Easy level editing
• Procedural potential
• Clean separation between data and runtime logic

Design became expressive without touching core code.

Takeaway:

> Declarative level design empowers designers without entangling engineers.

5. Separation of Rules from Rendering Is Non-Negotiable

Chess movement logic lives independently from rendering and state mutation.

This decision:

• Keeps movement pure and testable.
• Makes it possible to introduce new mechanics.
• Allows future custom rule variants.

If rules are intertwined with rendering logic, experimentation becomes dangerous.

Takeaway:

> Pure rule engines enable controlled innovation.

6. Event-Driven Architecture Reduces Coupling

Introducing an event emitter allowed tiles and pieces to communicate without tight coupling.

Instead of:

• A tile directly modifying piece internals
• A piece mutating board arrays

The system emits events and allows subscribers to respond.

This dramatically improves:

• Extensibility
• Feature isolation
• Debuggability

Takeaway:

> Events scale better than direct mutation.

7. LLMs Accelerate Execution, Not System Thinking

The AI was incredibly efficient at:

• Generating boilerplate
• Producing initial gameplay
• Translating abstract instructions into working code

But it did not:

• Enforce architectural discipline
• Predict future scaling needs
• Design for maintainability
• Create structural abstractions proactively

Human architectural reasoning was required to reshape the output into a system.

Takeaway:

> AI accelerates coding. Humans must design the system.

8. Architecture Is About Future You

The real test of architecture is not how fast you build version one.

It is how safely you can build version five.

By shifting to:

• Independent entities
• Layered rendering
• Explicit state management
• Modular rule engines
• Declarative data formats

The system became resilient to growth.

New mechanics can now be added without rewriting the core.

Takeaway:

> Good architecture protects your future iterations.

9. Creative Design and System Design Are Different Skills

The game concept — falling chess in a dynamic vertical world — is creative design.

The layered entity-based runtime model is system design.

One is imaginative.

The other is structural.

LLMs can assist with the former and accelerate the latter, but only disciplined architectural thinking ensures sustainability.

Takeaway:

> Creativity builds ideas. Architecture builds longevity.

Final Reflection

Chessfall Ascension demonstrates something important:

LLMs are extraordinary collaborators — but they are not architects.

They help you move fast.

They help you explore.

They help you prototype.

But when building systems that must evolve, scale, and remain understandable months later, deliberate architectural design remains a deeply human responsibility.

The real power lies not in choosing between AI and human reasoning —

but in knowing where each belongs.