Miyoo Extraction RPG — Phase 1: Core Movement & Rendering

In Phase 1 we build the foundation of the game world: a procedurally generated dungeon that the Miyoo can render efficiently using chunk loading and culling. By the end you will walk around a real dungeon generated on the Rust server.

🎯 Goal

Implement smooth top-down movement and efficient tile-based rendering with spatial chunking on the Miyoo while the Rust server generates and manages the dungeon.

✅ Final Deliverable

A Miyoo binary where you can freely walk around a server-generated dungeon (room + corridor style) with responsive controls and low latency over WiFi.

📋 Prerequisites — Complete Phase 0 First

✔️ Rust workspace with shared crate
✔️ Working Tokio TCP + UDP server
✔️ Miyoo SDL2 client compiling and running
✔️ Basic networking (Connect / Pong) established
✔️ 16×16 tileset and player sprite ready

Detailed Steps for Phase 1

Server: Implement Procedural Dungeon Generation

Room + corridor algorithm (simple & reliable)

In the Rust server crate, create a Dungeon struct that generates a grid (e.g. 64×64 tiles) using:

Place 8–15 random non-overlapping rooms (rectangles)
Connect rooms with L-shaped or straight corridors
Add a starting position and at least one extract portal
Use a seed (uuid or u64) so the same dungeon can be regenerated if needed

// Example skeleton in shared or server
pub struct Dungeon {
    pub width: u32,
    pub height: u32,
    pub tiles: Vec<TileType>,
    pub rooms: Vec<Room>,
    pub seed: u64,
}

This runs entirely on the server. The client never generates the map — it only receives tile data.

Define Network Packets for Dungeon Data

Expand the shared Packet enum to support dungeon loading:

pub enum Packet {
    // ... previous packets
    EnterDungeon { dungeon_id: u64, seed: u64 },
    DungeonData { width: u32, height: u32, tiles: Vec<u8> },  // compressed tile IDs
    PlayerPosition { x: f32, y: f32 },
    WorldSnapshot { entities: Vec<EntityState> },
}

Use bincode for compact binary serialization to keep WiFi traffic minimal.

Client: Implement Chunk-Based Tile Rendering

This is the most important performance optimization for the Miyoo.

Chunk size: Start with 16×16 or 32×32 tiles per chunk
Visible area: Load a 5×5 grid of chunks centered on the player (with 1-chunk buffer)
Rendering: Use SDL2 texture atlas for all 16×16 tiles. Render only visible chunks to an off-screen render target, then blit to screen.

Why chunks matter on Miyoo: Rendering the entire 64×64 map every frame would be too slow. Chunking reduces draw calls dramatically.

Client: Player Movement with Prediction

Implement smooth local movement on the Miyoo while sending inputs to the server:

Read D-pad + analog stick every frame
Apply movement locally immediately (prediction)
Send input packets over UDP at ~30 Hz
Server validates position and sends corrections via WorldSnapshot
Reconcile (smoothly correct) on the client when server data arrives

Server: Dungeon Instance Management

Create a manager that:

Creates a new Dungeon when a player (or party) enters
Tracks all connected players in that instance (max 8)
Broadcasts relevant WorldSnapshot to players (only nearby entities thanks to chunk-based interest management)

Add Basic Collision & Camera

On the client: simple AABB collision against tile data received from server.
Camera follows the player with slight smoothing. Keep the visible world centered.

Test Thoroughly on Real Hardware

Key tests to run:

Enter dungeon → receive and render chunked map
Move around edges of chunks — verify new chunks load smoothly
Test latency on home WiFi and hotspot
Measure FPS (aim for stable 30+ FPS)

✅ Phase 1 Complete When You Can:

✔️ Connect to server and enter a procedurally generated dungeon
✔️ Walk around freely with responsive controls and camera follow
✔️ See only visible chunks being rendered (performance stays smooth)
✔️ Experience low-latency movement even over WiFi

You now have a playable world. Phase 2 (Combat & Abilities) will feel very rewarding after this foundation.