Raumcapa: A Raumschach Engine

1. Introduction

Raumschach — literally “space chess” in German — was invented by Dr. Ferdinand Maack (1861–1930) of Hamburg and first published in 1907. Its mature version, referred to as “Normal Form,” is played on a 5×5×5 board composed of five stacked 5×5 levels and introduces the Unicorn, a rider confined to space-diagonal (three-axis) rays. The Queen combines all three rider types. Despite more than a century of theoretical attention — documented most authoritatively by Anthony Dickins (1914–1987) in A Guide to Fairy Chess (1969–71) — computer opposition for Raumschach has remained underdeveloped and underdocumented.

Raumcapa is a browser-based AI opponent for Raumschach, available in the raumschach.org game client. Its central technical contribution is its architecture: it uses no minimax search tree, no alpha-beta pruning, and no neural network. Instead, it projects a piece influence field — a Chebyshev-distance-decayed map of each color’s positional reach — across all 125 cells of the board, selects candidate moves by ten named positional principles, and ranks them by one-ply static evaluation. The approach places Raumcapa in a small and historically notable category: principle-only chess engines that reason about structure rather than searching a game tree.

The evaluation function is organized around the documented playing principles of José Raúl Capablanca (1888–1942), adapted to the geometry of three dimensions. The design premise is that Capablanca’s method — economy of means, structural patience, the relentless improvement of the worst-placed piece — was never fundamentally two-dimensional. It was an algorithmic instinct for what the position demands, a quality that translates intact into three dimensions and, in some respects, finds a more natural home there.

This article is organized as follows: §2 presents the historical and philosophical case for choosing Capablanca as design model; §3 situates Raumcapa among known Raumschach engines and discusses its novelty as a principle-only system; §4 and §5 describe board representation and move generation; §6 presents the complete algorithm; §7 documents the evaluation function; §8 records principal design decisions; §9 assesses advantages and disadvantages; §10 identifies Capablancan principles not yet encoded; and §11 concludes.

2. On the Choice of José Raúl Capablanca

The decision to ground Raumcapa’s evaluation in the principles of José Raúl Capablanca (1888–1942) rests on three independent grounds.

Historical Coincidence

Raumschach was invented in 1907 and had its peak cultural vitality in the 1920s, when it attracted serious attention from the German and Central European chess community. The greatest chess player of that precise decade was Capablanca. He won the world championship from Emanuel Lasker in 1921, dominated the great tournaments at London 1922 and New York 1924, and was considered so clearly the strongest player alive that his 1927 loss to Alexander Alekhine in Buenos Aires — a 34-game match he entered as a prohibitive favorite — remains one of the most shocking results in chess history. Capablanca is not merely a plausible model for a Raumschach engine; he is the world champion of Raumschach’s prime decade. The connection is a historical fact, not a design conceit.

Principle as Algorithm

Capablanca’s chess was governed by a principle that translates directly into algorithmic form: find the simplest path to the correct structure. He did not search for brilliant combinations; he searched for positions where the correct move was nearly forced, where the opponent’s resources were exhausted, where the conversion path was clear. This is precisely the kind of chess a principled evaluation function can embody: recognize structural advantages, improve the least-active piece, simplify when ahead. Each of these corresponds to an explicit term in Raumcapa’s evaluation and candidate-generation logic.

Importantly, Capablanca was not merely intuitive — he was explicit. His two instructional books, Chess Fundamentals (1921) and A Primer of Chess (1935), state his principles in language direct enough to serve as engineering specifications: “Improve the position of the piece that is worst placed.” “When ahead in material, exchange pieces but avoid pawn exchanges.” These sentences appear nearly verbatim in the candidate-generation logic of §6.3.

Endgame

By common consensus, Capablanca’s endgame technique was the finest of any player who ever lived. In Raumschach, where the endgame presents fundamentally new features — a 5×5×5 king march, no formal castling, the unicorn as an endgame piece — endgame understanding matters differently than in two-dimensional chess. Raumcapa’s king activation terms encode Capablanca’s documented endgame principle directly: when it is safe to do so, march the king toward the geometric center and toward the enemy king, and do so without hesitation.

Paul Morphy (1837–1884) is the other player one might consider — perhaps the purest first-principles player in the history of the game. A Morphy-derived engine would have been conceptually coherent. The reason Capablanca is preferred is documentary: his principles are self-articulated in writing with sufficient precision to be used as design specifications. Morphy’s principles are reconstructed by historians from his games and letters, not stated by Morphy himself with codeable specificity.

3. Raumcapa and the Raumschach Engine Landscape

Several browser-playable AI opponents for Raumschach have been made publicly available over the years. Most have been described as using minimax with alpha-beta pruning. To the best of the present author’s knowledge, none has published implementation details, evaluation functions, or pseudocode. Raumcapa is, to the best of the present author’s knowledge, the second fully documented Raumschach engine in the public record, after Maackesgeist, which established that record. The present article makes available a complete technical description including board representation, direction geometry, legal move generation, the evaluation function with all heuristic weights, and the complete algorithm in pseudocode.

