← The dated devlog

18–20 October: authority, programmable effects, and voice

Gameplay systems met real networked consumers, while capture and voice exposed platform lifecycle details.

From the development archive

Retrospective summary of original 18–20 October posts, using Europe/Berlin calendar days.

Four Windows flight-scene frames showing a purple drone following an authority-owned path through collision geometry.
19 October authority-driven drone study. It demonstrates the authored path, not local prediction or a server population benchmark.

This window connected several reusable systems to visible game behavior: authority-driven AI, skeletal and procedural animation, programmable particles, streamed-world lifetimes, persistent sessions, and optional spatial voice. The important architectural theme was that visual richness should not change who owns gameplay.

Presentation can vary while authority stays shared

Device captures labelled full and portable effect tiers. The same programmable-particle foundation could choose a different visual workload while gameplay remained authoritative. The drone study similarly showed a server-owned route through real collision geometry rather than an animation pretending to be a networked simulation.

A reconnect fixture exposed another subtlety. Clients retained different actors through relevance hysteresis because the test ended in different interest circumstances. Moving the route endpoint into a shared cell preserved the exact state comparison instead of weakening it. That is a useful example of correcting the experiment while keeping the required invariant.

Voice needs lifecycle and policy, not just samples

The voice work kept channels, mutes, and personal-space rules ahead of reusable server mixing. Microphone backgrounding and explicit re-enabling were separate checks. A foreground return was not treated as permission to resume capture automatically.

The cumulative voice review was merged on 20 October with recorded checks across Windows, Mac, browser, phone, Quest, and physical iPad. Xbox microphone input and physical audio latency remained separate hardware qualifications. Those limits are part of the result.

Drune became a concrete consumer

The same period produced a PC checkpoint for multiplayer driving, drifting, jumps, recovery, shared markers, and layered audio. That supplied a more demanding consumer for the reusable engine than an isolated effect viewer. Terrain contact, distance, vehicle motion, and network state all meet in one camera.

The later multiplayer article explains how that experience led to a more explicit lag and replication audit. The engine-boundary note describes why the reusable machinery and a game’s particular rules should continue to evolve separately.

Have a thought or a question?
I'd love to hear it. ↗