The King's Game: Modular Chess Platform

Overview

A three-module Maven project (Java 17 + JavaFX 21) that implements a complete chess platform: a desktop client with a cinematic animated menu, a pure-logic game engine supporting Standard Chess and Chess 960, and a TCP multiplayer server with authentication, matchmaking, and game persistence. The modules have strict dependency boundaries — core has zero external dependencies, and neither the client nor the server knows about the other.

I started this during my second year at university. It has gone through several major rewrites since then, most recently a full migration from Swing to JavaFX and an overhaul of the server into a persistent system with user accounts and session management. Today it also doubles as my testbench for agentic AI development workflows — I use it to evaluate how well spec-driven and test-driven approaches work on a real codebase.

Features

• ▸Local play for two players on the same machine
• ▸Online multiplayer with a TCP lobby, join codes, and automatic matchmaking
• ▸Standard Chess and Chess 960 rulesets, selectable per game
• ▸Pawn promotion with an interactive piece-selection dialog
• ▸Castling (king-side and queen-side) with move-history validation
• ▸6 visual themes — Midnight, Ember, Abyss (dark) and Manuscript, Fjord, Sakura (light)
• ▸English and German localization via ResourceBundle
• ▸Headless API mode for programmatic game control (nogui flag)
• ▸Server handles up to 40 concurrent games

Architecture

The project is split into three Maven modules with strict dependency rules:

Architecture rules enforced across all modules:

1. ▸core has zero dependencies on application or server. The client and server depend on core only, never on each other.
2. ▸All external interaction with the game engine goes through the Chess.java facade. Direct instantiation of Game subclasses from outside core is not allowed.
3. ▸UI components implement GameObserver and register via chess.addObserver(). No polling.
4. ▸core is pure logic — no UI imports, no JavaFX, no I/O.
5. ▸New rule variants implement the Ruleset interface. No branching inside Game for different rules.

Design patterns

Multiplayer server

The server accepts TCP connections on a configurable port (default 54321). Each client gets its own thread. Games run as isolated GameInstance sessions.

• ▸Up to 40 concurrent games (semaphore-limited)
• ▸Join codes: 12-character alphanumeric (XXXX-XXXX-XXXX), generated with SecureRandom, auto-expire after 10 minutes
• ▸Automatic matchmaking queue alongside manual join codes
• ▸User authentication with SQLite-backed persistence
• ▸Newline-delimited plain-text protocol
• ▸Automatic resignation on disconnect

Testing

75 test classes across all three modules:

As an AI development testbench

This project is also where I test agentic AI workflows. The codebase has enough complexity to be a real test (three modules, strict architecture rules, 75 test classes) but I can still iterate quickly. Experiments I've run:

• ▸Full UI migration from Swing to JavaFX, planned and executed through spec-driven agentic workflows using devline
• ▸Large-scale technical debt cleanup across all modules
• ▸Architectural restructuring to enforce module boundaries through AI-generated refactoring plans

Each experiment tests a different approach (spec-first, test-first, review loops) and I evaluate results against the architecture rules and test suite.

Tech stack