Der Landvogt

[Schrompf]

So richtige Gameplay-Statistik zu haben, ist schon echt sexy. Davon träume ich, seit ich für den letzten Arbeitgeber große Übersicht-Panels auf 4k-Monsterfernsehern in jedem Büro hatte, auf denen tausendundein Grafana-Board in Echtzeit zu sehen war.

[Endgegner]

Wären solche Diagramme (oder allgemein Statistiken, unabhängig von der Darstellungsform) nicht auch für einige Spieler interessant? Ich habe mir früher jedenfalls gerne mal nach einem Skirmish-Match die Statistiken angesehen, wenn es die Möglichkeit dazu gab. Die Zahlen schwarz auf weiß zu sehen hat doch oft eine zufriedenstellende Wirkung auf Menschen (wenn die Zahlen gut sind). ;)

Vielleicht kann man als Spieler dadurch auch besser nachvollziehen, warum die eigene Strategie nicht funktioniert hat und das Dorf ausgestorben ist.

[Jonathan]

Ja, ich hatte schonmal überlegt, ob das Lagerhaus historische Lagerbestände anzeigen soll. Dann sieht man z.B. leicht ob man aktuell zu wenig Nahrung produziert und man nur deshalb keine Hungersnot hat, weil die Lager gerade noch sehr voll sind (aber es bald nicht mehr sein werden!).

Ein bisschen hab ich mir aber gedacht: Was ist eigentlich die Herausforderung? Im Extremfall hast du im Hintergrund einen KI-Assistenten, der dir genau sagt, was du tun solltest ("Baue folgendes Gebäude an diese Stell"). Hat man keine Lagerstatistiken muss der Spieler halt von selber alle paar Minuten auf den Lagerstand schauen um Katastrophen zu vermeiden. Was nervig sein kann, aber in einer kleinen Siedlung, wenn man eh nur 5 Waren hat, ist das vielleicht gut so? Man könnte die Dorfstatistiken ja auch später im Spiel freischalten, durch einen Stadtverwalter den man bauen muss oder so. Die Spielmechanik geht dann von sehr Kleinteilig auf abstrakteres High-Level-Management über - was ja nett sein könnte.

Naja, mal schauen. Ich hatte diese Statistiken mal ausprobieren wollen, bin aber aktuell ein klein wenig enttäuscht, dass ich nicht so wirklich irgendetwas nützliches daraus gelernt habe. Ich hab überlegt, die Daten auch automatisch hochladbar zu machen, um mehr Statistiken von mehr Spielern sammeln zu können. Aber einerseits werden es vermutlich eh nicht so viele durchspielen (vielleicht erstmal 20 Leute?) und andererseits müsste das Datensammeln natürlich optional sein (man hat ja Prinzipien), wodurch sich die Zahl vielleicht nochmal halbiert. Meh, also ein paar Tage arbeit, potentielle Sicherheitslücken wegen online Kram und am Ende hat man ein kleines Häufchen Daten, aus denen man auch nicht so viel schlauer wird. Oh well :D

[Jonathan]

Ich hab jetzt die Baustufen des Doms fürs erste fertig. Insgesamt gibt es jetzt 7 Bauabschnitte:

Video:

cathedral_stages.mp4

(3.41 MiB) 27-mal heruntergeladen

Das ist jetzt in Blender mit Cycles gerendert, was die netten Global-Illumination Effekte erklärt. Es gibt ein paar Renderfehler (schwarze Stellen) die durch überlappende Geometrie in Cycles enstehen, in der Engine hat man die nicht, dafür ist das Shading aber weniger hübsch.

Für die Spieleengine muss ich noch statische AO-Maps backen, allerdings ist das aktuell noch ein manueller Prozess: Jeder Bauabschnitt besteht aus diverse Sub-Models, teilweise mit Modifiern etc. Daraus muss jeweils ein einzelnes Mesh gemacht werden, dann muss die AO-Map gebaked werden (wofür man ggf. auch wieder Parameter anpassen muss) und dann müssen die Materialien angepasst werden, damit beim Export auch die AO-Maps verwendet werden. Das werde ich also einmal ganz am Ende machen, wenn ich am Modell nichts mehr anpassen will (weil Änderungen ja ggf. alle Bauabschnitte betreffen...).

