Update v0.2.6 - Data refactor, Bug fixes
-
The building of Ninjora has been primarily featured focused for the last two and a half months of development, because of this I was neglecting critical data considerations such as how many KB per second each player would be sending.
Going back to address this felt daunting at first - I had already built an entire client-side prediction system using Float64 positions, and the thought of reworking everything to use quantized values seemed like it could break the delicate balance I'd achieved with smooth movement and jump mechanics. But the numbers were undeniable. With Float64 positions, each player was transmitting 24 bytes just for their X, Y, Z coordinates - multiply that by 20 updates per second across 50 players, and suddenly I'm looking at 52 KB/s download per player, or 187 MB per hour. And from a cost perspective, I'd be paying $81/month in bandwidth costs for just 100 concurrent players - costs that would scale linearly as the player base grew.
The solution was UInt16 quantization, but implementing it correctly took multiple attempts. The challenge wasn't just changing the data types - it was maintaining the prediction system's integrity while working with lossy compression. My first few attempts introduced visible rubberbanding during jumps because I was trying to correct prediction errors too aggressively. The client would predict a jump, but when the quantized position came back from the server, it would be slightly off, triggering corrections that felt terrible. The breakthrough came from realizing I needed to completely trust client physics during airborne movement - just like the old Float64 system did. The key insight was detecting "pending jump commands" - situations where the client has already sent a jump input but the server's confirmation hasn't arrived yet. By checking for these pending commands before applying any landing corrections, I eliminated the race condition that was causing the rubberbanding.
Now the system achieves both goals: massive bandwidth savings AND buttery smooth movement. With UInt16 quantization, I'm down to 6 bytes for positions (75% reduction) and 4 bytes for facing angles (also 75% reduction). Per player, that's 34 KB/s at most, instead of 52 KB/s - a 34.6% overall reduction. For a 1-hour play session, that's 66 MB saved per player. The precision loss is imperceptible - 3.9mm per step for horizontal movement, 0.9mm for vertical, and 0.0055° for rotation. These values are far below what human perception can detect in a game environment. And the prediction system actually feels better now with the conservative landing correction system: it only applies a gentle 10% blend when errors exceed 0.8m and the player has been grounded for 5+ frames, spreading the correction over 23 frames to make it completely invisible. This taught me an important lesson about optimization: sometimes you have to go back and fix foundational issues even when it feels like you're "done" with a system. The 20+ debug commits I made trying to nail this down are now squashed into one clean commit, but each failed attempt taught me something about how prediction, quantization, and network latency interact. The result is a system that's both technically superior and imperceptible to players - the best kind of optimization.
Implementations:
- All game data is imported from the newly made Ninjora Master Game Editor which will extremely speed up the creation process
- NPC's now have loot drops pertaining specifically to them
Other bug fixes:
- Character Customization screen completely dark
- Portal teleporting player back and forth when arriving on new map
- Interior shops had the sky in the background (unwanted)
- Texture duplication
- Map transition clean up
