This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle.
What if your chess opponent didn't just calculate moves, but actually noticed how you play?
What if moving your queen too early made your rival mock your overconfidence? What if playing defensively changed the way your opponent spoke to you?
That's the idea behind Checkmate Rogue, an open-source, AI-powered chess roguelike where every move leaves a memory, and every rival learns.
I wanted to build something different from another AI chatbot. Something people could actually play, enjoy, and potentially pay for.
So I combined a chess engine, roguelike progression, player-behavior analysis, and Google's open-weight Gemma model to create a game where opponents have more than just difficulty levels. They have personalities.
What I Built
Checkmate Rogue transforms traditional chess into a gothic, narrative-driven adventure.
Instead of playing isolated matches against an anonymous engine, players progress through a campaign of increasingly difficult rivals. Each encounter tests their strategy, while a separate AI system analyzes their playing habits and generates contextual dialogue.
The game includes:
- Three progressive rival encounters: Apprentice, Knight, and Boss, powered by Stockfish at different difficulty settings.
- Roguelike progression: A three-heart survival system makes each defeat meaningful.
- Strategic relics: Abilities such as Oracle's Debt, Fortress Pact, and Knight's Echo introduce tactical advantages and trade-offs.
- Behavior-aware rivals: The game detects patterns in player decisions and uses them to inform dialogue.
- Gemma-powered commentary: Rivals generate contextual observations, taunts, and strategic tips using Gemma 2 2B.
- Gemma Lab: A dedicated space for exploring the AI pipeline, evaluating responses, and understanding how the model behaves.
- Offline-friendly local inference: Gemma runs through Ollama, without requiring a paid language-model API.
Why build this?
Chess engines are excellent at calculating moves, but playing against them can feel impersonal.
I wanted to explore whether generative AI could make single-player chess more engaging without sacrificing the reliability of a traditional chess engine.
The key insight was that an AI rival doesn't need a language model to play chess. It needs a language model to make the experience of playing chess feel different.
Stockfish already handles the strategic calculations. Gemma adds personality, contextual feedback, and narrative tension.
Who would pay for it?
My initial target audience is casual chess players, beginners, and people who enjoy strategy games with progression systems.
The potential product is a free-to-play chess roguelike with optional paid expansions, such as additional rival campaigns, themed encounters, and new relic collections.
A possible business model would be:
Free: Core campaign, standard rivals, and basic progression.
Paid expansions: Additional story campaigns, new rival personalities, and themed content packs.
This is a proposed business model, not existing revenue. The current version is a playable prototype, and I haven't established willingness to pay yet.
My goal is to validate whether players enjoy behavior-aware rivals enough to return for another campaign.
Demo
The demo introduces the gameplay, campaign mechanics, AI-generated rival dialogue, and Gemma Lab.
A note about the live deployment: The public Render version supports gameplay and scripted rival dialogue, along with precomputed Gemma evaluation results. Live Gemma inference currently runs locally through Ollama and is demonstrated separately. The public website does not run live Gemma inference for visitors.
I made this distinction intentional rather than silently presenting scripted dialogue as live AI output.
Code
💻 GitHub: Pixie-19/Checkmate
The project is open source, including its game logic, campaign systems, AI integration, evaluation documentation, and deployment configuration.
Tech stack:
| Component | Technology |
|---|---|
| Frontend | React 19, TypeScript, Vite |
| Chess rules | chess.js |
| Chess engine | Stockfish 19 Lite, WebAssembly |
| Generative AI | Google Gemma 2 2B |
| Local inference | Ollama |
| Testing | Vitest |
| Deployment | Render |
The repository also includes documentation for the Gemma evaluation process and automated tests for the application's core logic.
How I Built It
The biggest technical decision was separating chess intelligence from generative intelligence.
I didn't want Gemma to invent chess moves, interpret rules incorrectly, or control the game's legal state.
Instead, I designed the application around three layers.
1. Stockfish handles chess. Gemma handles personality.
The chess engine runs using WebAssembly in a Web Worker, allowing it to calculate moves without blocking the main interface.
Meanwhile, chess.js validates legal moves and maintains the board state.
This means the game remains playable even when the generative AI model is unavailable.
Gemma has a different responsibility: generating character-driven dialogue based on the player's behavior.
2. A behavior analyzer gives Gemma grounded context
One of the problems with directly prompting a language model about a chess game is that it can invent details about the board.
To reduce that risk, I introduced a deterministic behavior-analysis layer.
The system examines player decisions and identifies meaningful patterns. Those observations are then used to construct the context passed to Gemma.
For example, if a player repeatedly exposes their queen early, the rival can respond with something like:
"Your queen seems eager for glory. Let's see whether your king shares her confidence."
That's an illustrative example, but it captures the experience I wanted to create.
The behavior analyzer identifies the pattern; Gemma turns it into personality.
3. Structured generation makes the AI more reliable
Gemma runs locally using Ollama with the gemma2:2b model.
Instead of requesting arbitrary free-form text, the application expects structured output with three fields:
{
"observation": "The player moved the queen early.",
"taunt": "Your queen is eager for glory.",
"tip": "Develop your minor pieces before exposing your queen."
}
This example illustrates the response schema.
The generated response is validated before being displayed.
I also added a timeout and deterministic scripted fallback. If Ollama is unavailable, inference takes too long, or the model returns an invalid response, gameplay continues.
The language model enhances the experience without becoming a single point of failure.
4. I built Gemma Lab to evaluate the model, not just showcase it
I didn't want to claim the AI worked well without examining its behavior.
So I built Gemma Lab, a guided demonstration and evaluation environment for the project's generative AI pipeline.
The evaluation covered 16 scenarios: 14 model-inference scenarios and two expected fallback scenarios.
Here are the results from my local evaluation:
| Metric | Result |
|---|---|
| Structured-response validity | 100% |
| Behavior grounding | 93.8% |
| Hallucination-free heuristic | 93.8% |
| Persona lexicon adherence | 100% |
| Average warm inference latency | 1,334 ms |
| Median warm inference latency | 1,284 ms |
These results come from project-specific evaluation heuristics. They are not universal model benchmarks, and the hallucination-free score does not guarantee factual correctness in every chess position.
The evaluation also highlighted a practical limitation: local cold starts can be noticeably slower than warm inference.
I documented the evaluation process in the repository so others can inspect and improve it.
5. I tested the systems independently
The project has 111 passing automated tests across six test suites in the latest completed local verification.
Both the standard production build and hosted build passed, and linting completed without warnings or errors.
The most important reliability decision was keeping deterministic gameplay independent of generative AI.
A model failure should never make a legal chess match impossible to finish.
Why Does Open Innovation Matter?
Open innovation isn't just a licensing choice for Checkmate Rogue. It directly influences the product's architecture.
First, local inference makes experimentation accessible.
Running Gemma through Ollama allows me to experiment with model prompts, response validation, and rival personalities without paying for every generated response.
There is still a hardware and electricity cost, but no per-request hosted-model API fee for local inference.
Second, player behavior can remain on the player's machine.
Chess move history and behavioral observations can be processed locally instead of being sent to an external language-model provider.
For a game that learns from how someone plays, local processing is a useful privacy-preserving design option.
Third, open models make the system adaptable.
I can experiment with different prompts, compare model behavior, replace the inference backend, and evaluate new open-weight models without redesigning the entire chess engine.
Fourth, the community can inspect the implementation.
Developers can examine how player behavior is detected, how prompts are constructed, how model responses are validated, and how the application handles inference failures.
That transparency matters because generative AI can produce convincing but incorrect responses.
Open code makes it easier to identify weaknesses and improve the system collaboratively.
For this project, the biggest advantage over a closed-only API approach is the freedom to run and evaluate the model locally while keeping the game's core logic independent of the inference provider.
What I Learned
Building Checkmate Rogue taught me that adding an AI model is often the easiest part. Designing the surrounding system is harder.
A model can generate impressive dialogue, but that doesn't automatically make the game reliable or enjoyable.
I had to think about questions such as:
- What happens when the model invents information?
- How can dialogue remain consistent with a rival's personality?
- What happens when inference is unavailable?
- How can the game stay responsive while Stockfish calculates moves?
- How do I demonstrate that Gemma is doing meaningful work rather than simply generating decorative text?
My solution was to give each component a narrow responsibility and make the generative layer observable and replaceable.
The most useful lesson was that open-weight AI becomes much more interesting when it is embedded inside a real interaction loop instead of being treated as the entire product.
What's Next?
Checkmate Rogue is still an early-stage project, and there is plenty of room to improve it.
I'd like to explore richer rival memory across matches, additional campaigns and relics, better position-aware strategic feedback, and eventually hosted open-weight inference so visitors can experience live generative dialogue directly.
Before expanding the feature set, though, my next priority is player feedback.
I want to understand whether behavior-aware dialogue actually makes chess more engaging, which parts of the campaign players enjoy, and whether anyone would pay for additional content.
Prize Categories
I'm entering:
Best Use of Gemma
Gemma 2 2B is the project's generative dialogue model. It powers behavior-aware rival commentary through local Ollama inference, with structured outputs, validation, fallback behavior, and a documented evaluation pipeline.
Best Use of Render
Render hosts the public Checkmate Rogue frontend and makes the playable game and precomputed Gemma Lab results accessible without local setup. Live model inference currently runs locally rather than on Render.
Checkmate Rogue started with a simple question:
What if your chess opponent could remember the way you play?
It became an experiment in combining deterministic game engines, roguelike design, player-behavior analysis, and open-weight generative AI into one interactive experience.
The game is still evolving, but the foundation is playable, open source, and ready for feedback.
Every move leaves a memory. Every rival learns.
Top comments (0)