Man könnte Vieles an vielen Stellen noch ausbauen und detaillierter machen. Aber das war so schon wieder viel mehr Arbeit als erwartet und so langsam reicht es ehrlich gesagt. Dafür ist aber jetzt auch quasi alles fertig. Die aktuellen ToDos:

• Baustufen balancen (Rohstoffkosten, Bauzeit, Arbeiter). Im Gegensatz zur Wirtschaft gibts hier aber kaum falsches Balancing, die Wartezeit verändert sich halt einfach. (In der übrigen Wirtschaft könnte es passieren, dass man 30 Arbeiter braucht um Nahrung für 20 zu produzieren, was das Spiel insgesamt unmöglich machen würde).
• Tutorial fertig bauen.
• Mehr Tooltips und Erklärungen im Spiel.
• 1-2 zusätzliche Maps bauen und etwas dekorieren.
• Ein paar UI-Grafiken austauschen (alles 2D).

[Endgegner]

Die einzelnen Bauschritte sehen nach viel Arbeit aus! Dafür sind sie aber auch richtig gut geworden, mit viel Liebe zum Detail, wie z.B. dem Dachstuhl oder dem Kreuz im Inneren des Doms. Keine Ahnung ob man in dieser Epoche tatsächlich auf diese Weise gebaut hat, aber darauf kommt es hier nicht an, denke ich. In meiner Laienvorstellung sehen die Schritte plausibel aus. ;)

Aber vorne scheint der Haupteingang zu fehlen? Sieht nach einem großen Bleiglasfenster aus.

[Jonathan]

Dankeschön :)

Hier mal, als Vergleich, eine Baustufe aus der alten Version:

Damals gab es nur ein fertiges Modell, für die Baustufen wurde das dann einfach auf unterschiedlichen Höhen (etwas ungleichmäßig) abgeschnitten. Die Wände haben keine Dicke und teilweise sind die Texturen recht kaputt.

Leider gab es heute davon nur noch die exportieren OBJ-Dateien, und die hatten auch optimierte Meshs, so dass die Dreiecke sehr hässlich sind und man das quasi überhaupt nicht mehr sinnvoll editieren kann. Auch die Texturen waren inklusive AO in eine große Colormap gebacken, bei jeder Geometrieänderung hätte man es also komplett neu texturieren müssen. Auch bloß Materialien austauschen war dementsprechend unmöglich.

Nach einer kurzen Bestandsaufnahme hab ich mich dann eben dafür entschieden, komplett von vorne anzufangen. Ist das bisher komplexeste Gebäude, das ich modelliert habe, rückblickend hätte sich sicherlich vieles anders machen sollen. Beispielsweise hätte ich direkt mit dem Innenraum anfangen müssen, denn den nachträglich einzufügen war fast nochmal genau so viel Arbeit, wie das ursprüngliche Modell.

Was die Authentizität angeht: Das neue Modell ist dank Fotos und Grundrisszeichnung von den Proportionen wesentlich akkurater. Die Inneneinrichtung hab ich mir auch angeschaut, da dann aber sehr viel vereinfacht, weil ich dafür dann doch keine Puste mehr hatte. Das hätte sich nur gelohnt, wenn man in der Ego-Ansicht während dem Spielen da durch laufen würde, oder sowas. Ich überlege auch immer noch Details wie Baugerüste und Materialstapel und Kräne und Werkzeuge hinzuzufügen, aber als nächstes will man dann Arbeiter und dann korrekte Animationen wie Stein für Stein aufeinander gesetzt wird, und dann bin ich in hundert Jahren noch nicht fertig. Pharao hat damals glaube ich den Pyramidenbau Stein für Stein simuliert, aber das war auch, wie ich einfach mal behaupte, viel einfacher :D

