dusk/ROADMAP.md

Dusk Roadmap

Tracking upcoming milestones for the engine.

Upcoming milestones

1. Add a very basic physics engine, moving away from the current tile-based movement.
2. Give entities full freedom of movement (no longer locked to tile grid positions).
3. Update entity interaction, triggers, chunk management, and other systems that currently assume tile-based positioning so they work with the new 3D positioning/movement code.
4. Investigate and fix poor UI rendering performance. Rendering the console alone tanks framerate despite the existing mesh optimizations, so there is likely more headroom to find in the vertex/text rendering path.
5. Create UI elements for displaying status indicators, e.g. network connection state and save-in-progress.
6. Fully test saving end-to-end on all supported platforms.
7. Remove the tile system from chunks in favor of meshes, with dynamic hitboxes per chunk loaded in from the chunk file data.
8. Create UI elements for network status: a connecting modal, an error state, and a connected flag. Retire the test HTTP request once these are in place.
9. Build the socket server and client implementation, including handlers for the different packet types.
10. Add a dedicated multiplayer entity type, clientplayer, alongside the existing npc and player types. Limit to 8 (defined constant) for now.
11. Send and receive clientplayer position over the network.
12. Create a UI menu for creating a server and joining a server. For now, join IPs are hard-coded (testing against a fixed IP of 10.0.0.94).
13. Create "handshake" packets. For now, just send the username, enforced to be under 10 characters long.
14. Server tracks all players' positions and broadcasts them to all connected clients.
15. Server sends disconnect packets for users who leave.
16. Server assigns each client a UUID; all clients know every other client's UUID (used to reference them across position updates, disconnect packets, etc).
17. Server notifies all clients (by UUID) when a user joins, leaves, or is disconnected, so clients can spawn or remove the corresponding clientplayer entity in the world.

Principles

• Never trust the network implicitly. Neither side (server or client) should assume the other's packets are well-formed or benign -- validate all incoming packet data defensively, since either side may send garbage or malicious data. Use errorret_t / errorThrow() for these runtime checks, not assert macros -- asserts are debug-only and won't guard release builds against malformed or malicious packet data.