A Principle-Only Engine

In his 1950 paper “Programming a Computer for Playing Chess,” Claude Shannon distinguished two approaches to machine chess. Type A engines examine every legal move to some fixed depth — the exhaustive minimax tradition that dominated the field for seventy years, from early programs through Deep Blue and beyond. Type B engines instead select a subset of “plausible” moves at each node, mimicking human selective attention. Shannon believed Type B was more promising; in practice, the field converged almost entirely on Type A once alpha-beta pruning made exhaustive search computationally tractable.

Neural network engines, beginning with AlphaZero (2017), revived selectivity through learned policy functions, but retained the game tree: Monte Carlo Tree Search still searches positions many plies deep, guided by a neural network rather than hand-written heuristics.

Raumcapa belongs to neither tradition. It is not Type A (no game tree is searched beyond one ply). It is not a neural network (no weights are learned from data). It is, in effect, a Type B system taken to a logical extreme: candidate moves are selected entirely by named positional principles, and the position is evaluated without any opponent-reply search at all. To the best of the present author’s knowledge, truly search-free chess engines of this kind are vanishingly rare in the literature. Botvinnik’s “Pioneer” program (1970s) used plan-based selective search, but still searched several plies ahead. Raumcapa does not.

Why Raumschach Is Suited to This Approach

The choice is not arbitrary. Raumschach has a substantially higher branching factor than flat chess: the Queen controls up to 26 ray directions, the Knight has 24 jump targets from an interior cell, and the 5×5×5 board produces an average legal-move count well above the flat-chess average of roughly 30. Minimax at useful depth is correspondingly more expensive and more prone to horizon-effect distortions. The influence-field approach side-steps these costs entirely, producing instant responses at any difficulty level.

There is also a structural argument. Raumschach’s theory is nascent; there is no deep opening book, no large body of annotated master games, and no well-established middlegame canon. In this environment, a principle-based engine is not a degraded version of a search engine — it is a reasonable first approximation of how strong human Raumschach players must think. The engine’s reasoning is also fully transparent: every move it makes traces to one of ten named principles and an explicit evaluation score.

4. Board Representation

The board is a JavaScript three-dimensional array board[l][r][f], where l ∈ {0–4} indexes the level (A through E), r ∈ {0–4} the rank (1–5), and f ∈ {0–4} the file (a–e). An occupied cell contains a plain object { type, color }; an empty cell contains null. Piece types are the single-character strings K Q R B U N P; colors are 'w' and 'b'.

4.1 Geometric Direction Sets

The Knight extends to three dimensions through all permutations of (±2, ±1, 0), yielding 24 distinct jump directions from an interior cell. All direction sets are precomputed as constant arrays at startup.

Two distance and centrality helpers are used throughout: cheby(al,ar,af,bl,br,bf), the Chebyshev distance between two cells; and cenDist(l,r,f) = max(|l−2|, |r−2|, |f−2|), the Chebyshev distance from any cell to the geometric center Cc3 = (2, 2, 2). The influence decay function is φ(d) = 1/(1+d), where d is the Chebyshev distance from a piece to a target cell.

The choice of Chebyshev distance rather than Manhattan distance is deliberate. Chebyshev distance reflects the number of King moves required to reach any cell, and correctly distributes centrality penalties: Manhattan distance over-penalizes edge cells along one axis while under-penalizing true corner cells.

5. Move Generation

pieceMoves(board, l, r, f) generates pseudo-legal moves for a single piece by ray-casting (sliding pieces) or single-step enumeration (King, Knight, Pawn). allPseudo(board, color) aggregates over all pieces of a given color. legalMoves(board, color) filters pseudo-legal moves by make/unmake: each candidate move is applied in place, the moving side’s King is tested for check via isAttacked, and the move is immediately undone — producing no heap allocations.

isAttacked(board, cell, byColor) performs reverse ray-casting from the target cell. Pawn promotion is handled inside pieceMoves: when a pawn reaches the promotion rank, the move is emitted five times with prom set to each of Q R B U N. The engine always selects the Queen promotion.

6. The Algorithm

The engine operates in four stages per move decision: (1) compute influence fields for both colors; (2) detect the current phase; (3) generate a candidate set by positional principles; (4) evaluate each candidate by one-ply static evaluation and return the highest-scoring move. No game tree is searched; the opponent’s reply is not considered.

6.1 Piece Influence Fields

For a given color, the influence field is a flat array of 125 values, one per cell of the board. Each own piece at cell (l, r, f) contributes φ(d) = 1/(1+d) to every cell (tl, tr, tf) reachable by a legal move, where d is the Chebyshev distance from the piece to the target. A Queen on a central square with 40 legal move targets radiates influence broadly; a Unicorn confined to a corner with three targets radiates almost none. The field thus encodes both quantity and quality of positional reach.

Two fields are computed per move decision: ownField and oppField. They are used in evaluation for center control, king safety and shelter, piece coordination, and outpost detection. They are also used directly in candidate generation to distinguish safe squares (low oppField) from dangerous ones.