Das mit der Tür - tja. Das ist in der Tat einfach das Fenstermaterial. Vielleicht sollte ich das noch austauschen. Es gibt eigentlich auch Statuen am Eingang, ich hab aber kein passendes fertiges Modell gefunden, und selber machen, tja, zu viel Zeit. Letztendlich ist es schwer abzuschätzen, wie lange und detailliert sich Spieler das ingame wirklich anschauen - ist ja bloß eines von vielen Gebäuden..


Übrigens: Das Tutorial ist jetzt zu gut 2/3 fertig. Das Skript dazu ist aktuell gut 450 Zeilen lang, da kommt schon einiges zusammen. Für jeden Schritt müssen Ziele definiert werden, dann erklärt werden und dann der Erfolg abgefragt werden. Und das braucht viele, viele neue Skriptanbindung, fast für jeden Schritt etwas neues, z.B: "10 Holz produziert", "2 Gebäude mit einer Straße verbunden", "Versorgung mit Kleidung auf 75%", "Forschungsfenster geöffnet". Und dann ganz viel Kleinkram um dafür zu sorgen, dass der Spieler keinen Quatsch macht und nicht stecken bleibt.

[Jonathan]

Kurzes Update, diesmal leider ohne Bilder, da sehr technisch:

Hintergrund:
Das Problem am Tutorial ist, dass der Spieler Spielprinzipbedingt viele Freiheiten hat und damit viel Quatsch machen kann. Veranschaulichendes Beispiel: Holzproduktion. Der Spieler soll einen Holzfäller bauen, um Holz produzieren zu können. Baut er stattdessen ein Haus, hat er vlt. nicht genügend Baumaterial mehr für den Holzfäller. Baut er ihn nicht in der Nähe vom Wald, findet der Holzfäller kein Holz und produziert auch nichts. Selbst wenn man jetzt Baumaterial für einen zweiten Holzfäller hätte, hat man vielleicht keine Arbeitskräfte mehr, weil die nutzlos im ersten Holzfäller rumdödeln. Klar, man könnte dem Spieler unendlich Baumaterial geben. Oder irgendwie unendlich Arbeitskräfte. Oder erkennen, wenn der Spieler Quatsch gemacht hat und alles zurücksetzen. Das ist alles irgendwie doof. Oder man erlaubt nur genau das richtige Gebäude an genau der vorgegebenen Stelle. Das ist auch doof, weil der Spieler ja lernen soll, selber richtige Entscheidungen zu treffen. Insgesamt alles irgendwie schwierig.

Ich mache jetzt eine Kombination aus verschiedenen Dingen, insbesondere aber das folgende: Anstatt darauf zu vertrauen, dass die Siedlung schon irgendwie sinnvoll über die Zeit aufgebaut wird, starten verschiedene Phasen des Tutorials jeweils komplett von vorne mit einer kleinen, vorgegebenen Siedlung, in der man jetzt ein Problem lösen muss (z.B. Kleidung produzieren). So ist zumindest garantiert, dass selbst wenn man ein wenig Quatsch gemacht hat, sich dieser nicht akkumulieren kann und man immer bei einer klaren und sauberen Problemstellung anfängt.

Dafür muss im im laufenden Spiel quasi einen halben Spielstand laden: Objekte in der Welt werden ersetzt, aber das Level-Skript oder die Spielzeit werden nicht zurück gesetzt, sondern laufen weiter. Ich lade also nur einen Teil eines Savegames, und überspringe andere Teile.

Mein eigentliches Problem:
Ich verwende ein eigenes Binärformat zum speichern. Es gibt natürlich zig fertige Lösungen dafür, aber zu 50% wollte ich einfach auch etwas eigenes bauen, und die anderen 50% sind "ich habe sehr spezielle Vorstellungen, welche Features ich genau will". Insgesamt passiert wenig aufregendes, man schmeißt im Prinzip einfach nacheinander Variablen in einen Container der dann in einer Datei landet. Das soll explizit kein strukturiertes Format wie JSON sein, in gewisser Weise ist der Code zum speichern / laden die Dokumentation des Formats, und nicht das Format selber. Metainformationen gibt es hauptsächlich um Bugs zu erkennen, wenn Speicher- und Ladefunktionen unterschiedliche Dinge machen (man hat z.B. die neue Variable nur in einer von beiden hinzugefügt). Insgesamt funktioniert das alles recht einfach und robust.

