The Open Source Board Engine Ecosystem
A board engine is three layers: rules, referee, and search. Here is how the open source board game engine ecosystem fits together, where Gomoku and chess engines live on GitHub, and what web projects change.
A browser board game feels like a single object. Underneath, an open source board game engine is three: the rules, the referee, and the search that picks a move. That split is why the same vocabulary turns up in a chess program from 2005 and in a web app shipped last month. yiboardgame.com runs on the same shape, so it works as a reference point for naming the parts.
What a board engine actually does
An engine is not the board you see. It is the machine that answers two questions: is this move legal, and which legal move is best. The graphics, the sounds and the scorekeeping all sit above it. When someone says they are building a board game, they often mean they are building the layer above an engine they borrowed.
The rules and referee layers are the ones people underestimate. They also decide whether a project is pleasant to build on, because a wrong legal move is a bug you find the same day, and a wrong win condition is a bug you find a month later.
The three layers in every project
Repositories sort themselves into the same three layers even when the folder names do not say so. Reading a new project is mostly a matter of working out which layer you are looking at.
- Rules. Legal move generation for one game. Short, easy to test, usually the oldest file in the repository.
- Referee. Turns two players' moves into a position, then decides wins, draws and repetition.
- Search. The move chooser. Chess engines live here, and so does every Gomoku opponent you have played.
- Presentation. The browser or desktop shell that draws the board and sends input back down.
Open source chess engine code is the best teacher
If you want to understand the search layer, read a chess engine. Chess has more open source work than any other board game, and the ideas travel. Alpha-beta pruning, transposition tables and iterative deepening were worked out on chess first, then reused everywhere else. A Gomoku engine runs the same pruning; it simply has a smaller branching factor and a shorter game to finish.
The lesson is that a small game is not a toy version of a big one. It is the same algorithm with fewer branches, which makes the code shorter and the tests simpler.
Gomoku engine repos on GitHub
Searching for a gomoku engine on GitHub returns coursework, research code and a few maintained libraries mixed together. The useful difference between them is not how clever they are. It is what each project agreed to be responsible for.
- Rules only. Legal moves, no opponent. Good when you are building a two-player app.
- Rules plus search. Playable against the machine, with strength set by search depth or a time budget.
- Rules plus search plus interface. A finished product you can run, and harder to reuse inside your own code.
- Training code. Teaches a network to score positions, and asks for a GPU plus patience.
- Library. No interface at all, written to be imported.
A repository that explains its rules in the README and keeps search behind a clear interface is easier to reuse than one that blends everything into a single main file. That boundary is the best signal of whether a project will survive contact with your own code.
What web game open source projects change
Browser projects add two constraints a desktop engine never had. A web game open source release has to run inside a tab, and it has to start quickly on a phone. Those constraints change design choices more than they change algorithms.
- No install step, so the engine ships as JavaScript or WebAssembly.
- No background process, so a long search gets a time budget instead of running to completion.
- No server assumption, so rules and opponent often run entirely on the device.
- No purchase channel, so there is nothing to place behind a paywall.
A search budget of a few hundred milliseconds is the usual compromise. It is enough for a strong beginner opponent, and short enough that the board still feels immediate.
It is also why browser engines lean toward simple evaluation functions. With a small budget, good move ordering beats a smarter but slower score.
If you want to see how the three layers behave in a finished product, the about page describes how yiboardgame.com separates them. Product questions are covered in more detail on the FAQ page.
FAQ
Is an open source board game engine the same as a chess engine?
No. A chess engine is one well-known case of the search layer. Board engines also exist for Gomoku, Reversi and Go, and they share most of the same techniques.
Do I need to write my own rules code?
Usually not. Rules for common games are well covered, and writing them from scratch is where small projects lose their first month.
Can a browser engine play well?
Yes, up to a point. WebAssembly and a tight time budget make a solid opponent, though not a tournament-grade chess engine.
Where should I start reading?
Open an engine for a game you already know how to play. Understanding the game removes half the confusion before you reach the code.