Skip to content


Switch branches/tags

Name already in use

A tag already exists with the provided branch name. Many Git commands accept both tag and branch names, so creating this branch may cause unexpected behavior. Are you sure you want to create this branch?

Latest commit


Git stats


Failed to load latest commit information.
Latest commit message
Commit time


Play it here

  • A 100% client-side implementation of Checkers that runs in modern web browsers.
  • Graphics and animations are rendered as SVG elements in the browser DOM.
  • Supports Human vs. Computer, Human vs. Human (hot seat), and Computer vs. Computer games.
  • Written in Scala.js.


  • Jumps are compulsory. As long as you have an opportunity to capture, you must take it.
  • If a piece can continue to jump once it has jumped, it must do so in the same turn.
  • If there is more than one alternative for capture, you may choose which one to take. It need not be the path that takes the most pieces.
  • When a checker is kinged, the turn automatically ends, even if the king can continue to jump.
  • If an exact board position is repeated a third time, the game automatically ends in a draw.
  • If 50 moves have taken place (for both players) since the last capture or advancement of a regular checker, the game ends in a draw.

Known issues

  • Some of the SVG elements in the user interface do not render correctly in iOS Safari.

Build instructions



Initial setup

cd checkers

pnpm install

Development session

In one terminal: pnpm run dev

Once the development server is up and running, you can optionally support live reloading while editing the Scala code. To do so, open a second terminal and run: sbt ~fastLinkJS


To build the finished product for production (in the dist directory): pnpm run build

To preview the production build: pnpm run preview


  • macros - Since Scala requires separation compilation of macros, all macro definitions go here
  • benchmarks - Build and run them using pnpm run benchmark

Implementation notes

  • Most user interface components, including the game elements and the user interface chrome, are composed of SVG elements. The exception is the new game dialog, which has some HTML 5 elements as well. React is used throughout the user interface.
  • The board is represented internally using three 32-bit integers: one for dark pieces, one for light pieces, and one for kings. Thanks to this article for the idea.
  • Computer players use alpha-beta search combined with iterative deepening. An endgame tablebase is not employed (yet), as this game is client-side only, and introducing a tablebase would significantly increase resources required of the browser.
  • Everything is done in a single thread (no web workers are used). While the computer player is thinking, it is given time slices from the event loop until the computation is complete.
  • The difficulty level of a computer player determines, among other things, the maximum number of evaluations per turn the computer player is allowed before having to yield a move. While slower computers will take longer to calculate a move, they will ultimately arrive at the same conclusion on a faster computer, all else being equal.
  • The computer doesn't always attempt for a perfect play. Lower level computer players have a higher chance of making a artificial blunder.
  • In some parts of the search tree, move order is shuffled (for moves other than the move the computer already thinks is best). This causes the computer to examine the same tree in a different way, so it may come to a different conclusion in situations where each alternatives' value is similar. This is done to introduce some variety into the computer's play, in the hopes of making it more or less as effective without being as robotic.
  • The computer can be rushed by the user. Shortly after being rushed, it will yield the move it thinks is the best from what it has seen so far. This is possible due to the computer player keeping track of the "principal variation" (what is thought of as the best sequence of moves), which evolves through the search process.
  • As an optimization, macros are used extensively throughout the project. The implementations of these macros are simple constants or bit-wise expressions. Since they are used in the same manner as C preprocessor macros, by convention they all have uppercase names (e.g. DARK, LIGHT, SHIFTNW).


Thanks to the authors and contributors of the following high-quality projects that were used in the creation of this game:

  • Scala.js - Scala to JavaScript transpiler.
  • React
  • scalajs-react - An incredibly flexible Scala.js binding to React.
  • scalajs-spa-tutorial - This is more than a tutorial -- it is a very good foundation for building non-trivial Play/Scala.js projects.


Copyright 2016 Kevin Schuetz

Apache 2.0 License


No releases published


No packages published