Project 33 / Physical

Atlas E-Paper Chessboard

A timeless game. An entirely different surface.

Concept artwork for Atlas E-Paper Chessboard
Studio concept artworkE-paper / Chess / ESP32
Project stageDesign development
Available to exploreEngineering study
Creative directionAPX Build

The idea

Create a quiet, readable chess device that supports a complete game, clear move entry and dependable recovery. V1 uses a commercially documented e-paper module and explicit touch or button input. It does not promise automatic recognition of physical pieces. The luxury furniture edition and additional games depend on validating this interaction first.

A timeless game. An entirely different surface.

The connection

Chess, e-paper and furniture design meet in an object intended to feel calm and permanent. The technical choices serve the experience of sitting down to play.

How it could work

01Player input
02Game state and display
03Quiet connected play

Split the system into display/input, authoritative game state and optional chess services. The ESP32-S3 can drive an appropriate display and input interface; run Stockfish on a suitable host for the first prototype rather than assuming a full desktop engine fits the microcontroller. Offline two-player chess remains usable if that host is absent.

Choose a panel by active dimensions, supported refresh modes, controller documentation, touch availability and price. A display's diagonal alone does not establish a comfortable chessboard. Divide its usable width and height by eight and test square size with fingers and pieces. Full refresh flicker, partial-refresh ghosting and touch-overlay parallax are product constraints to measure.

What would prove it

Display and play ten scripted games covering castling, promotion, en passant, checkmate, stalemate and undo in local mode. Interrupt power after selected moves. Test touches near all four corners and ask three people unfamiliar with the interface to make, cancel and confirm moves. Record input time separately from display refresh time.

Proposed gate: all scripted final positions match an independent reference; interrupted games resume without an extra move; users complete a five-move sequence without explanation after the initial instructions; displayed state never silently disagrees with saved state. Log actual panel latency and ghosting under its manufacturer's approved refresh cycle.

The path to a complete build

  1. Make a full-size paper interaction mock-up and choose screen dimensions.
  2. Implement local two-player chess with reliable save/resume.
  3. Benchmark the actual panel and input layer; document a refresh policy.
  4. Add engine-host play, then a separately tested online mode.
  5. Build the enclosure and perform a week of ordinary play before designing the furniture edition.
Open the engineering notebook

Components, interfaces and calculations

Prototype BOM: documented monochrome display/controller, ESP32-S3 development board, compatible touch layer or buttons, USB power, enclosure mock-up and an optional local engine host. Introduce a rechargeable battery only after measuring active, refresh and sleep power. Preserve a removable service panel and protect the screen from point loads.

The application owns a legal-move engine and serialised game state. Give each move an identifier; persist it before confirming success. On reconnect, reconcile against authoritative state instead of resending a move blindly. Online human play must use an appropriate supported board interface; keep engine assistance separate from human online games.

Scope and development questions

Allow 6–10 sessions after a suitable display is available. The screen and touch layer are likely procurement drivers; quote them as a pair with controller, shipping and replacement availability. Do not order a large premium panel until refresh behaviour is acceptable. Outstanding decisions: virtual versus physical pieces, battery requirement, minimum square size and whether offline computer play is mandatory.

Reference basis

This case study develops the project concept into a proposed build route. Numeric gates are design targets; completed hardware tests are not claimed.

From the notebook to the world

See a connection?
Let’s make it happen.