FUNCTION computeInfluenceField(board, color) → Float32Array[125]:
  field ← zeros(125)
  FOR EACH own piece at (l, r, f):
    FOR EACH legal move target (tl, tr, tf):
      d ← cheby(l, r, f, tl, tr, tf)
      field[tl × 25 + tr × 5 + tf] += φ(d)   // φ(d) = 1/(1+d)
  RETURN field

6.2 Phase Detection

Three phases are distinguished per color. Opening: hasUndevelopedPiece returns true, meaning at least one minor piece (N, B, U, Q) or the King still sits on its home square. Endgame: both queens are off the board and the opponent holds at most one non-pawn, non-king piece. Middlegame: neither opening nor endgame condition is met. The phase gate controls which candidate-generation principles are active.

On the choice of which pieces gate the opening. Rooks are intentionally excluded from hasUndevelopedPiece. A Rook develops not by moving early, but by occupying an open file or rank once the opening fight has resolved. Requiring a Rook to leave home before declaring the opening over is causally backwards — and in practice catastrophic: a Rook that never finds an open file in the first twenty moves holds the engine in opening mode indefinitely. Rooks are the one piece class that should emerge as a consequence of the opening resolving, not a precondition for it.

The King is included. Capablanca considered king safety — castling — a component of opening completion, not something to be deferred once the middlegame began. In Raumschach the equivalent is the tuck. An unmoved King on its starting square represents an incomplete opening objective. The King’s own tuck logic (Principle 4) reliably generates the corner approach as a candidate; the W_KING_FILE evaluation penalty (§7.6) ensures that candidate is actually chosen rather than passed over in favor of piece development.

Monotonic phase floor. determinePhase is backed by _phaseFloor, a persistent worker-scope object keyed by side, which makes the opening→middlegame boundary a one-way door. Without it, a piece returning to its home square after having left — the King tucking back, or a piece driven back in a skirmish — would re-trigger hasUndevelopedPiece and revert the phase to opening mid-game, reactivating all opening-only candidate-generation principles at the wrong moment. The floor advances from ‘opening’ to ‘middlegame’ the first time all qualifying pieces have left their home squares, and thereafter holds there regardless of subsequent piece movement. The only reset is when the board shows no qualifying piece off its home square at all — unambiguously a fresh position, covering the new-game case without requiring an explicit reset signal.

The middlegame↔endgame boundary is explicitly not guarded by the floor. A pawn promotion can restore a queen and legitimately push the position back from endgame to middlegame; that transition must remain live in both directions. Only the opening→middlegame boundary is a one-way door: once pieces have developed, they have developed.

6.3 Candidate Generation: Ten Positional Principles

The candidate set is assembled by up to six principle groups, applied in order. Duplicates are suppressed by a move-key map. If fewer than MIN_CAND = 6 candidates are collected after all principles, a safety-net fill ranks remaining legal moves by single-step SEE plus centrality gain and adds from the top until the minimum is reached, tagging each addition so it remains distinguishable from a principled pick. The six principles are as follows.

Principle 1 — Safe checks. Any move that gives check and leaves the checking piece either defended or unattacked. The safety condition is verified by make/unmake.

Principle 2 — Threat response. A piece qualifies for a response under either of two signals: diffuse enemy influence above a threshold (oppField[sq] > THREAT_THRESH = 0.40), or an exact attacker found by lva (least-valuable attacker) on the current board. The two signals are not redundant. oppField[sq] sums φ(d) = 1/(1+d) over every enemy piece that can reach the square, so it reliably flags accumulating pressure from several attackers at once, but a single attacker does not always clear 0.40 on its own: every Knight move in this geometry has Chebyshev distance exactly 2, so a lone Knight contributes exactly φ(2) = 0.33, and a lone slider two or more squares away contributes 0.33, 0.25, or less — all sub-threshold. The lva check closes that case directly: it asks only whether some opponent piece can capture this square right now, with no distance decay and no dependence on how many other attackers happen to be present, so a piece attacked by exactly one Knight, or by one slider that isn’t adjacent, still qualifies even where the diffuse signal alone would not notice. Once a piece qualifies under either signal, two responses are generated: escape moves to a safe destination (low oppField, verified safe by make/unmake), and captures of any board piece where see1() clears the contextual exchange threshold τ (see §7.13). see1() applies the capture, finds the opponent’s cheapest recapture, and returns the signed net gain. A result at or above τ indicates the exchange is appropriate given the current position’s material balance, king safety, and the piece’s own activity.

