The Abstract Play back end is built with TypeScript, and the front end is vanilla JavaScript with React. The fundamental hosting framework is Amazon Web Services (Cognito for user management, DynamoDB as the database, Lambda and API Gateway for the back end, CloudFront et al. for the front end).

Abstract Play is open source. All the code can be found on GitHub. We welcome the contributions of other developers. Visit the #dev-curious channel of our Discord server to ask questions.

• front: This is the React/JS code that powers the front end.
• gameslib: This is where the code for each supported game lives.
• renderer: This is the code that generates the SVG board images. Each game produces a JSON object describing the board, and the renderer renders it to SVG.
• node-backend: This is the code that bridges the front end and the database.
• recranks: This relatively tiny repository houses the game record schema and the code that calculates batch ratings.
• aiai: This Java code runs the Ai Ai bot.

There are also a couple ancillary repositories not directly related to the site itself:

• designer: This is a site that allows game designers to tinker with the rendering engine with the goal of testing out new game designs. It is coded in Svelte.
• zendo: A client for playing synchronous Zendo games over the web, also coded in Svelte.

The most common contribution people want to make is to add a new game to the site. In the gameslib repository is a /docs folder with some basic documentation, including a new game “template” with internal comments explaining how things are structured. Always feel free to join us in the #dev-curious channel on Discord to ask questions. We can at the very least point you to other games that exemplify certain features.

Definitely visit the Renderer Playground to see the sorts of the thing the renderer can do and how to structure your JSON.

The preferred workflow is as follows:

• Fork the gameslib repository and do your work in the develop branch.
• Create your game and add the appropriate lines to src/games/index.ts. Don't forget to add the experimental flag to your new game.
• Consider adding unit tests where appropriate (see test/games).
• Test your game as best as you can locally, using command-line tools (see bin/example.ts) and the the locally hosted playground (more information below).
• When you're ready for live testing, submit a pull request against the develop branch.
• When the developers merge it, test the game on the dev server.
• Repeat the PR → merge → test cycle until everyone is happy with the game.
• Devs will ultimately push it to production and announce it.

In the gameslib repository is a playground folder with an index.html file, which can be hosted locally for basic game testing. You can see an example of how it works at http://gameslib.dev.abstractplay.com/.

To do this, you need a few things:

• A LAMP stack or equivalent for your platform that will let you serve webpages locally.
• A copy of playground/index.html.
• A copy of APRender.js, produced either from compiling the renderer repository or downloading from the the renderer playground (http://renderer.dev.abstractplay.com/APRender.js).
• A copy of APGames.js, produced by compiling the version of the gameslib repository with your game included.

Place all those somewhere your LAMP stack can see them, and you can then launch games and do basic testing locally.