Godot game client and serverq
A Rust crate powering KBVE games — a Godot GDExtension client with a tokio game manager, plus a bevy + axum + rapier2d server flavor.
One crate, two flavors
The default build is a Godot GDExtension (cdylib) with a tokio-backed game manager; feature flags expose a parallel server flavor built on bevy, axum, and rapier2d, along with per-game bundles.
- Mutually exclusive — client and server gated by a compile_error in lib.rs.
- Game bundles — rollups like nexus-defense select a whole flavor.
What it gives you
Features
Client flavor
Godot GDExtension with dashmap, crossbeam, bitflags, and a tokio runtime; the default build.
Server flavor
Headless Bevy ECS driven from a tokio task, mutually exclusive with client.
Protocol
postcard wire format plus bincode snapshot framing (proto-shared, proto-client, proto-server).
Physics
rapier2d for spatial queries (client) and authoritative sim step (server).
Networking
WS client for the Godot extension, Axum for the server (net-client / net-server).
Supabase auth
Server-side HS256 JWT verification to admit players.
Game bundles
nexus-defense / nexus-defense-server roll up the features per game.
Questions
Frequently asked
What is the q crate?
Q is a Rust crate powering KBVE games. Its default build is a Godot GDExtension (cdylib) with a tokio-backed game manager, and feature flags expose a parallel server flavor built on bevy, axum, and rapier2d.
Can q be built as both a client and a server?
Yes, but not at once. The client and server features are mutually exclusive — enforced by a compile_error in lib.rs — so a build is either the Godot GDExtension client or the headless server flavor.
What game bundles does the q crate provide?
Feature rollups such as nexus-defense and nexus-defense-server bundle protocol, physics, networking, and (server-side) bevy ECS plus Supabase JWT auth and shared mapdb/npc registries, so build pipelines can select a whole game flavor with one feature.