Principle 2b — Jump threats (Knight fork pre-emption). Principle 2 above responds only to threats that already exist on the current board, surfaced by oppField or an exact lva hit. A different class of danger is latent rather than current: an enemy Knight that has not yet moved, but whose next jump would land on a square attacking one or more own pieces. The Knight is the only leaping piece in Raumschach — sliding and stepping pieces are already covered by Principle 2’s current-board check and by veiledThreatCount — so this latent case is isolated and answered by a dedicated geometric scan, jumpThreats, rather than by search. For every enemy Knight, each of its jump destinations is examined; for each destination, every own non-pawn piece that landing there would attack is collected as a victim, with a destination covering two or more victims flagged as a fork. Pawns are excluded from victim-counting: a Knight can never profitably initiate a capture against a lone pawn, so pawn-only ‘threats’ would flood the candidate set with noise rather than addressing anything materially significant. For each qualifying (Knight, landing) pair, three classes of candidate are generated: escape — move a victim (other than the King, whose own escapes are Principle 2’s domain) to a destination safe by make/unmake; attack — capture or drive off the threatening Knight now, accepted whenever see1() is at least neutral, so the engine does not concede material merely to forestall a threat that has not yet materialized; and landing denial — when the landing square is currently empty, occupy it with any non-King piece via a move verified safe by make/unmake, removing the destination before the Knight can ever reach it. This is the engine’s one principled instance of opponent-move anticipation without an opponent-reply search: the threat is read directly off the current board’s static geometry, at the cost of two passes over the Knight’s jump directions, rather than by simulating a reply.

Principle 3 — King shelter. When enemy influence in the king’s immediate neighborhood exceeds friendly influence by a threshold, moves that place a friendly piece in the king’s neighborhood at a safe destination are included.

Principle 4 — Opening development. Active while hasUndevelopedPiece is true. For non-pawn, non-king pieces still on their home square: moves to a safe destination with strictly lower cenDist than the home square are added as development candidates, and devMoveFound is set true. When no such strictly-improving move exists — because the piece’s path toward the center is entirely blocked by own or enemy pieces — a lateral fallback fires: any safe move to a square with cenDist ≤ srcCen (same or better centrality) is accepted. This prevents geometrically cornered pieces, such as a Unicorn or Bishop on a back-level corner square with all diagonals blocked, from holding the engine in the opening phase indefinitely because they cannot satisfy the strict < criterion. The fallback fires only when no strictly-improving move was found in the primary pass, so it does not broaden the candidate set for well-placed pieces. For the King: moves that stay on the home level and bring the king’s file index strictly closer to the nearest corner (file 0 or 4) — Capablanca’s king-tuck, implemented as a progressive corner approach across as many moves as needed. A queen-development gate is enforced as a final filter: the Queen may not leave her home square before at least one own Knight has left its home square. If filtering would leave the candidate set empty, the gate is lifted.

Principle 4b — Pawn structural development. Capablanca’s opening play followed a strict priority: pieces come out before pawns advance beyond what the position requires. A pawn move is treated as primary opening development only when it serves one of two structural purposes — opening a line for a friendly slider, or claiming central space. linesOpenedByPawnMove tests whether the pawn is the first blocker along any direction vector of a friendly Bishop, Unicorn, Rook, or Queen; if its departure would immediately extend that piece’s reach, the pawn move qualifies. Central-space claims use the same inner 3×3×3 test as elsewhere in the engine. Quiet pawn advances meeting neither condition are not added by this principle — they are passed over in favor of genuine piece development, though they remain available as a last resort through the central volume contest or the safety-net fill if nothing better exists.

The development gate. Capablanca’s opening discipline included a further rule: do not move the same piece twice while other pieces remain undeveloped. developmentGateOK implements this directly from the current position, with no move-history tracking required. isHomeSq serves as the proxy for “has this piece already moved”: a piece still on its home square has not developed and may move freely. A piece already off its home square may move again only under one of three conditions — it is currently threatened (lva finds an opponent attacker), the move wins material (see1() on a capture clears the contextual exchange threshold τ), or no other undeveloped piece has any safe developing move available this turn, tracked via a devMoveFound flag set during Principle 4’s main loop and consulted lazily. This gate is applied to the central volume contest sub-principle and to Principle 5b below, the two principles that iterate over all legal moves without already restricting themselves to undeveloped pieces. Principle 1 (threat response) is deliberately left ungated: it fires only under genuine threat or a winning capture, which are already the gate’s own exceptions (a) and (b), so gating it would be redundant. Principle 4’s own loop is likewise already gate-compliant by construction, since it considers only home-square pieces in the first place.

Principle 5 — Worst-piece improvement. Active outside the opening. The worst piece is the own non-pawn, non-king piece with the lowest influence-weighted mobility: Σ_m φ(cheby(sq, m.to)) over all legal moves m. worstPiece skips pieces with zero legal moves (c > 0 && c < lowestC); a blocked Rook in the corner scores c = 0 and is excluded, so the function always returns the least active piece that can actually do something. If all non-king, non-pawn pieces are immobile the function returns null, and P5 generates nothing. The King is excluded from worstPiece throughout: its opening development is the exclusive domain of the dedicated tuck logic in Principle 4, and in the middlegame and endgame its movement is governed by Principle 6. Moving the King toward the center via P5 is precisely the suicidal behaviour the king-exclusion guards prevent. Moves from the worst piece to a safe destination closer to the center are added.

