Research Report on the History of Computer Chinese Chess (Xiangqi) Game-Playing

Chapter 13 Other NNUE-Era Open Source Engines

13.1 Orange Engine

Orange is an NNUE open source engine independently developed by the Xiangqi community, created by developer Daniel Tan (primary author). Orange’s distinctive feature is that it is not adapted from the Stockfish codebase, but is an independent engine implemented from scratch.

Technical Features of Orange:

• Complete UCCI protocol support
• Multi-layer NNUE evaluation network (2 hidden layers, instead of the standard Stockfish NNUE’s 1 hidden layer)
• PVS search algorithm, incorporating common pruning techniques in modern search
• Configurable training system, supporting custom NNUE network training

Orange License:

Orange uses a custom open source license. According to the project’s GitHub page, Orange’s code may be freely used, but it is strictly forbidden to rename the engine and republish it as an “original” work.

Daniel Tan’s Research Work:

Daniel Tan not only developed the Orange engine but also studied NNUE feature design for Xiangqi at an academic level. He co-authored the paper “Study of the Proper NNUE Dataset” with Neftali Watkinson Medina, exploring feature selection issues in NNUE training datasets. The paper was published at an international academic conference (IEEE Conference on Games 2024), demonstrating that academic research on Xiangqi NNUE engines is gaining international recognition.

13.2 Fairy-Stockfish’s Xiangqi Support

Fairy-Stockfish is a derivative version of Stockfish, specifically designed to support various chess variants (Fairy Chess Variants). Fairy-Stockfish includes Xiangqi rules among its supported variants.

Although Fairy-Stockfish’s Xiangqi implementation is primarily intended for chess variant enthusiasts and researchers, it represents Xiangqi’s position within the broader scope of chess game research — Xiangqi is treated as a type of “chess variant,” capable of sharing technical frameworks with standard chess.

Fairy-Stockfish’s Xiangqi support is not its core function, but rather part of a series of variant supports. However, its existence demonstrates that Xiangqi rules can be incorporated into the variant engine framework of chess engines, providing a technical foundation for cross-domain knowledge transfer.

13.3 Other Community-Driven Developments

In addition to the projects mentioned above, several community-driven Xiangqi NNUE attempts emerged after Pikafish:

Xiangqi Cyclone (Cyclone-nn):

After entering the NNUE era, Xiangqi Cyclone also switched to a “Stockfish+NNUE” architecture. Cyclone’s NNUE version is called “Cyclone-nn” on the Fishtest testing platform. Cyclone-nn represents the attempt of commercial engines to transition from traditional architecture to NNUE architecture.

Continuous Emergence of Community Engines:

On GitHub, searching for keywords such as “chinese-chess,” “xiangqi,” and “cchess” reveals dozens of Xiangqi engine projects of varying scales. Most of these projects follow the “Stockfish adaptation” route, but some also explore other technical approaches.

13.4 BitStronger and Other Community Engines

BitStronger is an open source engine improved from the ElephantEye codebase. It made several improvements under ElephantEye’s LGPL license:

• Redesign and optimization of the evaluation function
• Parameter tuning of search algorithms
• More efficient position representation and move generation
• Initial attempts at multi-core support

Although BitStronger’s playing strength does not match commercial engines, as a derivative of ElephantEye, it demonstrates the feasibility of the “fork-improve” model enabled by open source licenses — an early experiment of the successful model later adopted by Pikafish.

13.5 Qilu Lite and the Pikafish Ecosystem

Qilu Lite was created by developer He Zhaoyun in October 2022, and was one of the earliest projects to package the Pikafish engine into a usable chess software. Qilu Lite itself is also released under the GPLv3 license and is an important part of the Pikafish ecosystem.

Qilu Lite’s contributions are:

1. Provided a directly runnable user interface
2. Lowered the barrier for ordinary users to use Pikafish
3. Validated Pikafish’s practicality on mobile and desktop platforms
4. Provided a reference for subsequent Pikafish-based software (such as Xiangqi Gongshe, etc.)

