I recently build a chess engine using javascript (https://github.com/Ram-the-coder/ai-chess-engine-v2). It runs on the browser - because of this when the chess engine is computing the best move, the webpage gets unresponsive. So I thought if I move the processing to the server, then I can eliminate the unresponsiveness. But if I do that then I've to maintain the game state for each client of the server. The size of the game state I think is in mega bytes as it includes the hash tables.

Another problem I faced in keeping the processing on the client-side is that the processing speed becomes dependent on the client's device.

How are such online chess engines usually built?

I don't think storing the game state in memory is good as the server has to serve many clients. Maybe storing in a database in the same server might work...

If I use a client-server architecture, won't I be restricted to serve one client request per server at a time? If yes, how are online chess engines able to serve unlimited clients at the same time?

  • 1
    usually UCI chess engines (which can be run online) use a separate thread for the search. It totally depends on the hardware it is running on. But if its js, I assume its running on the client computer, right? So you should try to use a separate thread. – Finn Eggers Jun 9 '20 at 6:04
  • I thought multi-threading in the browser was impossible. Upon some searching, I just found web workers. Maybe I should use that. Thank you. – Ramvardhan Jun 9 '20 at 7:29
  • 1
    Even before web workers, you could do a tiny amount of work, then post an event to do the next step, emulating "cooperative multithreading". – Mooing Duck Jun 9 '20 at 20:53

WASM defines how an engine is compiled but not how it runs. Browser chess engines always run on a web worker in JavaScript.

Sample code for running a chess engine on web browser:

const x = new Worker('/stockfish.js')
  • You shouldn't unconditionally run stockfish.js. As the documentation states, you should test whether the browser supports Wasm, and then run either stockfish.wasm.js or stockfish.js, as appropriate. And if you run stockfish.wasm.js, it will use the browser’s native Wasm support to run the file stockfish.wasm. – Stephen Jun 9 '20 at 14:28

Lichess uses WebAssembly (Wasm) - as is stated on the analysis page (“Stockfish 10+ WASM in local browser”). Wasm is the obvious thing to use, as it runs on the client side but is faster than JavaScript.

Running Stockfish in a web browser is usually done using Niklas Fiekas’ Wasm+JavaScript port of Stockfish, which is what Lichess uses. This consists of a Wasm file stockfish.wasm containing the engine itself, and a smaller JavaScript file stockfish.wasm.js that controls the use of the engine. (There is also a large file stockfish.js that is used as a fallback on browsers that lack native Wasm support.)

  • Wow nice. I'll look into it. Thanks. – Ramvardhan Jun 9 '20 at 7:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.