Just Chessing Around

steam game programming

A commercial roguelike chess game shipping on Steam. I built a custom grid engine in Unity, a chess engine with its own APIs on top of it, and the game systems on top of that.

Role Lead developer
Team 2 people
Tech Unity, C#, custom grid engine
Status Shipping on Steam

The short versionArchitecture first

problem

Two devs, many systems

A roguelike chess game has a lot of interacting rules. With a second developer in the codebase, one wrong dependency can create bugs that spread.

approach

Layers with hard boundaries

A grid engine at the base, a chess engine with APIs on top, and game systems built only through those APIs.

result

Safe to extend, reusable

New content slots in without touching the backend, and the grid engine is reusable in future projects.

Deep diveHow it's built

The layers

Grid engine tiles, pathfinding (A*)
→
Chess engine pieces, moves, public APIs
→
Game systems buffs, environments, AI
→
Unity front end views, camera, UI

Each layer only talks to the one below it through its API. Everything in the game interacts with the grid layer, which makes it an engine within an engine.

Just Chessing Around gameplay

Building the grid engine

Layered architecture. Separate layers of abstraction on top of the grid keep bugs contained.

Filling Unity's gaps. Working outside Unity's built-in tools meant building missing features myself.

Custom A*. The layered structure made it straightforward to slot pathfinding in.

Buff system

Buff.cs programming
// This class also has a few APIs methods to make buffs easily mutable.
              public abstract class Buff
              {
                  public abstract void ActivateInSlot(GameEventsContext ctx);
                  public abstract void DeactivateInSlot(GameEventsContext ctx);
              }

Why it matters: buffs use polymorphism, so a new buff is a new class. No backend changes, and a buff can only interact with the game using predefined callbacks. Making it very moddable.

The team

Built for a team of two

Front end / back end split. My friend can build content without being able to cause systemic bugs.

MVP. Game logic is kept separate from what's shown on screen.

Strategy pattern. Behaviour like AI decisions is swappable, not hard-coded.

My partWhat I did

01
systems

Grid Engine

Everything in the game interacts with a grid layer, making it an engine within an engine

02
systems

Chess Engine & APIs

Chess rules and pieces on top of the grid, exposed through APIs the rest of the game builds on

03
systems

Buff System

Polymorphic and easily expandable to new buffs without touching the backend

04
programming

Custom A* Pathfinding

Built for the grid engine, since Unity doesn't provide it for this setup

05
gameplay

Environments

Implemented boards with unique tiles & dangers, such as tornadoes and quicksand

06
production

Lead dev & marketing

Led the codebase and ran the game's marketing

Looking backTakeaways

Boundaries protect teams

A clean front end / back end split lets two people work fast without breaking each other's code.

Polymorphism over special cases

Adding a buff means adding a class, not editing the engine.

Invest in the base layer

The grid engine took work up front but now underpins every system, and carries over to future games.

GalleryScreenshots

Desert Swamp, changing buffs Throne room Shop Dark hallways Underling room Grass Defeated