Brian Hicks (Lead Producer DayZ) hat sich noch einmal Zeit genommen, um in einem weiteren Anlauf die Bedeutung des neuen Animations-Systems und des Player Controllers zu erläutern. Diese sind im letzten Statusreport zusehends in den Fokus gerückt, jedoch wird immer wieder der Eindruck gewonnen, dass vielen Spielern das Gewicht dieser beiden Engine-Bereiche noch nicht bewusst ist.
Wozu ein neues Animationssystem?
Hierbei zitiert er Adam, vom dafür zuständigen Team. Dieser erklärt, dass der Wechsel zu einem neuen Modul darin begründet ist, dass sie viele neue Funktionen für DayZ hinzufügen müssten. Das bisherige Skript ist allerdings bereits so alt, durch so viele Abteilungen gelaufen und immer wieder durch Kleinigkeiten ergänzt worden. Als Resultat dessen hat der alte Programmcode nun viele unnötige Features, ist schwer zu bearbeiten und hat einen hohen Datenbedarf im Netzwerk-Traffic. Adam beschreibt diesen als „kept together with glue and duct tape.“ – also mehr oder weniger zusammengewürfelt und in wenigen Komponenten stabil.
Im Spiel sieht man die Nachteile der bisher angewendeten Version in den hakeligen Animationen, welche man nicht abbrechen, und häufig nur zeitlich verzögert einsetzen kann. Das neue System hat bereits eine Reihe gründlicher Kontrollen und Tests absolviert. Adam ist optimistisch, dass es in der Lage sein wird, vollzählig die früheren sowie weitere, neue Animationen durchzuführen. Und das sogar noch effizienter, als bisher der Fall war. Wichtige neue Möglichkeiten für die Spieler werden das Kombinieren von Handlungen sein, wie zum Beispiel Gehen und Essen, ebenso wie das Abbrechen selbiger Animationen inmitten des Ausführens.
Player Controller? Was macht der?
Das Ersetzen des bisherigen Player Controllers ist Voraussetzung für viele angekündigte Neuerungen. So zum Beispiel das ein- und ausschaltbare User Interface bei manueller, sowie bei motorisierter Fortbewegung. Ebenso wird es zuständig sein für die Soft Skills, Spieler-Handlungen, die Lebensspanne (Bartwuchs!) und das Balancing der Spieler-Kontrolle. Auch das lang erwartete Ausdauersystem wird mit diesem verbunden sein.
Doch es müssen nicht nur neue Features auf die Fertigstellung der Engine-Module warten. Brian Hicks erklärt, dass das Fixen von bestehenden Bugs und Glitches ebenfalls extrem mit diesen Entwicklungen zusammenhängt. Er erläutert den Abwägungsprozess zur Bugbehebung mit folgenden Fragen:
- Was ist das Risiko, wenn man den Bug unverzüglich behebt? – In einem Status der Entwicklung, in welchem sich alles von einem auf den anderen Tag ändern könnte, ist die Rückkehr des selben Fehlers nach nur kurzer Zeit eine große Gefahr.
- Was sind die Ziele für den bearbeiteten Build/die bearbeitete Version? Muss im Zuge dieser Fehlerbehebung der Release der Version/die Erstellung des Builds massiv hinausgezögert werden? – Verzögerung bedeutet einerseits unzufriedene Spieler, andererseits aber auch hohe Kosten für die Entwickler.
- Ist das Problem mit einer veralteten Technologie verbunden, die ohnehin ersetzt wird, zum Beispiel dem neuen Renderer? – Einer bereits „zum Tode verurteilten“ Funktion personelle Ressourcen zuzuteilen, wäre in der Softwarebranche ein schwerer unternehmerischer Fehler.
- Ist das Problem verbunden mit einem Prozess, an dem bereits gearbeitet wird? – Einen Glitch im Detail zu beheben, wenn dieser z. B. vom Animationssystem verursacht wird, würde sehr viel mehr Ressourcen benötigen, als alles daran zu setzen, das Animationssystem schneller auszutauschen – und letztendlich dadurch dem Fehler sowieso den Garaus zu machen.
- Wenn das Problem mit einem zu ersetzenden System verbunden ist, was ist die geschätzte Zeit, um:
- Das Problem selbst zu beheben
- Tests zu durchlaufen
- den zugehörigen Build auf Funktion zu testen
- Rückfallpotenzial zu testen
–> Ressourcenplanung gehört in einem Unternehmen natürlich dazu.
Zuletzt betont Brian Hicks, dass ein Großteil der Probleme aus den Kategorien Items klonen („dupen“), glitchen in Strukturen, Cheats bzgl. Schaden / Projektile und Balancing-Probleme entweder mit dem Animationssystem und / oder dem Player Controller verbunden sind. Durch Aufstellen der oben angeführten Überlegungen kommt er zu dem Schluss, dass es in den letzten Monaten keinen Sinn gemacht hätte, Zeit und Ressourcen auf die Bearbeitung der einzelnen Fehler zu verschwenden – da diese ja sowieso mit den beiden neuen Systemen wegfallen sollten, oder im schlimmsten Fall zurückkommen würden.
Unser Fazit
In unseren Augen entkräftigen die Entwickler hinter DayZ mit diesem Statement einen guten Teil der Vorwürfe, DayZ würde nicht fortschreiten, weil ja nach Monaten der Entwicklung nach wie vor die selben Bugs bestünden. Klar, die Version 0.60 lässt schon lange auf sich warten. Wir von der Guided.news – Redaktion sehen hier das Problem eher in der Informationspolitik, als in der Methodik hinter dem Entwicklungsprozess. Auf diesem Gebiet stellt es sich unseres Erachtens eher dar, als würden die Entwickler mit ihrem Vorgehen eine vorbildliche und mindestens ebenso fundiert durchdachte Version des Themas Ressourcenmanagement abliefern. Guten Gewissens zu sagen, dass nach Jahren mit Bugs und Problemen im Spiel das Team hinter DayZ den wohl am stärksten kritisierten Punkt im Early Access-Modell – eben die Bugs – komplett außen vor gelassen hat, gelingt uns an dieser Stelle nicht mehr. Der Wille, den Spielern eine verbesserte Version mit Potenzial und Effizienz zu bieten, ohne dabei die gängigen Workflows bzw. Arbeitsabläufe zu verlassen, tritt in unserer Auffassung im Fall von DayZ unter Brian Hicks schon sehr deutlich und positiv auffallend zutage.
Ach ja, ehe wir es vergessen. Das Animationssystem und der Player Controller sind noch nicht für 0.60 angekündigt, sondern werden in den noch kommenden Versionen vor dem Start in die Beta implementiert.
Erstellt in Zusammenarbeit mit Benjamin Kaspar.
