Ich weiß, „Q1 2026" trifft es nicht mehr ganz da wir schon Mitte Mai haben. Aber es ist viel passiert: die großen Features des letzten Jahres zu Ende gebracht, den Code mit einer Runde Frühjahrsputz auf Vordermann gebracht, und das technische Fundament für den lang ersehnten UI Refresh gelegt. Lest weiter für einen vollständigen Überblick, und beachtet bitte unbedingt den Hinweis zu bevorstehenden Arbeiten am UI.
Hinweis: Vorübergehende Design-Inkonsistenzen im Anflug
Wer schon länger dabei ist, weiß, dass das Spiel derzeit neben dem hellen und dunklen Theme auch ein „klassisches" Farbschema anbietet. Auch wenn es mir (und vermutlich vielen anderen) am Herzen liegt: Das klassische Theme ist faktisch veraltet und wird im Zuge des UI Refreshs früher oder später entfernt – zugunsten des heute üblichen Standards: ein Hell/Dunkel-Modus entsprechend der Betriebssystemeinstellung, mit der Option, ihn manuell zu überschreiben.
Darüber hinaus kann es in den nächsten Wochen, wenn ich die ersten Gen-3-Komponenten einführe (mehr dazu im Abschnitt UI Refresh weiter unten), gelegentlich zu visuellen Inkonsistenzen kommen – etwa wenn Teile des (neuen) Seitenrahmens optisch nicht ganz zum (bestehenden) Inhalt passen. Das ist beabsichtigt und vorübergehend. Ich plane die Migration inkrementell durchzuführen statt mit einem großen, riskanten Schnitt. Es wird also eine Übergangsphase geben. Das klassische Theme wird davon voraussichtlich besonders betroffen sein, da ich dort keine Ressourcen für themespezifische Anpassungen aufwenden werde.
Ich wollte das lieber vorab ansprechen, damit niemand denkt, etwas sei kaputt. Vielen Dank für euer Verständnis!
Location-Based Demand (LBD) — Verfeinerungen & laufendes Balancing
Nach der Winterpause war meine erste Aufgabe, das Location-Based Demand-Feature aufzuräumen, das ich kurz vor Weihnachten noch schnell rausgebracht hatte. Als ersten sichtbaren Schritt (Woche 2) habe ich den Tab für das Bodennetz auf Flughafen-Infoseiten so angepasst, dass er verbundene Locations statt anderer Flughäfen anzeigt, und die Flughafenkarten aktualisiert, um diese Locations als Hotspots im Einzugsgebiet darzustellen. Außerdem habe ich mich intensiv mit dem Location-Clustering-Algorithmus befasst – dem Stück Code, das Hunderttausende realer Orte auf eine handhabbare Menge reduziert – und eine Reihe von Grenzfällen behoben, die offensichtlich falsche Ergebnisse lieferten, wie Flughäfen auf Inseln ohne verbundene Locations. Die Behandlung von Inseln ist nach wie vor ungelöst und als eigener Roadmap-Punkt vorgemerkt.
In Woche 4 und Woche 6 habe ich tiefer untersucht, warum LBD sich unerwartet verhält, wenn es mit Individual Travel Requests kombiniert wird – der Kombination, die ich langfristig als Standard für alle neuen Spielwelten einsetzen möchte. Zwei zentrale Herausforderungen zeichnen sich ab: Tourismus-intensive Ziele generieren viel zu wenig Nachfrage, weil das aktuelle Modell rein bevölkerungsbasiert ist, und Fracht ist so dünn über die Ziele verteilt, dass es nahezu unmöglich ist, das Aufkommen sinnvoll abzuschöpfen. Ich untersuche beide Probleme gemeinsam mit dem Freiwilligen aus dem Datenteam, erwarte aber keine schnelle Lösung. LBD bleibt vorerst auf Wright beschränkt.
Individual Travel Requests (ITRs) — Kurz vor der Produktionsreife
Die ersten Wochen von Q1 standen auch im Zeichen der letzten offenen Punkte auf der ITR-To-do-Liste. Einer der kniffligeren (Woche 6) war die Aktualisierung der Bewertungsanzeigen für Service-Profile und Kabinenkonfigurationen – knifflig, weil das alte ORS und die ITRs Bewertungen sehr unterschiedlich berechnen, aber beide je nach Konfiguration der Spielwelt parallel funktionieren müssen. Ich habe mich für eine pragmatische Lösung entschieden und sie für eine ordentliche Überarbeitung vorgemerkt, sobald die Überarbeitungen von Kabinenkonfiguration und Service-Profilen anstehen.
Die größere Änderung, die in v6.13.2 (Woche 7) ausgeliefert wurde, waren entfernungsabhängige Kundentyp-Wahrscheinlichkeiten: Preissensitive Passagiertypen werden auf längeren Strecken nun seltener, was deutlich intuitiver ist. Um das richtig umzusetzen, war eine recht umfangreiche Überarbeitung der Anfragegenerierungslogik nötig, weil der bisherige Ansatz – Passagiertyp und Anfragegröße in zwei separaten Schritten zu würfeln – die tatsächlichen Wahrscheinlichkeiten subtil verzerrt hat. Die ITRs sind auf einem guten Weg, und ich erwarte, dass sie in den kommenden Monaten in einer regulären Spielwelt eingeführt werden (zumindest als Vorschau in einer temporären Spielwelt, bis Fares verfügbar sind und einige verbleibende Schwächen beheben).
Frühjahrsputz — Framework- & Abhängigkeits-Upgrades ✅
Von Woche 8 bis Woche 12 habe ich einen geplanten „Frühjahrsputz" durchgeführt – alle wichtigen Bibliotheken und Frameworks, von denen unsere Systeme abhängen, wurden auf ihre aktuellen Versionen gehoben. Ich habe mit dem zentralen Account-Management-Backend begonnen und mich dann zu AirlineSim selbst vorgearbeitet. Das Upgrade des Account-Backends verlief reibungslos; das von AirlineSim dauerte länger als erwartet und beförderte mehrere Bugs zutage, die ich beheben musste, bevor ich den Patch für den Frühjahrsputz ausrollen konnte. Es gab auch ein paar Nacharbeiten nach dem Release, aber alle Systeme laufen jetzt auf den neuesten Versionen – ein solides Fundament, auf dem der UI Refresh aufgebaut werden kann.
UI Refresh — Technisches Fundament in Arbeit
Nachdem der Frühjahrsputz abgeschlossen war, bin ich endlich wieder ernsthaft zum UI Refresh zurückgekehrt – allerdings nicht ohne eine wichtige strategische Neuausrichtung (Woche 14). Ich hatte mich beim Versuch im Kreis gedreht herauszufinden, wie ich die Arbeit am visuellen Redesign mit der technischen Migration in Einklang bringen soll – und nach mehreren Rubber-Ducking-Sessions wurde die Antwort klar: Das technische Framework ist gerade der eigentliche Blocker. Es gibt unzählige Features, an denen ich erst richtig arbeiten kann, wenn Gen-3 vorhanden ist, während ein frischer Anstrich immer noch später aufgetragen werden kann. Das unmittelbare Ziel ist also, das UI-Framework zuerst zu migrieren – inkrementell statt mit einem großen, riskanten Schnitt (siehe oben).
Praktisch bedeutet das, mit den gemeinsamen Komponenten zu beginnen (dem Kopf un dem Fuß der Seite), die auf jeder einzelnen Seite über alle drei UI-Generationen hinweg zu sehen sind (Woche 15, Woche 16). Statt Code zu duplizieren, arbeite ich an einer einzigen Implementierung, die diese Komponenten für Gen-1, Gen-2 und Gen-3 gleichermaßen erzeugt. Der Fuß ist bereits fertig wurde mit Version 6.13.8 auf allen Spielwelten ausgeliefert – die erste echte Gen-3-Komponente in Produktion. Die Arbeit am Seitenkopf und dem restlichen Seitenrahmen läuft noch, und die erste vollständige Gen-3-Feature-Seite (höchstwahrscheinlich die neue DS-Suchoberfläche) folgt im Anschluss.
Der visuelle Refresh steht nach wie vor fest auf der Agenda, er wird lediglich auf nach dem "technischen Refresh" verschoben. Es ist und bleibt ein wichtiges Entwicklungsziel, besonders im Kontext unseres Early Access-Releases auf Steam und der Usability- und Onboarding-Probleme, die dieser aufgedeckt (oder vielmehr: mir wieder bewusst gemacht) hat.
Backend-API — Erster Endpunkt live
Zusammen mit dem Wartungs-Patch, der in Woche 18 ausgeliefert wurde, habe ich einen ersten read-only API-Endpunkt als geschlossene Vorschau eingeführt. Auch wenn die API mit Blick auf Dritte als Anwender entwickelt wird, ist sie vor allem eine Voraussetzung für das Gen-3-Frontend selbst – eine client-seitige Benutzeroberfläche braucht eine Server-Schnittstelle, mit der sie kommunizieren kann. Ein standardisiertes Format zu verwenden bedeutet, dass ich Client-SDKs automatisch generieren kann, was den Boilerplate-Aufwand erheblich reduziert. Der erste Endpunkt erforderte etwas mehr Planung und Design als erwartet: Fragen wie die Repräsentation physikalischer Größen in Server-Antworten müssen vorab entschieden werden und das gewählte Format dann konsistent über alle zukünftigen Endpunkte hinweg angewendet werden.
Lokalisierung & Marketing
Eine ungarische Lokalisierung wurde fertiggestellt und in Woche 7 auf Steam angekündigt. Auf der Marketingseite (Woche 9) haben Michi und ich begonnen, ein neues Tool für die Influencer-Ansprache einzusetzen – es automatisiert einen Großteil der manuellen Arbeit beim Finden von Content-Creatorn, die gut zu unseren Spielen passen würden, und gibt uns einen deutlich größeren Pool an Kandidaten sowie mehr Zeit, sie tatsächlich anzusprechen.
Ausblick
Wie zu erwarten, wird mich die UI-Arbeit noch eine Weile beschäftigen. Aber sobald ich diese hinter mir habe, werde ich direkt wieder in die Feature-Entwicklung einsteigen – mehr oder weniger genau nach dem Plan, den ich in meinem State of the Game-Video vom Januar vorgestellt habe. Die wahrscheinlichsten nächsten Punkte sind die (bereits erwähnte) DS-Suchoberfläche sowie Fares, um den ITRs wichtige neue Funktionalität hinzuzufügen.
Parallel arbeitet ein Team von Freiwilligen kontinuierlich an neuen Updates für Airport- und Geo-Daten sowie an neuen Performance-Profilen für Version 1.5 des Performance Systems, welches sich aktuell auf Paine in einer Preview ausprobieren lässt. An dieser Stelle ein riesengroßes Dankeschön für diesen Einsatz!