13.6 Cross-Domain Participation from the Chess Community

In recent years, some developers from the chess community have also participated in Xiangqi engine research. Their participation has brought different technical perspectives:

• Contributions to NNUE Feature Design: Chess NNUE design experience (such as the HalfKP feature set, incremental update strategies) provided direct reference for Xiangqi NNUE.
• Sharing of the Fishtest Platform: Pikafish’s Fishtest platform was initially based on Stockfish’s Fishtest codebase, sharing much of the underlying architecture.
• Migration of Compilation Optimization Techniques: Optimization experience for modern CPU instruction sets (AVX2, BMI2, AVX512, ARM NEON, etc.) was migrated from the chess community to the Xiangqi community through community contributors.

13.7 The Open Source vs. Closed Source Game: Shifting Community Power

The open source vs. closed source struggle in Xiangqi engines has gone through three stages:

Stage 1: Closed Source Monopoly Period (1980s–early 2000s)

During this stage, almost all engines were closed source. Developers treated engines as personal intellectual property and commercial products, with source code not publicly available. The only exceptions were some engines produced in university research projects (such as Qi Tian Da Sheng), but their code was also not publicly released.

Problems in this stage included:

• Technology dissemination relied entirely on the developer’s personal willingness to disclose
• When developers stopped updating their engines, their technical accumulation also disappeared
• Later developers could not learn from predecessors’ work and had to “reinvent the wheel”

Stage 2: Open Source Exploration Period (2005–2020)

Marked by ElephantEye’s open sourcing, some developers began experimenting with the open source model. Huang Chen’s decision to choose the LGPL license was very wise — it both ensured free use of the code and allowed commercial projects to use the code under license conditions.

However, during this stage, the playing strength of open source engines was still far below commercial engines (typically a gap of 500-1000 ELO or more), so open source engines were mainly used as learning tools rather than practical weapons.

Stage 3: Open Source Disruption Period (2022–Present)

The emergence of Pikafish completely overturned the power structure. When open source engines surpassed or matched commercial engines in playing strength for the first time, the power structure of the entire community underwent a fundamental change:

• From “commercial-driven” to “community-driven”
• Contributors expanded from “individual enthusiasts” to “global developers”
• Technical decisions shifted from “authoritarian author” to “community consensus”

The profound impact of this change continues to unfold.

---

Chapter 14 Cloud Computing and the Data Revolution

14.1 The Birth and Architecture of the Xiangqi Cloud Book

The Xiangqi Cloud Book (chessdb.cn) is the most influential online database project in the field of Xiangqi. It provides large-scale opening book and endgame tablebase query services, and is an indispensable piece of infrastructure for Xiangqi engines and interface tools.

Birth of the Cloud Book:

The Xiangqi Cloud Book was built and maintained by a series of community contributors. Its initial idea came from dissatisfaction with the “everyone fends for themselves” situation in Xiangqi opening books and endgame tablebases — each engine had its own opening book, but they could not share and update data with each other.

The Cloud Book adopts a server-client architecture:

• Server side: Stores opening book and endgame tablebase data, providing Web API interfaces
• Client side: Connects to the Cloud Book through interface tools like Binghe Wusi to query game data

Scale of Cloud Book Data:

According to the Cloud Book official website, as of 2026, the data scale of the Cloud Book is extremely large:

• Opening Book: Contains approximately 2,000,000 opening moves
• Endgame Tablebase:
  • DTM version (Distance to Mate): 15.71 TB
  • DTC version (Distance to Conversion): 2.08 TB
  • Total exceeds 17 TB

Cloud Book Data Quality:

Cloud Book data quality is ensured through the following mechanisms:

1. Automatic Verification: Correctness verification is automatically run after each data update
2. Community Review: Community members can report errors or inconsistencies
3. Version Control: Data versions are traceable and support rollback

14.2 Impact of Cloud Book Usage on Engine Strength

