Just looking to play? All of this is already up and running for you to use over here!
The following outlines some of the changes I have planned, though it's likely not exhaustive. If there's anything not mentioned here that you'd like to see feel free to leave an issue. If you want to help out pull request are always appreciated, though I'd recommend reaching out especially when working on something from the list below simply to avoid any unnecessary cases of multiple people working on the same thing and someones work going to waste.
Currently an unexpected websocket failure just pops up an alert window informing of the event, no further handling or attempt at reconnection is made. This should of course be handled by trying to reconnect to the Archipelago server.
Chess puzzles are currently picked completely at random. Players may end up getting puzzles that are almost impossible to fail followed by ones that might feel like titled chess players could struggle to solve.
Instead, a player should be able to supply their Elo rating, so puzzles can be picked within a range around that. Since Elo rating somewhat depends on the exact format (as evidenced by popular chess platforms tracking player Elo separately for different categories), a players blitz rating might not be representative of their puzzle skills, so automatic adjustment based on the players performance would be worth at least considering.
People have different aesthetic preferences. For a first iteration I just stuck to default chessboard and pieces as provided by the libraries in use, however both are easily customizable and there is no reason to not let player pick whatever look they like best.
Additionally, the client already ships CSS for light and dark modes, but currently exclusively goes by the preference signalled by the browser. Allowing the user to override this is easy to implement, but since there's currently no preferences page I didn't do so yet.
When enabled send a death for failing a puzzle or have the puzzle reset when others send deaths via Archipelagos deathlink system.
Right now there are fixed chances to get certain categories of hints. 10% for a progression item, 20% for a useful item, otherwise a filler. If the rolled category doesn't have anything left to hint it'll drop down to the next. Once fillers are all hinted it'll instead give hints for traps and only when those too are all hinted will there be a chance to not receive a hint. Clearing a puzzle without a hint and clearing a puzzle without any wrong moves each add a 2.5% increase to the chance for a progression item hint, effectively reducing the chance for a filler (or trap) by up to 5%.
This should be made configurable with the Archipelago servers remote admin password similar to how APSudoku does this. When puzzles are rolled based on player skill rather than randomly throughout the entire databse, an option to give a player harder puzzles for better hints would be feasable as well.
Currently you get 3 lives for each puzzle, each wrong move costs you one life. Loosing the last one is considered failing the puzzle. This could be made customizable or possible to disable. To what degree this should be the players choice and when the remote admin password should be needed as a form of permission is to be determined.
The Lichess puzzle database, which I use for this project, tags puzzles with a variety of themes. Allowing a player to whitelist or blacklist specific puzzle themes would be easy to implement. Not sure if this should have limits though as I could see someone whitelisting only mate in one puzzles to game the difficulty systems planned. If limits are put in place they should probably be configurable with the remote admin password though.
To build the frontend you'll need NPM and SBT.
To host a production build you'll need to serve the build output using some webserver. (The server component does not serve the frontend)
Run npm install to set up the JavaScript dependencies
Just run npm run build. The build result can be found in target/dist/
For development you'll want to have both npm run dev and sbt ~web/fastLinkJS running. Some shells may need you to escape the ~ with a \
While both are running you'll get hot reload and recompiling as you edit the code.
All you need to build the server is SBT.
To run it you only need a JVM.
The server expects to find a config.json in its working directory containing credentials for a PostgreSQL database.
When running with sbt ~server/run the working directory is the server directory in this repo. You'll also find a config.example.json there as a template.
The PostgreSQL database is expected to contain the following table:
create table chess_puzzles(
auto_id serial,
id varchar(10) not null,
fen varchar(100) not null,
moves text not null,
rating int4 not null,
rating_deviation int4,
popularity int4,
nb_plays int4,
themes text,
game_url text,
opening_tags text,
primary key(auto_id)
);The following SQL will load chess puzzles from a CSV file into the table assuming the layout of the chess puzzle export from Lichess
copy chess_puzzles(id, fen, moves, rating, rating_deviation, popularity, nb_plays, themes, game_url, opening_tags)
from '/path/to/chess/puzzles.csv'
delimiter ','
csv
header;Run sbt server/assembly to compile the server and create a self contained JAR with all dependencies included. The result can be found in server/target/scala-3.7.2/
Run sbt ~server/run to get automatic recompilation as you edit the code