Principle 5b — Anti-development occupancy (prophylaxis). When the opponent is still in the opening phase, the engine identifies the opponent’s worst piece (lowest positive influence-weighted mobility, via worstPiece, subject to the same exclusions) and enumerates all squares that piece could reach that would improve its Chebyshev centrality. Any own move that lands safely on one of those squares is added as a candidate, subject also to the development gate during our own opening phase. The King is explicitly excluded from contributing to this principle: King moves into the central cube are precisely the suicidal moves the architecture works to prevent, and treating them as desirable “prophylactic” destinations would undermine the safety logic. This directly encodes Capablanca’s prophylactic principle: if they intend to develop their worst piece toward the center, occupy those squares first. The opponent’s pseudo-legal moves are used (no make/unmake), keeping the cost O(board).

Principle 5c — Piece-safety under material deficit (prophylaxis). When the engine is materially behind by more than 50 cp, it uses lva (least-valuable attacker) to identify any own non-pawn, non-king piece attacked by a cheaper opponent piece — for example, a Rook (460 cp) threatened by a Unicorn (290 cp). All safe escape moves for such pieces are added as candidates. This shares its exact-attacker mechanism with Principle 2 above, narrowed to the specific case that matters most once the position has already turned unfavorable: a losing exchange the engine can least afford to allow. The material-deficit gate makes Principle 5c a targeted reinforcement of Principle 2’s coverage at exactly the moment standing pat is costliest, rather than an independent detection path.

Principle 6 — Endgame: king march and passed pawns. Active in the endgame phase. King moves to a cell closer to the board center are included. All moves advancing any own passed pawn are included.

A central volume contest sub-principle also fires when the opponent’s cumulative influence over the inner 3×3×3 cube exceeds the engine’s own: moves to any inner-cube cell with low enemy influence are added. King moves are explicitly excluded from this sub-principle, and during the opening phase every candidate move is additionally checked against the development gate above, so this sub-principle cannot be used to justify a second move of an already-developed piece. This operates throughout all phases.

King candidate channels. Following the exclusions in P5, P5b, the central volume contest, and the safety-net fill, the King may enter the candidate set through exactly four principled paths: Principle 1 (a King move that gives check), Principle 3 (king shelter in an emergency, where the King moves a piece into its own neighborhood), Principle 2b (the King capturing the threatening Knight itself, the one branch of the jump-threat response not restricted to non-King movers), and the dedicated tuck logic in Principle 4. No undirected King move can reach the candidate list by any other route.

