evoyo.la
VOIDRIFT
Browserbasiertes 2D-Weltraum-MMO mit serverautoritativer Bewegung über WebSocket und Protobuf — Go-Backend, PixiJS-Client, in aktiver Entwicklung.
VOIDRIFT ist ein browserbasiertes 2D-Weltraum-MMO mit serverautoritativer Bewegung und Kampf: ein Go-Backend, ein PixiJS-Client, PostgreSQL als Datenhaltung und ein binäres WebSocket-Protokoll über Protobuf. Das technisch anspruchsvollste Projekt im Portfolio — und ausdrücklich ein laufendes Vorhaben, keine fertige Produktion.
Galerie
Case Study
Ausgangslage
VOIDRIFT ist der Versuch, ein Weltraum-MMO mit echten, serverautoritativen Regeln im Browser zu bauen — auf einem geteilten Devserver mit dokumentierter Historie an Speicherproblemen, weshalb Ressourcenbudget von Anfang an ein Entwurfsfaktor war, nicht ein nachträgliches Problem.
Herausforderung
Der Client sendet ausschließlich Bewegungsabsichten, nie eine Position — die eigentliche Position, Geschwindigkeit und Rotation werden serverseitig jeden Tick berechnet. Eine frühe Version der Client-Interpolation ließ denselben Objektzustand mehrfach puffern, wodurch Bewegung sichtbar auf die Tick-Rate einschnappte statt flüssig zu wirken. Treffererkennung bei Projektilen brauchte einen Segment-gegen-Kreis-Test zwischen vorherigem und aktuellem Tick statt eines reinen Punkt-Abstands, damit kleine, schnelle Ziele nicht zwischen zwei Ticks hindurchschlüpfen. Lasttests zeigten außerdem, dass die Anzahl gegenseitig sichtbarer Verbindungen — nicht die reine Objektzahl — der limitierende Faktor ist: Der Kipppunkt lag bei rund 60–80 gegenseitig sichtbaren Verbindungen, deutlich unter einer ursprünglich angenommenen, sich als Testartefakt herausstellenden Zahl.
Vorgehen
Go-Backend, unterteilt in eine reine, netzwerk- und datenbankfreie Simulationsschicht (unit-getestet), eine Sektor-Schicht mit Tick-Loop und Interessensraster, eine Gateway-Schicht für WebSocket- und Protobuf-Terminierung sowie eine Auth-Schicht mit Argon2id. Datenzugriff über sqlc-generierten Code statt eines ORMs, PostgreSQL 17 in Docker mit Migrationen über goose. Der PixiJS-Client mit striktem TypeScript übernimmt Rendering, Prediction für das eigene Schiff und Interpolation für alle anderen Objekte. Eine Hot-Reload-Dev-Umgebung baut Go automatisch neu, beobachtet Protobuf-Änderungen und startet den Vite-Client parallel.
Entscheidungen
Der Client sendet nur Bewegungsabsichten, nie eine Position; jeder Schuss wird jeden Tick neu gegen Cooldown, Reichweite und Energie validiert.
Die proto3-Feldpräsenz unterscheidet „nicht gesetzt“ von „0“ und trägt damit das Delta-Encoding zwischen Ticks, ohne ein zweites, handgepflegtes Diff-Format zu brauchen.
Bei der aktuellen Größenordnung ist ein kompletter Rasterneuaufbau pro Tick günstiger als ein inkrementell gepflegter Baum.
Balancing-Werte leben versioniert in Textdateien; alles, worüber zwei Spieler unterschiedlicher Meinung sein könnten — etwa Inventar — lebt in Postgres.
Kein aktuelles Feature braucht Cross-Sektor-Kommunikation; ein zusätzlicher Container auf einem Host mit Speicherproblemen in der Vergangenheit war nicht gerechtfertigt.
Einzeldateibasierte Migrationen und eine reine Go-Library, die sich enger mit sqlc paart — eine Präferenz-, keine Korrektheitsentscheidung.
Eigenanteil
Vollständiger Entwurf und Umsetzung von Backend-Simulation, Netzwerkprotokoll, Authentifizierung, Datenbankschema, PixiJS-Client, Admin-Tooling, Lasttest-Werkzeug und der kompletten Deploy- und Betriebsinfrastruktur der Entwicklungsinstanz.
Ergebnisse