Crate combat_service 

Combat service: authoritative, event-sourced combat encounters with live updates over WebSocket. Any number of instances can run against the same Postgres database.

Modules

admin

Errors, as responses. What whoever runs the service asks of it over HTTP. The combat service’s admin API (see edda_server::admin): exporting, importing and deleting a campaign’s combats and planned encounters.

encounters

Planned encounters: CRUD over each campaign’s reusable plans. Plans (and their notes) are the DM’s, so player devices can’t see them.

error

hub

Live combats on this instance: command execution and fan-out of events to connected clients.

routes

The /combats routes and the WebSocket.

services

Reaching the other services as this service itself: it logs in to the auth service with its own key (registered there with auth-service add-service) to get a token for each campaign it works for. Character sheets are kept in step through it (see crate::sync), and monsters’ stat blocks fetched, to add them to a fight.

store

Persistence of the combat event log in Postgres, shared by every instance of the service.

sync

Keeps character sheets in step with combats: hit points are written back, and what casting or using a feature costs (a slot, uses) is spent on the sheet before the command runs and given back if it’s refused or undone. Every frontend gets this without doing anything.

Structs

ApiDoc

The service’s OpenAPI description.

Config

Where the other services are, the limits, and where to listen for other instances’ events.

Functions

app

The service, with its background tasks started on the current runtime. Accepts tokens that verifier vouches for.

connect

Connects to the database, creating it if needed, and applies migrations.