The emergence of the Cloud Book changed engine performance in the opening and endgame phases. Engines using the Cloud Book can, in the opening phase:

• Precisely select the best opening moves (based on statistics from millions of high-level games in the Cloud Book)
• Avoid playing opening variations already proven disadvantageous
• Learn new variations from the Cloud Book (including master-level theoretical innovations)

In the endgame phase, the Cloud Book allows engines to play precise “optimal moves” in known endgames, including the shortest checkmate path.

Improvement in Engine Practical Performance from the Cloud Book:

The introduction of Cloud Book data has a significant impact on engine strength. Before and after using the Cloud Book, the same engine’s win rate may improve by 5-10 percentage points (under the same hardware and search settings). This improvement is mainly reflected in:

• Reduction of non-combat losses in the opening phase (avoiding disadvantageous openings)
• Improved “precision” in the endgame phase (not taking detours in advantageous or equal endgames)

14.3 Cloud Endgame Tablebase

Principles of Endgame Tablebase Generation

The Xiangqi endgame tablebase is generated using Retrograde Analysis:

1. Starting from terminal positions: Enumerate all positions where one side checkmates or stalemates the opponent (winning positions).
2. Backward reasoning: From winning positions, reason backward to find all positions that can reach a winning position in one move.
3. Label distances: Label each position as “win” or “draw,” and record the minimum number of moves to checkmate (DTM, Distance to Mate) or the minimum number of moves to decisive material conversion (DTC, Distance to Conversion).
4. Iterative expansion: Continuously add pieces, gradually building more complex endgames.

Detailed Process of Retrograde Analysis:

The starting point of retrograde analysis is “basic endgames” — those with the fewest pieces and already determined results. For example, a position with only a lone general against a lone general is almost always a draw (unless one side is checkmated or stalemated). Starting from these basic positions, the algorithm gradually adds pieces to compute results for more complex positions.

Specific steps:

1. Enumerate material combinations: Determine the material combination to compute (e.g., “Rook+Horse+Advisor vs. Rook+2 Elephants”), enumerate all possible piece layouts under that combination.
2. Label basic positions: Among all layouts, label those that are already checkmate or stalemate positions (basic winning positions).
3. First round of backward reasoning: For each “non-basic position,” check if there is a move that reaches an already labeled winning position. If so, label that position as a “win” and record the optimal move.
4. Second round of backward reasoning: Check if there are non-basic positions where all opponent’s moves lead to “winning positions”… and so on, until all labelable positions have been processed.
5. Label remaining positions: Positions that still cannot be labeled after complete retrograde analysis are “draws” or “unknown.”

Why Retrograde Analysis Is Extremely Resource-Intensive:

The complexity of endgame tablebase computation grows exponentially with the number of pieces. Taking a single chariot (Rook) vs. full advisors and elephants as an example:

• All possible positions of the chariot (Red side): 90 intersection points
• All possible positions of the general (Red side, within the palace): approximately 10 positions
• All combined positions of 2 advisor pieces (Red side)
• All combined positions of elephant pieces (Red side)
• Opponent’s pieces also need to be considered

For high-difficulty endgames such as “Chariot+Horse+Advisor vs. Chariot+2 Elephants,” the number of possible positions can reach billions or even trillions. This is why the Cloud Book’s endgame tablebase has reached 15.71 TB (DTM version).

Relationship Between Endgame Tablebase and Practical Play:

The impact of endgame tablebases on practical play is revolutionary. Within the coverage of the endgame tablebase, engines can:

• Precisely know the win/draw result of each position
• Play the optimal move in any position
• Precisely calculate the minimum number of moves to checkmate
• Take no detours in winning positions, directly taking the shortest path to victory

Scale of the Xiangqi Cloud Book’s Endgame Tablebase:

According to the Cloud Book website (chessdb.cn), as of 2026:

The material combination coverage of the endgame tablebase includes:

