Kurzversion: Ein modulares System für Gebäude und Fahrzeuge ermöglicht flexiblere Funktionen und den späteren Fahrzeugkonfigurator. Ein Design-Template verbessert die Benutzerfreundlichkeit und Barrierefreiheit im Frontend. Performance und Fehlerbehebungen optimieren das Spiel, und neue Einsätze wurden hinzugefügt. Dispo ist wegen des Studiums weniger verfügbar, während das Team die Arbeiten am Rework fokussiert fortsetzt.
- - - - - - - - - - - - -
Dies ist eine Zusammenfassung der “Neuigkeiten zum Rework” vom Discord Server seit Ende August.
Wir haben endlich das System für die Gebäude und Fahrzeuge technisch so ausgetüftelt, dass wir hier ganz massive Vorteile im Vergleich zum aktuellen ReSi haben.
Der Programmcode für jedes mögliche kaufbare Gebäude und Fahrzeug setzt sich nun ganz modular aus verschiedenen Bausteinen zusammen. Eine Wache hat zum Beispiel den Baustein "HatPersonal" und "HatStellplätze". Mit diesen Bausteinen ist dann das ganze dahinterliegende System geregelt um neues Personal zu werben oder Stellplätze auszubauen.
Das ist bei den Gebäuden praktisch und bei den Fahrzeugen sogar notwendig, um einige Spezialfahrzeuge in Zukunft umsetzen zu können. Alle Straßenfahrzeuge haben dann entsprechend den Baustein "FortbewegungStraße" und "FährtSelbständig", sofern es sich nicht um einen Anhänger oder AB handelt. Ein Hubschrauber nutzt dann "FortbewegungLuft".
Dieses System lässt uns in Verbindung mit weiteren technischen Vorbereitungen quasi jedes gewünschte Fahrzeug in Zukunft umsetzen, ohne, dass eine neue Eigenschaft eine bestehende stört. Das war ein ganz massives Problem bei der Implementierung des WLFs, welches zu sehr vielen Fehlern und feststeckenden Fahrzeugen geführt hat. Wir haben es dadurch auch ermöglicht, den Weg für den lange gewünschten Fahrzeugkonfigurator zu ebnen, den wir damit in Zukunft implementieren können.
Dieses System ist jetzt schon zum Teil für die Gebäude implementiert. Es ist schon möglich die kaufbaren Fahrzeuge per API Schnittstelle auszugeben, um sie dann im nächsten Schritt im Gebäudeshop anzeigen zu können. Das Kaufen von Gebäuden mit der automatischen Personalgenerierung funktioniert auch schon. Ebenso die Stellplätze werden beim Gebäudekauf automatisch angelegt.
Konkret habe ich hier die Freiwillige Feuerwache umgesetzt und alle dafür notwendigen Bausteine programmiert. Die Logik, ab wann welches Gebäude gekauft werden kann (Ein Krankenhaus z.B. erst, wenn man eine Rettungswache hat), folgt später.
Wenn die Bausteine für die Freiwillige Feuerwache vollständig implementiert sind, werde ich die weiteren Gebäude vervollständigen. Ziel ist aktuell erst einmal alle Wachen und die Leitstelle zu implementieren und dann mit den Fahrzeugen zu starten. Das Krankenhaus kommt dann, wenn wir uns um den Rettungsdienst kümmern.
Beim Gebäudekauf werden nun die Adressdaten korrekt und vollständig gespeichert.
Anhand der gewählten Position des geplanten Gebäudestandorts wird eine Abfrage an unseren Kartenserver gestellt um einige Dinge zu prüfen und zu erfragen. Wir prüfen unter anderem, ob die Position im freigeschalteten Spielbereich des ReSi liegt (aktuell Deutschland, Österreich und Schweiz) und erfragen zusätzlich alle Adressdetails dieser Position (Straße, Hausnummer, Stadt, Postleitzahl, …). Diese Adressdetails werden unabhängig von den Gebäuden gespeichert und lediglich mit diesem verknüpft. So können wir das Adress-System ganz unabhängig auch für weitere Funktionen, wie zum Beispiel für die Einsatzorte nutzen. Zeit, die wir aktuell also in einige Details investieren, spart uns in Zukunft den doppelten Aufwand an anderer Stelle.
Ich hatte neulich ein spannendes Gespräch mit einem befreundeten Entwickler, der uns bei der Einrichtung der zukünftigen Serverinfrastruktur unterstützen kann. Mit ihm treffe ich mich momentan etwa einmal pro Monat in einem CoWorking Space, in dem jeder primär an seinen eigenen Projekten arbeitet und man sich bei Fragen gegenseitig unterstützen kann. Wir reden dabei aber auch immer über die technischen Hintergründe des ReSi und werden hier vermutlich in nächster Zeit bereits langsam die zukünftige Serverinfrastruktur vorbereiten, da er auf dem Gebiet sehr viel Expertise besitzt.
Da ein Gebäude nicht kostenlos im ReSi zu haben ist, habe ich zusätzlich ein universelles Transaktionssystem implementiert. Überall wo in Zukunft dem Spieler Münzen oder Marken gutgeschrieben oder abgezogen werden, gibt es jetzt eine einheitliche Funktion, um die Zahlungsfähigkeit zu prüfen und die Transaktion korrekt durchzuführen. Zusätzlich ist dadurch sichergestellt, dass immer ein passender Eintrag in die Transaktionshistorie erfolgt, um jede “Kontobewegung” nachvollziehbar zu machen. Auch hier gab es initialen Aufwand für den Gebäudeshop, der sich nachher an vielen anderen Stellen auszahlt.
Die korrekte Umsetzung aller Besonderheiten (Erweiterungen) der Gebäude ist relativ komplex. Hier geht es zum Beispiel um Stellplätze, Personal, Betten und Krankenhauserweiterungen.
Im aktuellen ReSi kommt es ja häufiger zu unvorhergesehenen Fehlern, die zum Beispiel Fahrzeuge oder Abrollbehälter nach Einsatzende an der Einsatzstelle feststecken lassen. Viele andere Fehler bekommt ihr als Spieler zum Glück nicht direkt zu spüren, wir sehen sie aber in unseren Protokollen. Um hier in Zukunft solide aufgestellt zu sein und Fehler auf das kleinste zu reduzieren, haben wir viel Zeit in ein robustes Fehlersystem investiert. An allen Stellen im Code, an denen bestimmte Fehler auftreten könnten, werden diese hinterlegt und an allen Stellen, an denen diese Funktion genutzt wird, definieren wir, was im Falle welches Fehlers konkret passieren soll, um den ReSi nicht zum Absturz zu bringen und die Situation bestmöglich zu lösen.
Das kann von automatischen Zurücksetzungen von Fahrzeugen, über Luftlinien-Routen bei Ausfall des Kartenservers, bis zu schön formulierten Fehlermeldungen an den Spielenden und uns Entwickler sehr individuell umgesetzt werden. Jeder mögliche Fehler erhält einen individuellen Workaround.
Wir möchten nun eine Funktion immer “beidseitig” umsetzen. Erst die API Schnittstellen und Logiken im Backend sowie die Speicherung der Daten in der Datenbank. Dann nutzen wir diese Schnittstellen, um diese Funktion im Frontend zu implementieren.
Wir haben lange abgewogen, ob wir für das für euch sichtbare Frontend auf ein ausgereiftes Design-Template zurückgreifen möchten. Das ist vereinfacht gesagt ein Baukasten aus den verschiedensten Komponenten wie z.B. Buttons, Menüs, ...
Dies hat für uns zwei massive Vorteile: Zum einen sparen wir vermutlich mehrere Monate an Arbeit im Frontend, in der wir diese Komponenten nicht erst von Grund auf selbst erstellen müssen und zum anderen sind diese Komponenten schon ausgereift, funktionieren in jedem Browser und sehen einheitlich gut aus.
Wir haben ein solches Design-Template getestet und geprüft, ob es wirklich in allen Belangen unseren Anforderungen entspricht. Das sah sehr vielversprechend aus, weshalb wir uns dafür entschieden haben, dieses Template zu nutzen.
Ich habe bereits einige berufliche Erfahrungen mit diesem Template und spare mir daher zusätzlich Zeit, da ich mich nicht von Grund auf dort einarbeiten muss.
Aktuell finalisieren wir hiermit die neue Leitstellenansicht, die wir euch in Kürze mit ersten Screenshots präsentieren möchten.
Für das Rework haben wir uns einige spezifische Ziele für das Frontend gesetzt:All diese Dinge werden uns mit einem Design-Template deutlich vereinfacht und wir können direkt mit der Umsetzung der einzelnen Ansichten starten.
Zudem haben wir das Login-System im Frontend implementiert und an die Datenbank angebunden.
Aktuell implementieren wir den Gebäudeshop im Frontend, hierzu sind parallel einige Vorbereitungen zu treffen, um die von der API angeforderten und zurückgesendeten Daten einfach und modular verwalten zu können.