Inspiration

Chess creates depth from a small rule set, but traditional matches can demand memorized openings and long sessions. CHESS/RUPT asks a different question: what if familiar chess movement powered a fast arcade survival game where the board itself fights back?

What it does

CHESS/RUPT is a native iPhone and iPad game built around short, replayable tactical runs.

  • Daily Challenge gives every player the same deterministic scenario each day.
  • Crown Trials chains varied, escalating challenges into a survival streak.
  • Puzzle Mode offers a 999-level puzzle campaign plus a daily puzzle.
  • Free Play lets players combine modes, board layouts, timing rules, portals, power-ups, and piece effects.

The rules stay readable through chess movement, but each run can add collapsing floors, shrinking boards, portals, chain reactions, morphing pieces, rival territory, or survival goals.

How we built it

CHESS/RUPT is built natively with Swift, SwiftUI, SpriteKit, and GameKit. Deterministic seeds make daily challenges consistent across devices. A lightweight simulation harness evaluates generated challenges before release so difficulty can be tuned without requiring a server.

The interface uses a high-contrast pixel-art system: sharp edges, off-white and yellow UI panels, a black board, and motion cues that make hazards and enemy control legible on both iPhone and iPad.

Monetization

The game preserves a complete free experience:

  • free daily challenge and daily puzzle
  • three "free plays" for all other game modes, with limit resetting daily
  • leaderboards and achievements

A single non-consumable Unlimited Plays purchase, fulfilled through RevenueCat. This allows players to play endless challenges, puzzles, and arcade modes without the constraints of a daily three "free play" limit.

Challenges we ran into

The hardest problem was keeping dozens of interacting rules fair. A challenge that looks reasonable on a full board can become impossible on a smaller layout. Portals can create loops. A valid goal can still allow only one rigid solution. We addressed that by centralizing mode rules, validating spawns and portal paths, and using deterministic simulations to reject impossible or overly narrow challenge combinations.

What we learned

Our biggest lesson was that shipping required subtraction, not just more code. The prototype included online multiplayer, shareable replays, advertising, themed chess pieces, and several additional modes. One turned chess pieces into a soccer team. Another played like miniature golf, with a ball ricocheting off walls and traveling through portals. We also built modes about growing a zombie chess-horde ("Infection") and added golf-puzzles.

Each idea worked on its own, but every new feature had to behave correctly with every board shape, computer opponent, visual effect, tutorial, and special rule. The soccer mode alone needed sensible goal placement, ball collisions, bounces, team behavior, and fair starting positions on every possible board.

More importantly, several of these modes simply were not fun enough. Soccer was too unpredictable (where does a ball go if one chess piece collides with it and it bounces into a wall?), golf is too simple as a turned base game (you lose the highs of a hole in one), and infection just made the core gameplay loop easier (instead of 1 player vs. the board, it was 1+N players vs. the board).

We learned the same lesson from cosmetic pieces. Adding one art set sounded simple, but it had to look consistent during gameplay, on menus, in tutorials, and on scoreboards. Maintaining several separate presentations caused visual bugs to return after they had already been fixed. Removing the extra sets let us build one dependable presentation for the pieces that remained.

The second major lesson came from the Daily Challenge. Every player receives the same newly generated game each day, so the game has to create something that is possible, challenging, and fair without a designer checking it first.

Small combinations produced surprisingly large balance problems. One challenge gave the player a powerful rook against much slower kings and was almost effortless. Another combined a smaller board, disappearing tiles, and several opponents; it was technically possible, but almost no reasonable move survived the opening. Some challenges could be beaten only by finding one exact first move, which made them feel more like guessing than strategy.

To catch those problems, we built lightweight automated players that try each generated challenge in several different ways. Before a challenge is accepted, the system checks that the player can move safely, that at least one solution is found, that the goal is neither trivial nor nearly impossible, and that success does not depend on one rigid sequence. During a final 90-day test, the generator replaced 78 challenges after finding a better board or starting arrangement. The accepted set landed within our target of roughly 10–20% successful runs.

What's next

After launch, the same mode and challenge systems can support new boards and puzzle mechanics without weakening the core experience.

Built With

Share this project:

Updates