ak47andrew/fableforge-reborn

Purpose and Workspace Layout

FableForge Reborn is a Rust virtual-tabletop project organized as a Cargo workspace with three crates:

• Shared protocol/domain crate: common/src/lib.rs

• Interactive client application: client/src/main.rs

• Authoritative multiplayer server: server/src/main.rs

The README provides product intent but no operational instructions; architecture must be inferred from crate and module boundaries.

Client Application Entry and Composition

client/src/main.rs is the client entry point and composes UI, configuration, authentication/token handling, camera behavior, and network connectivity. The client is structured as a native application rather than a browser-oriented frontend.

Core client modules:

• client/src/button.rs — UI button/component behavior.

• client/src/smart_camera.rs — tabletop viewport/camera control.

• client/src/config.rs and client/src/consts.rs — client configuration and shared client constants.

Client-to-Server Boundary

The network boundary is explicitly isolated in client/src/websocket.rs. This module is the likely transport adapter between the client’s UI/state interactions and server-side multiplayer state.

Authentication/session credential concerns are separated into client/src/token.rs, indicating tokens are managed on the client independently of presentation and WebSocket transport. The expected control flow is: startup loads configuration/token state, establishes a WebSocket connection, then forwards user actions and receives synchronized game/tabletop updates.

Server Runtime and State Authority

server/src/main.rs is the server process entry point. It owns service startup and connection handling, while server/src/state.rs isolates server-managed application state.

This establishes the server as the authority boundary for shared tabletop/session data:

• Connection requests enter through server/src/main.rs.

• Shared or per-session state is read and mutated through server/src/state.rs.

• Updates are returned to connected clients through the network layer.

No persistence, HTTP API, database integration, or deployment infrastructure is visible in the supplied tree.

Shared Contract Crate

common/src/lib.rs is the workspace’s cross-process contract boundary. It should contain protocol messages, common domain types, and serialization-compatible structures used by both client and server.

The intended dependency direction is:

• client → common

• server → common

• no direct client-to-server source dependency

Keeping multiplayer message and domain definitions here prevents transport payload drift between independently compiled binaries.

Primary Flow

1. The client starts at client/src/main.rs, initializes local configuration and UI/camera state.

2. Credential/token logic from client/src/token.rs supports session identity or authorization.

3. client/src/websocket.rs connects to the server and exchanges types defined in common/src/lib.rs.

4. server/src/main.rs accepts/processes client traffic and delegates authoritative mutations to server/src/state.rs.

5. The server broadcasts or returns state changes; the client maps them into tabletop UI and camera-visible state.

Material Runtime and External Dependencies

The implementation is Rust/Cargo-based, with workspace dependency definitions in Cargo.toml, client/Cargo.toml, server/Cargo.toml, and common/Cargo.toml. A WebSocket service is architecturally central; its concrete library, host configuration, authentication scheme, rendering runtime, and storage backend are not identifiable from the provided files.