sphynx / rokumon Goto Github PK

This would seriously decrease the running time. We can use rayon for that.

Display it somehow nice for the moment, before finalized UX screens for that are ready.

Currently the rule is implemented as "Fight" is possible if "at least on die is yours". This actually includes the case when both dice are yours. However, according to Charles, the fight should only be allow when there are two dice: one is your and one is your opponent's.

The fixes should be applied to game.rs in rokumon_core (in validate_move function). Also, we can apply them in the UI where availability of the Fight button is checked: canFight function in game.js

So that we can easily upload the resulting web app to the web server.

As explored in #16, our WASM size is currently more than 300k, which is potentially large for Web.

Investigate what can be done with that, perhaps we can avoid building packages like rand (and just use rand() from js-sys) or optimize compilation for size (trying not to neglect speed at the same time).

And a link to official game rules

Now we have some code to conditional classes like this:

const kindClass = props.kind.toLowerCase();
const selectedClass = props.selected ? 'selected-card' : '';
...
return ( 
  <div className={`card ${kindClass} ${selectedClass}`}>
...
);

which can be made neater by using classnames.

See this for details:

• https://reactjs.org/docs/faq-styling.html
• https://www.npmjs.com/package/classnames#usage-with-reactjs

Currently I'm mostly using unwrap() there, we should fix that.

Relevant links:

• https://rustwasm.github.io/docs/wasm-bindgen/reference/types/result.html

Currently, the bot uses std::time to handle duration running condition (i.e. to measure the time which it can use to analyse the move). std::time is not supported on wasm32-unknown-unknown, so we need to have a custom implementation of rubot::RunCondition which will probably use websys. We'll need to enable it conditionally for wasm-aware build of the core library (i.e. under "for_wasm" feature).

Currently npm start runs with the following warning:

Compiled with warnings.

../rokumon_wasm/pkg/rokumon_wasm_bg.js
Critical dependency: the request of a dependency is an expression

I believe it was introduced by compiling rand Rust package with wasm-bindgen feature.

Now, when I move from Game Setup screen to the Game screen, it all happens inside a single page (I basically do the transition with JavaScript, just rendering different components), even though it feels like we are going to another page.

Therefore, just clicking Back button on the Game screen does not take you back to the Game Setup screen and instead just takes you on the previous web page (sometime that's not even Rokumon page).

We should figure out how to handle that Back putton in JS and just revert the app state back to GameSetup.

We should try publishing it in "release" mode (as opposed to "dev") and see how big it is and how it looks (CSS/JS/WASM). Then we can see if it's ok or that we should work on trying to make it smaller.

This also includes minimizing the compiled WASM size (i.e. using -c flag to ask compiler to optimize for generated code size).

Now they end up being displayed to the web users, so we need to be more user friendly.

Review common error messages for the following moves:

• Place
• Move
• Fight

Now it just panicks on unwrap when I request another move.

Now, we always have first player's dice in the bottom.

We should have a component which orchestrates getting moves from the players (be it human players or bots). Currently it's done in a rather ad hoc manner: it's hardcoded for Human vs AI play, not being able to handle Human vs Human or Bot vs Bot games.

Now we just say 'invalid place move' or 'invalid move move' which doesn't explain the reasoning.

We need to show a message when the game ends, disable normal controls, showing an option to start a new game.

We should consider "no moves" a normal situation when the player to moves just loses, however current code expects that there always at least some move and panics otherwise (because it uses unwrap from Option).

Thanks to @illegal for spotting the bug!

Here is an example of a position demonstrating this bug (without "fight" or "surprise" moves):

Resulting position:

Jade[] Gold[B1 < R2] Gold[B1 < R2]
Jade[B1] Gold[B1 < R2] Jade[R2 < B1] Jade[]
Player 1: []
Player 2: []
to move: Player 2

Running AI with duration 1s...
thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', src/ai.rs:163:21
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Full log is available here: https://gist.github.com/illegal/afd89aef9356b7799c892bd99bbe86df

It would be nice to have a separate lib-crate with just the core parts and data structures of Rokumon, without the parts required by the console executable (for example moves parser, command line options handling, etc.). Then this crate can be used for WebAssembly compilation

Currently it just uses standard React ones

We can do it for:

• perft, to test the speed of move generator –– definitely useful.
• selecting move from the bot (say up to particular, short depth).

We should do it for various combinations of rules:

• No Fight, no Surprise
• Only Fight
• Both

And perhaps for several positions:

• starting position
• position after 3-4 moves
• position somewhere in the middle of the game when most dice are out

The one to play with Automa (hex-shaped with a fort in the middle).

For that we would need to implement the missing case marked with unimplemented!() in Board::new for Layout::Hex7. There are examples of creating new boards for other layouts: Rectangle6 and Bricks7.

...while it looks that it's possible in Rust currently! And therefore it's allowed in UI as well, since we rely on Rust for move validation.

Prepare CSS and JS to style the main game page according to Maryna's screen in 'game start.svg'

It should be clear whose turn it is now.

Automa is a bot described in the rules, basically a solo version of the game.

For that you'll need to check out the last page of the rules and then implement the algorithm for playing.

Since their values do not matter, we can omit the pips altogether.

In this way if should be easy to reproduce certain games and situations.

We should also add a way of dumping games or current position to a file, so that it can be reproduced later.

The format can be as simple as options + sequence of moves. Then we create the game using those options and apply the moves sequentially.

Use Web Workers API to run AI in a similar thread.

Currently, I'm unblocking the main thread by using a simple setTimeout trick, but this probably won't do for more serious usage.

See this TIL for details.

Currently the bot is very strong, so it's practically impossible to beat in some modes.

We need to let people play with weaker bots, so that it's more fun to play.

We should load WASM only once (since it's quite heavy) and just recreate the Game/Playground using WASM calls when creating another game. On the other hand, we don't want to load WASM at the very beginning, i.e. on Game Setup page, since it's not needed yet.

So, we should basically load WASM lazily, but keep it in memory and not to load it twice (or every time when creating a new Game as it's done now).

It's not very clear for me what is the idiomatic way to do it, I should read more about React lazy loading and overall approach to long calls/loads.

Sometimes when two bots are playing they start looping, coming back to the same position again and again. Since bots are mostly deterministic, they keep choosing the same option, so there is no point in continuing this and we should probably call it a draw (like three-fold repetition rule in chess).

We should probably migrate from deprecated failure crate and use anyhow and thiserror crates.

We should also consider errors in rokumon-core to be library errors, i.e. instead of using strings, we should use enums, so that web and console-ui clients can interpret and display those error differently and in whatever fashion they like. Then we can also localize them.

Some of them look like they can even improve performance slighly!

We should also explicitly mention WebAssembly part of the project, because currently README only tells about the command line interface.