Maackesgeist: A Chess Engine for Raumschach
The First Documented AI Opponent for Three-Dimensional Chess
Raumschach — literally “space chess” in German — was invented by Ferdinand Maack of Hamburg and first published in 1907. It is played on a 5×5×5 board comprising five stacked 5×5 levels, and introduces two pieces absent from orthodox chess: the Bishop restricted to face-diagonals, the Unicorn restricted to space-diagonals (triagonals), and a Queen that combines all three sliding directions of three-dimensional space. Despite more than a century of theoretical attention — most authoritatively chronicled by Anthony Dickins (1914–1987) in A Guide to Fairy Chess (1969–71) — no computer opponent for Raumschach had, to the present author’s knowledge, been publicly documented prior to the engine described here.
Maackesgeist is the AI component of a browser-based Raumschach implementation. It is written entirely in JavaScript, executes without a server, and is playable at four difficulty levels. This article provides a formal account of the engine: its algorithmic design, its evaluation function, its novelties relative to the state of the art in chess programming, and a candid assessment of its current weaknesses and potential improvements.
Orthodox chess programming has a documented history stretching from Shannon’s 1950 paper to the dominance of neural-network engines in the 2010s. Chess variants, however, have received far less attention. Engines for variants such as Chess960, Crazyhouse, and Antichess are supported by general-purpose engines like Stockfish and Fairy-Stockfish. For three-dimensional chess specifically, implementations of the commercial game Tri-Dimensional Chess (popularized by Star Trek) have appeared, but the rules of that game differ fundamentally from Raumschach.
For Raumschach proper — with its 5×5×5 geometry, Unicorn piece, and Maack–Dickins rules — no open or documented AI opponent appears to have existed prior to Maackesgeist. Online playable versions of Raumschach have existed, as has an AI opponent, but these AI opponents have lacked documentation beyond a vague description such as minimax with alpha-beta pruning. The absence of a documented AI opponent is unsurprising: the combinatorial complexity of the 3D board is substantially higher than that of orthodox chess, and the theoretical literature has focused on rules, notation, and problems rather than computation.
The claim of Maackesgeist as the first fully documented Raumschach engine must be advanced with appropriate epistemic caution. It is possible that private, documented and unpublished implementations have existed in academic contexts, hobbyist projects, or proprietary software. The claim advanced here is narrower and more defensible: Maackesgeist is, to the best of the present author’s knowledge, the first publicly playable and documented AI opponent for Raumschach according to the Maack–Dickins rules. The engine’s source code is embedded in a single HTML file, fully inspectable, and requires no installation.
The board is represented as a three-dimensional JavaScript array board[l][r][f], where l ∈ {0,1,2,3,4} indexes the level (A through E in Maack notation; A = 0 at the bottom for White), r ∈ {0,1,2,3,4} indexes the rank (1 through 5), and f ∈ {0,1,2,3,4} indexes the file (a through e). Each non-empty cell holds a plain object { type, color }. The board is cloned on each node of the search tree by a full deep-copy; this representation is simple and correct, though it carries significant performance costs relative to bitboard encodings (discussed in §7.6).
Three-dimensional piece movement requires three classes of direction vector, generalising the two classes of orthodox chess:
| Name | Count | Description | Pieces |
|---|---|---|---|
| Orthogonal | 6 | ±1 along exactly one axis | Rook, Queen |
| Face-diagonal | 12 | ±1 along exactly two axes | Bishop, Queen |
| Space-diagonal | 8 | ±1 along all three axes | Unicorn, Queen |
| All directions | 26 | Union of the above | Queen, King |
The Queen in Raumschach thus controls up to 26 directions of sliding movement — a dramatic increase over the 8 directions available in orthodox chess, and a major source of the game’s tactical complexity. The Knight’s move is extended to three dimensions by enumerating all integer displacements that are permutations of (±2, ±1, 0), yielding 24 distinct directions compared to 8 in orthodox chess.
Move generation follows the standard pseudo-legal approach. For each piece of the side to move, candidate moves are generated without checking whether they expose the moving side’s King to check; these are then filtered to legal moves. Sliding pieces (Rook, Bishop, Unicorn, Queen) use a ray-casting loop that extends in each direction until the board boundary is reached or a piece is encountered. Stepping pieces (King, Knight) generate single-step candidates. Pawns advance in the positive rank direction for White (or negative for Black) and may also advance one level per move, with diagonal captures in the same combined directions.
Legal moves are obtained by applying each pseudo-legal move to a copy of the board and testing whether the moving side’s King is then in check. Check detection performs a reverse-ray trace: it asks whether any opposing piece of each relevant type could attack the King’s square from the directions appropriate to that piece type. This is both logically correct and the conventional approach.
Maackesgeist implements the Maack–Dickins distinction between boardmate and spacemate. If the King is in check and has no legal moves on its current level but may still escape to an adjacent level, the position is boardmate (annotated ††). Only if the King is in check and has no legal moves whatsoever is the position spacemate — true checkmate, terminating the game (annotated †††). This distinction, absent from orthodox chess, is correctly implemented and annotated in the move log.
Maackesgeist uses alpha-beta minimax search with capture-first move ordering. The search is depth-limited; at depth zero the static evaluation function is called. No quiescence search, transposition table, or iterative deepening is employed.
| Level | Name | Search Depth | Character |
|---|---|---|---|
| 0 | Beginner | 0 plies | Selects a random legal move |
| 1 | Easy | 2 plies | Sees one move ahead for each side |
| 2 | Normal | 3 plies | Rudimentary tactical awareness |
| 3 | Hard | 4 plies | Strongest available; sees 2-move combinations |
No prior published evaluation function for Raumschach is known to the present author. Maackesgeist therefore establishes the first benchmark for piece values and positional scoring in this game. Several of its choices merit specific comment.
Centrality in three dimensions. The centrality score 6 − (|l−2| + |r−2| + |f−2|) is the three-dimensional analogue of the taxicab-centrality used in orthodox chess piece-square tables. The geometric centre of the 5×5×5 board is the cell Cc3 in Maack notation, which scores the maximum centrality of 6; the eight corner cells score 0. Weighting piece values by this measure rewards centrality in a principled way.
The Unicorn’s exceptional centrality bonus. The Unicorn receives the same centrality multiplier (×100) as the Queen — larger than that of the Rook (×67), the Bishop (×33), and the Knight (×50). This is theoretically motivated: the Unicorn’s triagonal movement radiates from the centre of the board and its coverage falls sharply when displaced to a corner. A Unicorn at the centre commands 8 long space-diagonals through the entire volume; at a face centre it commands only 4; at a corner it commands only 1. Rewarding central placement for the Unicorn is therefore correct.
Bishop’s level bonus. In addition to the general centrality bonus, the Bishop receives a supplementary reward for occupying a central level: (2 − |l−2|) × 8. This reflects the fact that a Bishop on levels A or E is effectively restricted to slides within a single 5×5 plane and its face-diagonals into adjacent planes; a Bishop on the central level C has access to face-diagonals in all directions.
Pawn advancement in two dimensions. Orthodox chess evaluation rewards pawns for rank advancement alone. Maackesgeist additionally rewards advancement in the level dimension (la × 15), reflecting the fact that White pawns may advance by one rank or one level per move, and that level advancement is strategically as significant as rank advancement. A further bonus (+25) is awarded to pawns on the central level, which enjoys the greatest connectivity across all directions.
The engine correctly implements all six Raumschach piece types according to the Maack–Dickins rules, including the full 24-direction 3D Knight and the distinction between the three sliding piece families. Earlier online Raumschach implementations have, in some cases, employed simplified or incorrect move sets. Maackesgeist’s move generation has been verified against the theoretical source.
The engine runs in a single HTML file without server infrastructure, external libraries, or installation. This makes it the most accessible Raumschach opponent ever produced. The entirety of the game logic — board representation, move generation, check detection, search, evaluation, rendering, and notation — occupies fewer than 300 lines of JavaScript.
The most significant algorithmic weakness is the absence of quiescence search. At the leaf nodes of the search tree, the static evaluation function is called on positions that may be tactically unstable: a piece may be hanging, a sequence of captures may be in progress, or a forcing combination may be one ply beyond the horizon. Evaluating such positions with a static material count produces the horizon effect, whereby the engine plays a move that appears good at the searched depth but walks into a losing sequence just beyond it. In Raumschach this effect is amplified: the board supports more simultaneous threats due to the greater number of attack directions, and unresolved capture sequences are correspondingly more dangerous.
The search revisits identical positions reached by different move sequences. A transposition table (a hash table keyed on Zobrist hashes of board positions) would allow the engine to recall the score of a previously evaluated position, avoiding redundant computation and effectively extending the search depth at no additional cost. Without it, the engine performs significantly more work than necessary, particularly in the endgame where many move orders converge to the same position.
The maximum search depth is 4 plies. In orthodox chess, 4-ply search corresponds approximately to the strength of a beginner club player. In Raumschach, the branching factor of the search tree is substantially higher than in orthodox chess: each position has more legal moves on average, due to the greater mobility of sliding pieces in three dimensions. The practical effect is that 4-ply search in Raumschach covers far fewer meaningful move sequences than 4-ply search in orthodox chess, and tactical combinations longer than 2 moves are largely invisible to the engine.
Move ordering consists solely of sorting by the value of the captured piece (Most Valuable Victim, or MVV). No Least Valuable Aggressor (LVA) tiebreaker is applied, and no quiet-move ordering heuristics — killer moves, history heuristic — are implemented. Poor move ordering reduces the effectiveness of alpha-beta pruning. With perfect move ordering, alpha-beta searches a tree of size O(bd/2) rather than O(bd), where b is the branching factor and d the depth. Without good ordering, this saving is substantially reduced.
The evaluation function captures material balance and centrality, but is blind to a wide range of strategically important features. The engine has no incentive to keep its King safe except insofar as this is captured by check detection at the leaves. Pawn structure features (doubled, isolated, and passed pawns) are not recognised. Piece mobility is not counted. Piece values are fixed regardless of game phase: in the endgame, King activity and pawn promotion become dominant, but the engine applies the same weights throughout the game.
Cloning the board on every node of the search tree is expensive. Each deep copy of the 5×5×5 array of objects involves significant memory allocation and triggers JavaScript garbage collection. A bitboard representation — in which the positions of each piece type and color are encoded as integers — would allow the engine to make and unmake moves in place, dramatically reducing overhead. In a 5×5×5 = 125-cell board, each piece set fits in two 64-bit integers (since 125 < 128 = 2×64), making bitboards feasible.
Adding quiescence search at the leaf nodes would eliminate the most damaging class of tactical errors. A minimal implementation would extend the search at captures, calling evalBoard only when no captures are available. This change requires no alteration to the evaluation function and would improve playing strength substantially even without increasing the nominal search depth.
Zobrist hashing assigns a random 64-bit integer to each (piece, color, square) triple and XORs these values to produce a compact board hash. The hash can be updated incrementally on make and unmake. A hash table mapping positions to previously computed scores — with depth and flag metadata — would eliminate repeated computation and allow effective use of iterative deepening.
Rather than searching to a fixed depth, iterative deepening searches to depth 1, then 2, then 3, and so on, using the results of each shallower search to order moves for the next. Combined with a transposition table, iterative deepening provides the depth-first search with the move-ordering benefits of breadth-first search, and allows the engine to be interrupted after any complete iteration, making it amenable to time-controlled play.
Adding LVA tiebreaking to MVV ordering (prefer to capture with the least valuable aggressor) would improve pruning efficiency at no cost. Killer move heuristics — storing moves that caused beta cutoffs at a given depth and trying them first — would further improve ordering for quiet positions.
Adding a term for the number of legal moves available to each side — particularly for the Queen and Unicorn — would give the engine a meaningful positional signal in positions where material is approximately equal. Mobility evaluation is standard in orthodox chess engines and is especially relevant in a three-dimensional game where piece scope varies dramatically with position.
A full rewrite of the board representation using bitboards, with incremental Zobrist hash updates and in-place make/unmake, would be a significant engineering investment but would unlock an order-of-magnitude improvement in nodes searched per second. This would allow the engine to search to depth 6 or 7 within the same time budget as the current depth-4 search — a qualitative change in playing strength.
Maackesgeist constitutes, to the best of present knowledge, the first documented AI opponent for Raumschach. Its algorithm is a classical alpha-beta minimax search with capture-first move ordering and a material-plus-centrality evaluation function. The evaluation function introduces several Raumschach-specific refinements — the Unicorn centrality bonus, the Bishop level bonus, and the two-dimensional pawn advancement reward — that are theoretically motivated and have no analogues in prior work.
The engine’s weaknesses are those typical of a first-generation, zero-dependency implementation: the horizon effect from absent quiescence search, shallow effective depth due to the high 3D branching factor, and the performance cost of cloning-based board representation. A clear roadmap exists for improvement, beginning with quiescence search and a transposition table, which would advance the engine’s strength substantially without requiring a full rewrite.
As the first working opponent for a game described in the theoretical literature for over a century, Maackesgeist is a historically notable artifact in the study of three-dimensional chess. Its existence may stimulate further development — of stronger engines, of opening theory, and of endgame analysis — in a domain that has for too long remained without a mechanical adversary.