• Full material (all 7 piece types): extreme cases
• Multi-piece combinations: Chariot+Horse+Cannon, Chariot+2 Horses, 2 Chariots, etc.
• Low-piece combinations: Chariot+Pawn, Horse+Pawn, Cannon+Pawn, etc.
• Basic endgames: Lone elephant, lone advisor, Horse beats lone advisor, etc.

14.4 Impact of the Cloud Book on the Community

The Cloud Book not only changed how engines are used but also altered the collaboration model of the Xiangqi community. Collaboration with the following characteristics became possible:

1. Data Sharing: Community members can jointly expand and improve opening book and endgame tablebase data.
2. Automatic Updates: Engines no longer need to manually update opening books; all data synchronization is done automatically through the Cloud Book.
3. Version Management: Data versions are traceable, supporting rollback and branching.
4. Open API: Third-party tools can query and participate in data maintenance through API interfaces.

14.5 NNUE Evaluation vs. Traditional Hand-Crafted Evaluation: In-Depth Comparison

The introduction of NNUE evaluation is one of the most revolutionary technological changes in the history of Xiangqi engines. The following is an in-depth comparison from two dimensions: technical implementation details and practical effects.

Note: NNUE is not perfect. It requires large amounts of high-quality training data, powerful GPUs for training, and CPUs supporting SIMD instruction sets such as AVX2 for efficient inference. On low-end hardware, traditional hand-crafted evaluation still has a speed advantage. However, overall, the strength improvement brought by NNUE is decisive, and all top engines have switched or are switching to NNUE architecture. It is worth noting that NNUE and HCE are not mutually exclusive — the best practice is NNUE evaluation as the primary method, with HCE as a supplement or fallback.

14.6 Comparison of Xiangqi Engine Business Models and Licensing Methods

The commercialization model of Xiangqi engines has evolved from boxed software to online licensing to open source free. Different business models reflect changes in market environment, user demand, and technical conditions:

Note: The commercialization of Xiangqi engines has always faced the triple challenge of a small user base, weak willingness to pay, and severe piracy. The boxed software era ended due to internet piracy; the online licensing model, though improved, still faces cracking and sharing problems. The open source model (represented by Pikafish) provides a new direction — reducing development costs through community collaboration, achieving distributed quality assurance through the Fishtest framework, and relying on the GPLv3 license to prevent closed-source commercial abuse. The current trend is: top-strength engines are moving toward open source, while commercial engines differentiate through value-added services (opening books, cloud books, technical support).

14.7 Comparison of Three Major Technical Routes: PVS+HCE vs. MCTS vs. NNUE

Three major technical routes have appeared in the development history of Xiangqi engines. Understanding the pros and cons of each is key to grasping the direction of engine technology evolution:

Note: The competition among the three routes has essentially been decided — PVS+NNUE is currently the undisputed optimal solution. The MCTS route achieved great success in Go (AlphaGo/Zero), but has not surpassed PVS+NNUE in Xiangqi. The main reason is that Xiangqi’s branching factor (approximately 40) is much lower than Go’s (approximately 250), making PVS’s pruning efficiency far higher than MCTS’s sampling efficiency. Although the traditional PVS+HCE route dominated the engine world in the 2010s, the accuracy ceiling of hand-crafted evaluation has been thoroughly broken through by NNUE.

Chapter 15 Integration of AIGC Engines and AI Technology in Xiangqi

15.1 Impact of AIGC on Xiangqi

AIGC (Generative AI) impacts Xiangqi mainly at two levels:

AI-Assisted Content Generation: High-quality Xiangqi engine analysis no longer requires specialized software. Community versions of open source engines like Pikafish provide game analysis far exceeding human levels.

Education and Training: With engine APIs and big data analysis, Xiangqi education tools can generate personalized training plans, automatically adjusting training difficulty and content according to the learner’s level.

15.2 Integration of Engine APIs and Online Analysis Platforms

The opening of engine capabilities enables various online platforms to integrate chess analysis functions. A typical architecture includes:

User (Web/Mobile APP)
→ Frontend (React/Vue interface)
→ Backend (API Server, e.g., Nginx)
→ Engine Container (running Pikafish, etc.)
→ UCCI Protocol Communication
→ Engine Calculation Engine (parallel search + NNUE evaluation)

Implementing this architecture requires solving the following technical issues:

1. Engine process management (start, stop, timeout control)
2. Queuing and scheduling of concurrent requests
3. Allocation of engine and GPU resources
4. Result caching strategies

15.3 Outlook for AI Technology in Xiangqi

The outlook for AI technology in Xiangqi includes:

1. Lighter Deployment: With continuous optimization of NNUE networks and improvements in hardware efficiency, engines approaching top-level strength can run on lightweight ARM devices or even in browsers. The application of WebAssembly (WASM) technology makes it possible to run a full engine in the browser.

2. Personalized Analysis: Based on large language model technology, natural language-level game analysis and interaction can be realized. Users can ask engine analysis questions in natural language (such as “What should I play here?” or “What is the key point of this position?”), and the engine returns natural language explanations after analyzing the board.

3. Cross-Domain Research: Cross-disciplinary research combining Xiangqi engine technology with AI subfields such as reinforcement learning, transfer learning, and few-shot learning has broad prospects. Xiangqi’s unique characteristics (handling of cyclic moves under different rules, the uniqueness of the Cannon, etc.) provide interesting research topics for AI technology.

4. Real-Time Game Analysis: With the development of cloud computing and edge computing, real-time high-level game analysis will become widespread. Future online game platforms can provide master-level analysis immediately after each move, including the best move, key variations, tactical combinations, and more.

---

Chapter 16 Endgame Tablebase Verification: Data Validation and Accuracy Issues

16.1 Database Completeness Issues

During the development of the Xiangqi Cloud Book, problems of incomplete and erroneous endgame tablebase data emerged. These issues originate from:

1. Limitations of the generation algorithm: Although retrograde analysis can theoretically accurately compute all endgames, when faced with extremely complex positions, due to computational resource constraints, omissions or errors may occur.

2. Storage errors: During the background storage and management of over a dozen TB of data, storage errors or data corruption may occur.

3. Differences between rule systems: Asian rules and Chinese rules differ in handling cyclic moves; the endgame tablebase may only be adapted to one set of rules.

16.2 Community Collaboration on Data Correction

Data correction for the endgame tablebase is mainly accomplished through community collaboration. When community members discover, during engine analysis, that the endgame tablebase data does not match expectations (e.g., a winning endgame is displayed as a draw), they report it to the Cloud Book administrators.

Data correction process:

1. User reports a suspicious position
2. Administrator verifies whether the error exists
3. If the error is confirmed, initiate the recomputation process
4. Publish the corrected data to the Cloud Book
5. Verify the correction result

This community-participated error-correction mechanism is very important in large-scale data maintenance — automatically generated data cannot be 100% correct, and manual review and community feedback are key to ensuring data quality.

---

Chapter 17 The Artistic Value of Endgames and Game Records

17.1 Challenges of Classic Endgames for Engine Development

Xiangqi has a rich heritage of classic endgames, such as “Earthworm Subduing the Dragon,” “Seven Stars Gathering,” “Thousand Miles Alone,” and others. These endgames are characterized by few pieces but complex variations, usually containing exquisite tactical combinations and profound positional judgment.

The challenges classic endgames pose to engines are:

1. Depth of tactical combinations: Some classic endgames require very deep search to discover the correct move
2. Precision of evaluation: Precise evaluation of small-advantage positions requires extremely high-precision evaluation functions
3. Global perspective: Some endgames require a global rather than local understanding of the position

17.2 Performance of Modern Engines on Classic Endgames

Modern NNUE engines (such as Pikafish) perform significantly better on classic endgames than traditional hand-crafted evaluation engines. The NNUE evaluation network can learn pattern recognition and tactical judgment in classic endgames, even without explicit rule encoding:

• For profound endgames like “Earthworm Subduing the Dragon,” modern engines can quickly discover the correct move
• For large-scale endgames like “Seven Stars Gathering,” modern engines can provide accurate analysis and variations

17.3 Digitization of Game Records and Cultural Preservation

The digitization of Xiangqi game records is of great significance for cultural preservation:

1. Digitalization of traditional game records: Entering historical master game records and classic endgame scores into electronic systems
2. Annotation with engine analysis: Using engines to perform in-depth analysis of historical games, discovering new variations and annotations
3. Building game record databases: Establishing public, searchable game record databases

---

Chapter 18 Engine-Rule and Engineering Implementation of Game Rules

18.1 Strategies for Implementing Rules in Code

Implementing Xiangqi rules in an engine requires solving a variety of complex edge cases. The main rule implementation strategies include:

1. Move Legality Verification:

The engine’s move generator needs to verify whether each move complies with Xiangqi rules:

• Generals must not face each other
• The general’s movement range is limited to the palace
• The advisor’s movement range is limited to the palace diagonals
• The elephant’s movement is limited to its own side of the board, cannot cross the river, and must avoid having its eye blocked
• The horse must avoid having its leg hobbled
• The cannon’s capture requires exactly one piece (the “cannon mount”) between the cannon and the target
• Pawns/soldiers can only advance before crossing the river, cannot move sideways or backward; after crossing the river, they can advance or move sideways but cannot retreat

2. Special Rule Handling:

• Perpetual Check: The same side continuously checks, forcing the opponent’s general to move and then return to its original position. Under the rules, perpetual check is a prohibited move. The engine needs to detect this pattern and handle it accordingly.
• Perpetual Chase: The same side continuously threatens the same opponent piece with the same piece. Perpetual chase is also a prohibited move. The engine needs to distinguish between “perpetual chase” and allowed moves such as “perpetual block” and “perpetual exchange.”
• Check and Chase Alternating: One move of check and one move of chase alternating. Under the rules, this is a prohibited move.
• Check and Idle Alternating: One move of check and one non-threatening move alternating. Under the rules, this is an allowed move; the checking side must change their move.
• Double Attack with One Counter-Attack: One side makes two consecutive threatening moves, while the other side makes one threatening response in between. The engine needs to correctly handle this type of complex cycle.

3. Stalemate Handling:

In Xiangqi, stalemate (a side has no legal moves and is not in check) is ruled as a loss. This differs from chess, where stalemate is a draw. Stalemate detection requires the engine to correctly handle the absence of legal moves during search.

18.2 Implementation Differences Between Rule Systems in Engines

Asian rules and Chinese rules differ in the judgment of cyclic moves as follows:

Engines need to execute different judgment logic according to the user’s selected rules. Typically, engines provide a UCCI option for users to select “Asian Rules” or “Chinese Rules.”

18.3 Common Pitfalls in Rule Implementation

The following are some common pitfalls and edge cases in engine rule implementation:

1. Pitfalls in Implementing Generals Facing Detection: In some environments, detection of generals facing requires special attention — when the red general and black general are on the same file with no other pieces between them, they are considered to be facing, which is prohibited. However, if there is a piece (even one’s own) between the two generals, the facing is considered blocked.

2. Cannon Jump Capture Detection: The cannon’s jump capture requires precise detection of whether a “cannon mount” exists. The logic for cannon mount detection is: there must be exactly one piece (of either color) between the cannon and the target. This logic has no counterpart in chess and requires independent implementation.

3. Edge Cases for Pawns Crossing the River: After crossing the river, pawns can not only advance but also move sideways. However, pawns cannot retreat after crossing the river. The behavior of pawns on the river boundary needs special attention — once a pawn has stepped onto the opponent’s side of the board (rows 6-10), it is considered to have crossed the river.

4. Recording Cyclic Moves in Game Notation: When recording game notation containing cyclic moves, the type of each move (check/chase/idle, etc.) needs to be specially annotated so that it can be correctly parsed during subsequent review.

---