claude
c4beeae38f
Top-down twin-stick bullet-hell, Godot 4.7, server-authoritative dedicated server with client-side prediction. Clients send input only; the server resolves every hit for both players and enemies (no PvP). - SimWorld: whole simulation as plain RefCounted objects (no nodes, no physics server), ~0.24ms/tick at peak load -- runs headless for free and drives 78 tests in under a second - BulletPool: struct-of-arrays bullet storage, replicated as spawn/despawn events rather than per-tick state - Emitter framework (Ring/AimedSpread/WallGap/ArcSweep) shared by trash enemies and bosses -- a new boss is data in src/content/content.gd, no simulation changes - The Warden of the Fold: stationary 4-phase boss built entirely on that format - Lobby hub with a portal into on-demand dungeon instances; one process hosts the hub plus every concurrent dungeon - Emergency escape: 3s server-owned channel, cancelled by damage - tools/check.sh, test.sh (GUT), smoke.sh (real server + bot clients over ENet), bench.gd; git hooks wired to the same scripts - docs/ARCHITECTURE.md, NETCODE.md, WORKFLOW.md, ROADMAP.md
3.0 KiB
Roadmap
Built
| MVP requirement | State |
|---|---|
| Top-down 2D twin-stick bullet hell | Movement, aim, fire, i-frames, death and respawn; MultiMesh bullet rendering. |
| Multiplayer with server-side hit validation | Authoritative dedicated server; clients send input only; all hits resolved server-side for both players and enemies. No PvP. |
| Simple, predictable enemies | Drifter, Turret, Stalker, plus a lobby dummy. Five movement behaviours, all closed-form. |
| Stationary boss, adaptable format | The Warden of the Fold: four phases, data-defined. A new boss is one function and zero simulation changes. |
| Lobby hub with dungeon entry | Persistent lobby instance, portal, party forming window, dungeons opened on demand. |
| Emergency escape | Three-second channel, cancelled by damage or release, server-owned. |
78 tests plus an end-to-end smoke test over a real socket.
Next, in rough order of value
1. Make the dungeon a place. Right now it is one arena and three stages.
Rooms, doors, and a SimWorld with static geometry — which means adding a
collision representation for walls (segment-vs-circle for players, segment
crossing for bullets) since there is no physics engine to lean on.
2. Art and feel. Everything is drawn with draw_circle and a generated dot
texture. Sprites, hit flashes, screen shake, muzzle flashes, death effects, and
sound. None of it touches the simulation — this is entirely src/view/.
3. A second boss. The format claims to be reusable; the way to find out is
to use it. A mobile boss will exercise BossDef.stationary, which the runtime
already reads but no content uses yet.
4. Progression. Loot, character stats, persistence. Needs a decision on storage: for a dedicated server, player state belongs server-side in a database, not in a client save file.
5. Netcode hardening. In the order they will actually matter:
- DTLS on
ENetMultiplayerPeerbefore any public server. - Authentication;
peer_namesis currently client-supplied and trusted for display only, which is fine now and will not be once there is progression. - Snapshot delta compression, once enemy counts grow.
- Interest management inside an instance, once arenas are larger than a screen.
6. Scale. The simulation costs ~1.4% of a core per instance, so the ceiling is bandwidth and process supervision, not CPU. A shard manager that runs several server processes behind a lobby-of-lobbies is the shape, but it is premature until there is a game to fill it.
Deliberately not done
- Lag compensation. Discussed in NETCODE.md: rewinding for a shooter's view would mean a player who dodged still gets hit, which is the wrong trade for this genre.
- Pattern-level bullet replication. A large bandwidth win that couples the client to emitter behaviour. Not worth it until bandwidth binds.
MultiplayerSynchronizer/MultiplayerSpawner. Right tools, wrong shape for a bullet hell. See ARCHITECTURE.md.