01 / Route

For my projects, compare AlphaZero and NNUE first

If the goal is to build an AI that is genuinely strong, arrives quickly, and can keep improving, my experience says that choosing the right route matters more than polishing local tricks at the start. In the projects I have worked on, the first comparison worth making is usually an AlphaZero-style route versus an NNUE-style route.

AlphaZero

This route pairs a relatively large neural network with search, accepting some loss of speed in exchange for higher representational capacity and a more dependable ceiling.

I value its generality: once the rules can be integrated, many two-player zero-sum games can be trained competitively with the same overall paradigm.

NNUE

NNUE leans toward a small network with extremely fast evaluation, pursuing strength through speed, feature design, and search engineering.

It is very strong in some mature games. In my transfer experience, however, a new game usually calls for more hand-designed features and search work.

My choice: unless I am optimizing CPU software for one game, I usually prefer AlphaZero when the aim is to cover many games, variants, or original rules. For those goals it has been more general and dependable in my projects, and the total engineering work is often lower than designing a separate NNUE pipeline for every game.

02 / Infrastructure

KataGo is my preferred efficient AlphaZero foundation

Understanding AlphaZero does not give you an efficient implementation. When building from scratch, any weakness in self-play, parallelism, sample efficiency, the training pipeline, or inference can consume a large amount of performance.

Why it matters

KataGo has already refined many engineering details, making it possible to reuse mature search, self-play, and training infrastructure.

The difference I observe

Compared with a basic AlphaZero implementation built from scratch, KataGo often removes a great deal of search, self-play, and training overhead. The difference still depends on the game, hardware, search budget, and target strength. A fair efficiency comparison should record GPU hours required to reach equal strength on the same hardware and evaluation set.

Immediate benefit

Reusing this foundation lets me spend more time on rules, data quality, network architecture, and compute instead of rebuilding infrastructure first.

03 / Representation

KataGo is not limited to alternating placements

KataGo is not restricted to the standard form in which two players alternate placing stones on empty points. Games such as Xiangqi and chess, where one move includes both selecting a piece and choosing its destination, can also be handled with a similar framework.

For prototypes, my most common and least expensive approach is to split one move into two steps: select the piece, then select its destination. This decomposition is not guaranteed to be theoretically optimal. In my experience, it usually keeps the strength loss acceptable while lowering the integration barrier substantially.

When the goal is to validate a family of rules or build a prototype quickly, I think decomposition is well worth using. See rules integration for the concrete state representation and network inputs.

04 / Scaling

Money Is All You Need—but returns diminish

In my training experiments, playing strength often grows approximately logarithmically with training volume. This does not mean that further training is useless: doubling the training volume can still add rating, but the improvement per unit of compute gradually falls.

For many complex games that remain unsolved, I have not observed a clear practical endpoint. While the data, search, and network keep improving, Elo often has room to rise. This is an empirical trend, not a promise for every game and training configuration.

My engineering judgment is therefore that the ceiling is usually determined less by one clever trick than by whether the route is appropriate, the implementation is efficient, and the project can sustain continued training.