Jetzt war aber das Problem dass ich beim Laden einen Teil der Daten überspringen möchte, im alten Format ging das aber nicht. Beispielsweise kann man ein array<int, 10> speichern und laden, ohne sich die Größe merken zu müssen, die steht ja schließlich im Typ drin ("der Code definiert das Format"). Bloß hat man den Typ ja leider nicht, wenn man wirklich einen Teil einfach überspringen möchte.

Ich musste jetzt also das Format umbauen um doch ein paar mehr Informationen darin abzulegen um diese Art von Funktion zu erlauben. Gleichzeitig musste das alte Format aber weiterhin funktionieren, da ich nicht alle Savegames verlieren und das Tutorial wieder komplett neu bauen möchte. Also hab ich gestern den Tag damit verbracht, mir die Anforderungen an das neue Format zu überlegen und alles so umzuschreiben, dass ich jetzt im neuen Format speichern, aber sowohl das alte wie auch das neue Format laden kann. Hat ein wenig gedauert, aber jetzt funktioniert alles, vielleicht wird der Landvogt damit ja doch noch diesen Oktober fertig! :)

[Schrompf]

Serialisierung! So wichtig. In anderen Programmiersprachen schmeißt man sein zentrales Szene-Objekt auf den JSON-Serialisierer und ist fünf Minuten fertig, und dafür lädt es dann halt 500ms. Ich mag so binäres Gebastel. Neulich im Stammtisch meinte mal jemand "oh, das war's schon?" zum Spielstand-Laden in Splatter, weil man das halt auch im Takt der MachineGun machen kann. Und das geht halt nur mit ehrlicher bäuerlicher Handarbeit :-D

[Jonathan]

In anderen Programmiersprachen schmeißt man sein zentrales Szene-Objekt auf den JSON-Serialisierer und ist fünf Minuten fertig, und dafür lädt es dann halt 500ms.

Ja, aber das ist nur die halbe Wahrheit. Es ist in 5 Minuten fertig, aber das heißt noch lange nicht, dass es nach 5 Minuten funktioniert. Spoiler Alert: Tut es nicht und das zu fixen dauert ungefähr so lange, wie es gleich richtig zu machen.

Ich habe mir z.B. gut überlegt, welche Daten ich speicher und welche nicht. Beispielsweise ist das Balancing, also die Eigenschaften der einzelnen Gebäude ja vielleicht kein Teil des Savegames. Ich will auch nicht unbedingt, dass das Hintergrundlied bei genau dem selben Takt weitergeht wo man das Spiel gespeichert hat. Das soll schön von vorne anfangen. Andere Sounds wiederum müssen vlt. mit dem Spielgeschehen synchronisiert sein. Ich kann auch nicht einfach den Zustand der Skriptengine speichern, immerhin will ich vlt. das Levelskript anpassen können. Also gibt es einen sauber definierten globalen Skript Speicher (eine handvoll Variablen) der Teil des Savegames ist, darüber hinaus ist alles Scripting stateless. Klar bedeutet das nicht, dass man jetzt beliebig Änderungen am Spiel vornehmen kann und alle Savegames funktionieren garantiert weiterhin. Aber wenn dir bewusst ist, was genau ein Savegame ist, dann weiß du auch, welche Änderungen du machen kannst und welche nicht.

Das ist das selbe wie mit AI-Coding. Man kann Komplexität und in einigen Ausnahmefällen einfach so ignorieren, oft sollte man wissen, was im Hintergrund eigentlich passiert.

(Ich glaube btw. nichtmal unbedingt, dass ich 500 Spielstände pro Sekunde laden kann - aber ich verstehe was wo passiert, und könnte es dementsprechend verbessern, sobald der Bedarf dafür größer wird, als der für das nächste Feature das zur Spielfertigstellung noch fehlt.)