mahjong
mahjong copied to clipboard
Prototype client-server game architecture written in C# and Rust
We need a generalized solution around how we handle desyncs in the client. Currently we're doing a pretty good job of sending the client the necessary pieces of information needed...
Right now the shared Rust library implements most of the core state tracking for a mahjong match in the `MatchState` (soon to be `LocalState`) type. However, the C# code is...
The way client/server communication is setup for mahjong matches has the client and server each maintaining their own (slightly different) copies of the match state. As the player performs actions...
Right now the client code knows all tiles in the wall from the start of the match, including the order in which they will be drawn. This means that a...
`TileInstance` was originally setup so that we could try to take advantage of Rust's ownership system when moving tiles around with the hope of avoiding bugs that could result from...
Currently we drop the generated C# bindings for the shared Rust code directly into the Unity project. This is perfectly functional, but it has the annoying issue that when you...
In setting up the server, I'm running into the question of how to do error handling in a way that ensures all state changes are atomic. When handling user input,...
Right now we have tests for the match state, but we don't have a way to test the running server outside of just running the client and playing the game....
Currently we connect the client and server with a websocket using the [warp](https://crates.io/crates/warp) crate. While this works, it requires us to effectively build our own RPC layer on top of...
We should make use of [Clippy](https://github.com/rust-lang/rust-clippy) for static analysis in the project. This will likely take some minor setup: * Clear out any existing warnings/errors it highlights. * Configure warning...