FUNCTION generateCandidates(board, color, phase, ownField, oppField, legal) → moves:
  seen ← empty Map (move key → move)
  devMoveFound ← false   // set true once Principle 4 adds an undeveloped-piece move
  exchBaseline ← exchangeBaseline(board, color, ownField, oppField)  // material + king safety; computed once
  // developmentGateOK: "don’t move the same piece twice in the opening"
  FUNCTION developmentGateOK(sq, type, m):
    IF phase ≠ ‘opening’ OR type ∈ {Pawn, King}: RETURN true
    IF isHomeSq(sq, type, color): RETURN true               // has not developed yet
    IF lva(board, sq, opponent) ≠ null: RETURN true        // (a) threatened
    IF m is capture AND see1(m) > exchangeThreshold(baseline, mover.type, m.from, m.to, ownField, oppField): RETURN true         // (b) wins material
    IF devMoveFound = false: RETURN true                     // (c) blockage
    RETURN false
  // Principle 1: safe checks
  FOR EACH m IN legal:
    IF m gives check AND checker is defended OR not attacked: add(m)
  // Principle 2: threat response (influence-threshold OR exact attacker)
  FOR EACH own piece at sq where oppField[sq] > THREAT_THRESH OR lva(board, sq, opponent) ≠ null:
    FOR EACH m IN legal FROM sq:
      IF oppField[m.to] < SAFE_THRESH AND trulySafe(m): add(m)  // escape
    FOR EACH m IN legal WITH capture AND see1(m) ≥ exchangeThreshold(baseline, mover.type, m.from, m.to, ownField, oppField): add(m)  // contextual threshold
  // Principle 2b: jump threats — latent Knight forks (pure geometry, no search)
  jThreats ← jumpThreats(board, color)
  FOR EACH {knightPos, landPos, victims} IN jThreats:
    FOR EACH victim IN victims where victim ≠ King:
      FOR EACH m IN legal FROM victim where trulySafe(m): add(m)        // (a) escape
    FOR EACH m IN legal TO knightPos where see1(m) ≥ 0: add(m)              // (b) attack the Knight
    IF landPos is empty:
      FOR EACH m IN legal TO landPos where mover ≠ King AND trulySafe(m): add(m)  // (c) deny landing
  // Principle 3: king shelter
  IF enemy influence in king’s neighborhood > friendly + 0.5:
    FOR EACH m IN legal where m.to is near king AND trulySafe(m): add(m)
  // Principle 4: opening development
  IF phase = ‘opening’:
    FOR EACH undeveloped non-pawn, non-king piece at home sq:
      hadImproving ← false
      FOR EACH m to safe sq with cenDist(m.to) < cenDist(home): add(m); devMoveFound ← true; hadImproving ← true
      IF !hadImproving:   // lateral fallback: piece geometrically blocked from improving
        FOR EACH m to safe sq with cenDist(m.to) ≤ cenDist(home): add(m); devMoveFound ← true
    FOR King on home level: add file-toward-corner moves that are safe
    // Queen gate: suppress queen moves until a knight has left home (filter removed if set empties)
  // Principle 4b: pawn structural development (line-opening or central-claiming only)
  IF phase = ‘opening’:
    FOR EACH own quiet pawn advance m:
      claimsCenter ← m.to IN inner cube
      opensLine    ← linesOpenedByPawnMove(m.from, color)  // pawn is first blocker on a friendly slider ray
      IF (claimsCenter OR opensLine) AND oppField[m.to] < SAFE_THRESH AND trulySafe(m): add(m)
      // other quiet pawn pushes are NOT added here — they may surface via central
      // volume contest or the safety net, but are not treated as primary development
  // Principle 5: worst-piece improvement (middlegame / endgame only)
  IF phase ≠ ‘opening’:
    wp ← worstPiece(board, color)  // excludes King, Pawn; skips pieces with c=0
    FOR EACH m FROM wp to safe sq with lower cenDist: add(m)
  // Principle 5b: prophylaxis — anti-development occupancy (King excluded; dev-gated)
  IF determinePhase(board, opponent) = ‘opening’:
    oppWP ← worstPiece(board, opponent)  // excludes King, Pawn; skips c=0
    oppTargets ← {m.to : m ∈ allPseudo(board, opp) FROM oppWP, cenDist(m.to) < cenDist(oppWP)}
    FOR EACH m IN legal where m.to ∈ oppTargets
                  AND mover ≠ King              // King never blocks dev squares
                  AND developmentGateOK(m.from, mover.type, m)
                  AND oppField[m.to] < SAFE_THRESH AND trulySafe(m): add(m)
  // Principle 5c: prophylaxis — piece-safety under material deficit
  IF materialBalance(board, color) < −50:
    FOR EACH own non-pawn, non-king piece at (l, r, f):
      threat ← lva(board, [l,r,f], opponent)
      IF threat exists AND PV[threat] < PV[own piece]:
        FOR EACH m IN legal FROM (l,r,f) where trulySafe(m): add(m)
  // Central volume contest (all phases) — King excluded; dev-gated in opening
  IF oppCenter > ownCenter:
    FOR EACH m to inner-cube sq where mover ≠ King
                  AND developmentGateOK(m.from, mover.type, m)
                  AND low oppField: add(m)
  // Principle 6: endgame king and passed pawns
  IF phase = ‘endgame’:
    FOR EACH king move to sq with lower cenDist, not attacked: add(m)
    FOR EACH passed pawn advance: add(m)
  // Safety net: fill to MIN_CAND; King moves excluded entirely
  IF |seen| < MIN_CAND:
    fill from remaining legal (excluding King moves), sorted by (see(m) + φ(cenDist(m.to)))
  RETURN [...seen.values()]

6.4 Evaluation

Each candidate is evaluated by applying it to the board, recomputing both influence fields from the resulting position, calling evalBoard, and unmaking the move. The evaluation function returns a score in centipawns from the mover’s perspective. Its components are documented in full in §7.

6.5 getBestMove and Difficulty

After all candidates are scored, the highest-scoring move is returned with its score attached as _score, alongside the position’s own _phase. Both accompany the move back to the main thread and drive two Capablanca-faithful policies that sit outside the worker’s search-free architecture entirely, since they are decisions about whether to continue playing rather than positional reasoning: the draw policy (§8.4) and the resignation policy (§8.10). If _score < DRAW_OFFER_THRESH = −80 cp, the engine proactively offers a draw; if the player offers a draw and _score < DRAW_ACCEPT_THRESH = +50 cp, the engine accepts.

Difficulty is controlled by a perturbation parameter: a uniformly distributed random value in [−perturbation, +perturbation] centipawns is added to each candidate’s score before comparison. A negative perturbation bypasses evaluation entirely and returns a random legal move. Five named levels correspond to five historical Capablanca phases:

FUNCTION getBestMove(board, color, perturbation) → move:
  legal ← legalMoves(board, color)
  IF legal is empty: RETURN null
  IF perturbation < 0: RETURN randomChoice(legal)   // Boy level
  phase    ← determinePhase(board, color)
  ownField ← computeInfluenceField(board, color)
  oppField ← computeInfluenceField(board, opponent)
  cands    ← generateCandidates(board, color, phase, ownField, oppField, legal)
  bestMove ← null;  bestScore ← −∞
  FOR EACH m IN cands:
    undo  ← makeMove(board, m)
    IF move gives checkmate: unmakeMove; RETURN m   // immediate checkmate
    nOwn  ← computeInfluenceField(board, color)
    nOpp  ← computeInfluenceField(board, opponent)
    s     ← evalBoard(board, color, nOwn, nOpp)
    s     += uniform{−perturbation, …, +perturbation}
    unmakeMove(board, m, undo)
    IF s > bestScore: bestScore ← s; bestMove ← m
  IF bestMove is null: bestMove ← randomChoice(legal)
  RETURN bestMove WITH _score ← bestScore

