Design Docs

RPG98 › Design Docs › Page 11 — Technical Implementation & Client Optimization

Reaver’s Rest Design Document

Page 11: Technical Implementation & Client Optimization

Overall Architecture

Reaver’s Rest uses a thin-client design optimized for the Miyoo Mini Plus hardware.

  • Client: Runs on Miyoo (Linux-based Onion OS) using mmap for rendering (direct framebuffer access) and evdev for input.
  • Server: Authoritative Rust server handling all game logic, combat, loot, economy, and matchmaking. Communicates with the client via hybrid TCP/UDP.
  • Goal: Keep the client as lightweight as possible so the Miyoo can maintain 30+ FPS even with many entities on screen.

Rendering Approach (Client-Side)

Static Background Baking

  • At dungeon load time, the client receives the full static map data (Ground + Mask layers) from the server.
  • These layers are baked once into one or two large off-screen buffers in RAM.
  • Fringe / animated tiles and all dynamic entities (doors, boulders, spike traps, breakable rocks, players, enemies, effects) are drawn individually on top of the baked background every frame.

Benefits:

  • Dramatically reduces draw calls.
  • No re-baking needed during the run.
  • Excellent performance headroom for loading many enemy NPCs.

Memory Estimate (128×128 dungeon):

  • Baked static buffer (Ground + Mask merged, 32-bit): ~64 KB base + overhead.
  • Very safe on the Miyoo’s 128 MB RAM.

Loading Screen / Preloader

  • Full-screen loading bar shown while the client bakes the static map and loads entities.
  • Simple progress text examples: “Preparing the dungeon…”, “The void stirs…”.
  • Includes steps: receive map data → bake static layers → spawn initial entities.

Dynamic Entities

All interactive and moving objects are handled as entities:

  • Doors, boulders, spike traps, breakable rocks
  • Players, enemies, projectiles, effects
  • Animated elements (water, torches, etc.)

This keeps the static background truly static while allowing rich gameplay.

Input & Controls

  • evdev for raw button/D-pad input.
  • Context-sensitive actions (talk to NPC, open menu at Dungeon Portal, proximity interaction).
  • Virtual on-screen elements kept minimal and large for readability.

Network & Server

  • Server: Rust with Tokio for async handling.
  • Hybrid TCP (reliable: login, inventory, extraction, economy) + UDP (unreliable: movement, combat updates).
  • Server is fully authoritative for all important state (loot, death, portal modes, Threat Score).

Performance Guardrails

  • Target 30+ FPS on Miyoo Mini Plus.
  • Static baking happens only once per dungeon load.
  • Dynamic entities drawn efficiently.
  • No heavy per-frame calculations on client.
  • Dungeon sizes start at 64×64 and scale to 96×96 / 128×128 with testing.

Future Technical Considerations

  • Miyoo Mini Flip & Android ports: Responsive scaling and letterboxing already planned in the rendering pipeline.
  • Optimization iterations: Monitor RAM usage during 128×128 dungeons and adjust baking strategy if needed.
  • Server scaling: Start with a modest VPS; design allows easy horizontal scaling later.

Asset & Code Notes

  • All rendering code must respect the mmap framebuffer approach.
  • Entity system designed to be lightweight and data-driven.
  • Baking routine should be profiled on actual Miyoo hardware early.

Version 0.4 • April 2026 Previous: Page 10 – Art Style, UI/UX & Visual Direction Next: Page 12 – Game State & Menu State Management