← Back to projects

Engineering case study

Flutter / Flame chess roguelike

Chess Mutator

A published single-player chess game that keeps the language of chess while changing the rules around the player.

00

Project overview

What this product is and where I contributed.

A published single-player chess game that keeps the language of chess while changing the rules around the player.

01

Problem & context

Make a familiar game ask unfamiliar questions.

Chess gives players a precise rule set. Chess Mutator uses that familiarity as its starting point, then introduces mutations that can change the value of a piece, a square, or an entire position. The product therefore has to feel understandable before it becomes surprising.

The public product is structured as a campaign-first, single-player experience. Its six-chapter campaign covers 60 levels, while the official product pages describe mutation-driven encounters and Normal or Expert AI modes.

02

Scope & ownership

A product owned from the game loop through release.

My recorded contribution covers the Flutter / Flame product, gameplay systems, mutation-driven progression, AI opponents, persistent player data, and the debugging and profiling work needed to keep the experience maintainable.

I also handled production release and maintenance workflows for Android and iOS. The case study stays at product and engineering level; private algorithms, services, and credentials are not published.

03

Architecture & decisions

Keep state, rules, progression, and platform delivery aligned.

Flutter and Flame provide the cross-platform game implementation. Supabase and Firebase are part of the recorded product stack for persistence and platform services. The important boundary is between the current board state, mutation rules, AI turns, campaign progression, and the data that must survive a session.

The design favors explicit game-state transitions and inspectable progression over hidden magic. That makes a rule-changing game easier to debug, balance, and extend without exposing private implementation details on a public portfolio.

04

Engineering challenges

The hard parts were interactions, not isolated screens.

Several systems have to agree before a move feels correct. The public-safe engineering summary is:

  • Mutation-aware rules had to change the tactical meaning of a position without losing the recognizable structure of chess.
  • Campaign levels, stars, quests, rewards, and achievements had to remain coherent as new mutation combinations were introduced.
  • AI responsiveness and debugging / profiling work mattered because a rule-changing opponent is only useful when its behavior remains understandable to the player.
  • Release work had to cover Android and iOS while ongoing fixes addressed match recovery, progression, quests, and stability.
05

Reliability & delivery

A published product is an ongoing engineering responsibility.

Chess Mutator is publicly available on Android and iOS, with Steam listed as coming soon. Public release notes document improvements around match recovery, progression, quests, AI responsiveness, achievements, and stability. No download, revenue, or performance number is claimed here.

06

Reflection

Design the rule change, then make it legible.

The strongest lesson from Chess Mutator is that novelty needs a stable frame. Players can accept a surprising rule when the product communicates the state clearly, preserves a reliable loop, and gives them a way to learn what changed.

07

Evidence & links

What can be checked publicly.