7. Evaluation Function — The Capablanca Heuristics

The evaluation function returns a score in centipawns from the mover’s perspective. It receives both influence fields as parameters, avoiding recomputation. The thirteen heuristic components are documented below.

8. Design Decisions

9. Advantages and Disadvantages

The influence-field architecture is not a minimax engine with features removed; it is a different kind of engine. Its strengths and weaknesses differ accordingly.

Advantages

Speed and responsiveness. Raumcapa returns a move instantly at any difficulty level. No search tree is constructed; the per-candidate cost is two influence-field computations and one evaluation call, each O(125). The browser is never blocked.

Transparency. Every move Raumcapa makes traces to one of ten named principles and an explicit numeric score. This is not true of minimax engines (where the chosen move emerges from a tree that cannot be easily summarized) and certainly not true of neural network engines. Players can understand, and disagree with, what Raumcapa is doing. Raumschach Studio’s Etiology panel (§8.13) puts this directly in front of the player, rather than leaving it as a property only the source code reveals.

Smooth difficulty gradient. Noise-controlled difficulty produces a more natural gradient than depth-controlled difficulty. At depth 2, a minimax engine plays very differently from depth 3; the change is discontinuous and qualitative. At perturbation 35 vs. 8 (Challenger vs. Champion), Raumcapa plays the same structural chess, with more or fewer random deviations.

Appropriate branching factor. The influence-field approach scales well to Raumschach’s high branching factor. Raumschach’s Queen controls up to 26 ray directions; the Knight has 24 jump targets from an interior cell. The candidate-generation step limits the work to a small principled subset of legal moves without paying the exponential cost of a game tree.

Educational style. A principle-based engine plays in a way that illustrates Raumschach strategy. Players can study its moves and extract something useful. A highly optimized minimax engine would be a stronger opponent but a less instructive one.

Disadvantages

Tactical blindness. The engine does not see two-move combinations. It cannot find a discovered check two plies away, a fork that requires a quiet preparatory move, or a mating sequence beyond an immediate check. In sharp tactical positions, it will be outplayed by any engine performing even shallow minimax.

No opponent modeling. Because the engine does not search the opponent’s reply, it cannot anticipate or prevent threats that do not already exist on the board. It will sometimes develop a piece into a position that the opponent can immediately exploit. The threat-response principle (Principle 2) mitigates this for existing threats but does not prevent future ones — with one narrow exception: the jump-threat principle (2b) reads a Knight’s latent next-move fork directly off the board’s static geometry, since the Knight’s leap makes that one case computable without search. Threats from sliding or stepping pieces, and anything requiring more than a single move to materialize, remain entirely outside the engine’s anticipation.

Candidate incompleteness. The safety-net fill at MIN_CAND = 6 guarantees a minimum candidate set, but there exist positions where the correct move is not generated by any of the ten principles and does not rank in the top-6 safety-net fill. Principles 5b and 5c substantially reduce the incidence of the most costly oversights — missed development blockades and unaddressed exchange threats — but the engine remains capable of overlooking defensive resources that require a non-obvious quiet move outside the principle categories.

Endgame imprecision. Capablanca’s endgame technique depended on calculation — precise mating sequences, zugzwang recognition, opposition play — that is beyond one-ply evaluation. The king activation and cut-off heuristics encode the general direction of correct endgame play but cannot execute technical conversions with the precision the historical Capablanca brought to them.

Strength ceiling. The engine’s strength is bounded by the quality of its positional principles and evaluation weights, with no computational path to improvement. A minimax engine can be made stronger simply by running deeper; Raumcapa’s ceiling is determined by the quality of its heuristics. That ceiling may be sufficient for recreational human Raumschach — but it is a ceiling.

10. Capablanca Principles Not Yet Encoded

The heuristics in §7 encode Capablanca’s most transferable positional principles. Several dimensions of his mastery are not yet encoded, falling into three categories.

10.1 — Inapplicable in Three Dimensions

Castling and king shelter. Capablanca castled quickly and consistently, regarding early king safety as a prerequisite for middlegame operations. Raumschach has no castling rule. The king-shelter heuristic (§7.6) and the opening-phase king-tuck (§6.3, Principle 4) capture the spirit, but the precise two-move castled architecture has no implementation target.

Classical king opposition. Capablanca’s endgame technique included precise understanding of king opposition — the rule that two kings standing two squares apart with the side to move lose the opposition. In Raumschach, kings can approach from 26 directions; opposition is not formally defined in the same way. The king-proximity term (§7.6) captures the king-approach incentive but not the formal opposition concept.

