I think as a mental exercies it's important to explain what a card game really is in order to scope what needs to be done for this framework.

In order to test the server we need a bot player that will communicate with the NGS application. It needs

• to perform the handshake with the server
• send delta object
• resolve deltas with its own internal game state
• fall back to server game state if it cant resolve the delta

The below set up is gonna sound like it's a lot of work and it, especially to someone who does not yet know rust. However, I think we can bypass that with some clever sub issues, but this is a brain dump on everything this bot-rs project will need

• create a handshake request with the following attributes.

#[derive(Serialize)]
struct JoinRequest {
    /// The clients username
    username: String, // could proably use &str to be super mem efficient, but for this POC its not woth it yet
    /// The name of the opponent to request to play against. A Value of None indicates that a random opponent may be accepted
    opponent_requested: Option<String>
}

• The server will respond with a waiting when the join request is proccessed

{ "queue_status" : "WAITING", "opponent" : null }

• then an accept when the opponent requsted is ready to play

{ "queue_status" : "ACCEPTED", "opponent": "opponent_name", "player_number": u8 }

• The game will then begin with an initial state supplied by the server. This initial state will be a collection of entities received by the server as a "FAT" delta.

{
    entities: [
        entity { },
        ...
    ]
}

• When the turn entity matches the player number the player may play, otherwise delta requests received by the server during this time will be denied.

• A single entity can be updated in a given delta request sent at the server. Once the server accepts the delta request more can be be made.

a delta request will be responded to by the server with one of the following response:

enum ServerResponse {
    /// entity will effectively be a revert to be enacted by the client
    DENIED { entity: Entity },
    /// any valid delta request will be responded to by the server with a list of entities to be updated on the client side
    UPDATE { entities: Vec<Entity> },
    ///  I'm not exactly sure how this would work yet, but it would be when your action creates a prompt for a response from your opponent
    WAITING { }
}

when the game is complete the outcome entity will be updated with the winner. when this entity is set the clients should not send or receive any more deltas from the server.

• create a game delta request struct that can be serialized and sent to ngs using TCP. The NGS server will respond with an echo if it has been accepted by the server's validator engine (yet to be created) and can be applied to to the Local Game State. if it does not the delta request will be discarded, and the localgamestate should be refreshed against the the server's game state

Questions we need to figure out:

• What if the local game state diverges from the game state maintained by the server? How do we know when said divergence occurs?
• Do we need to design out entity specifics now? I imagine certain parts need to be planned out now.
• Under what rules could a delta request be denied?

Draw Diagrams for each submodule of the card captor framework and a high level diagram that shows the interaction between all components