8

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?

Improve this question
3
  • 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, 2020 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.
    – Ram
    Jun 9, 2020 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, 2020 at 20:53

2 Answers 2

Reset to default
3

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')
x.postMessage("uci")
Improve this answer
1
  • 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, 2020 at 14:28
8

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.)

Improve this answer
1
  • Wow nice. I'll look into it. Thanks.
    – Ram
    Jun 9, 2020 at 7:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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