Minority attack. Capablanca was precise about pawn-majority dynamics and the use of a minority pawn attack to create structural weaknesses. In Raumschach, the pawn topology makes the classical minority attack inapplicable as a defined strategy.

10.2 — Absent but Codeable

Backward pawns. A backward pawn — one that cannot advance without moving into a square controlled by an enemy pawn, and behind which no friendly pawn supports — is a distinct weakness in flat chess. Raumschach’s three-dimensional pawn advance geometry does not provide a clean analogue: the forward directions include both level and rank advance, and a pawn blocked in one direction may still have the other open. A defensible 3D backward-pawn definition could be constructed and weighted, but has not yet been.

10.3 — Beyond One-Ply Evaluation

Combination finding. Capablanca’s play was not combinationally oriented, but he calculated precisely when he needed to. One-ply evaluation cannot find any combination requiring a quiet preparatory move followed by a tactic.

Zugzwang recognition and engineering. Capablanca’s endgame technique included acute recognition of zugzwang — not a merely cramped position, but the specific condition that every move available, including the best one, makes things worse than standing pat would. A structural proxy for the precursor condition is implemented (§8.11, approxZugzwang): in the endgame, an opponent with very few legal replies is scored as more likely to be obligated, at no extra cost beyond a value getBestMove already computes for its stalemate check. This is restriction, not recognition — it rewards cramped positions whether or not every move in them actually loses, and proves nothing about any specific position. Genuine recognition would mean comparing the opponent’s stand-pat evaluation against their actual best reply, which requires running the engine’s own move-selection pipeline a second time from the opponent’s side — one real ply of lookahead, deliberately not built outside that single narrow, documented exception. Zugzwang engineering — triangulation, opposition, corresponding squares, deliberately losing a tempo to hand the obligation to the opponent — is a different problem again: it requires reasoning about sequences of future positions, not just the next one, and remains entirely out of scope. Both the deeper recognition and the engineering are problems that require either a perfect evaluation function or sufficient search depth.

Prophylaxis. Capablanca routinely anticipated and pre-empted the opponent’s plans. Principles 5b and the development gate implement the most directly formalizable prophylactic behaviors; deeper plan-anticipation — recognizing that the opponent intends a maneuver three moves from now and pre-empting it quietly — remains beyond one-ply evaluation.

11. Conclusion

Raumcapa is, to the best of the present author’s knowledge, among the first chess engines of any kind to rely entirely on positional principles and influence fields, with no minimax search tree and no neural network. It operates by projecting φ(d) = 1/(1+d) Chebyshev-decayed influence across the 5×5×5 board, selecting candidates by ten named principles — including a Capablancan development gate that prevents moving the same piece twice while others remain undeveloped, and a structural test that admits pawn moves into the opening repertoire only when they open a line or claim central space — and evaluating by one-ply static assessment of fifteen Capablancan heuristics: material; pawn structure (with rank-doubled, level-doubled, and apex-doubled penalties, isolated pawn, quadratic passed-pawn bonus, and Tarrasch rook-behind-passer); hanging pieces, unfavorable exchanges, and veiled threats; a contextual exchange threshold encoding material trajectory, king safety asymmetry, piece activity, and open-line monopoly; piece coordination; center control; king safety and activation with cut-off technique; unicorn 3-parity; bishop color pair; open and half-open lines; outpost squares; material simplification; an opening piece-development bonus; an endgame mobility-restriction proxy approximating zugzwang; and a repetition-contempt adjustment that discourages repeating a position when ahead and welcomes it otherwise.

Its advantages are speed, transparency, and a recognizable positional style. Its disadvantages are tactical blindness and a bounded strength ceiling. For Raumschach specifically — a game with a high branching factor, nascent theory, and no large corpus of master games — these trade-offs are defensible. The engine plays chess that can be understood, discussed, and learned from. That is a different goal from playing chess that wins, and it is a goal Capablanca himself would have recognized.

He was, after all, the world champion of Raumschach’s own prime decade.

12. References

Capablanca, J. R. (1921). Chess Fundamentals. New York: Harcourt, Brace and Company.

Capablanca, J. R. (1935). A Primer of Chess. New York: Harcourt, Brace and Company.

Dickins, A. S. M. (1971). A Guide to Fairy Chess. New York: Dover Publications.

Maack, F. (1907). Das Schachraumspiel: Dreidimensionales Schachspiel. Hamburg.

Shannon, C. E. (1950). Programming a computer for playing chess. Philosophical Magazine, 41(314), 256–275.

Silver, D., et al. (2017). Mastering chess and shogi by self-play with a general reinforcement learning algorithm. arXiv:1712.01815.

International Raumschach Federation. (2026). Maackesgeist: A Raumschach Engine (Version 2). maackesgeist-v2.html

Source code: raumschach.html (2026). International Raumschach Federation. raumschach.org/raumschach.html

Source code: studio.html (2026). International Raumschach Federation. raumschach.org/studio.html