Uh uh uh, zum Thema Balancing kann ich auch mal was erzählen :). Ich hatte mir damals was nettes dafür gebastelt, aber ich glaub ich habs noch nie vorgestellt.
Zunächst einmal: Die "Hauptressource" in meinem Wirtschaftssystem sind die Arbeiter. Ich fand es bei Anno 1602 immer komisch, dass man 4 Hütten, einen Fischer und einen Holzfäller hat und die Menschen alle irgendwie Steuern bezahlen, von denen man dann Dinge kaufen kann. Wo kommt das Geld denn her? Wie verdienen die das? Geld macht für große Städte Sinn, in einem winzigen, autonomen Dorf aber so gar nicht.
Also ist alles eine, uhm, kommunistische Diktatur. Alle Rohstoffe gehören allen, aber einer (der Spieler) ist der absolutistische Herrscher und entscheidet absolut alles alleine und unmittelbar. Deshalb gibt es kein Geld, sondern nur Rohstoffe und Arbeitskraft.
Menschen müssen ernährt werden, sonst sterben sie. Klar soweit. Das alleine wäre aber zu langweilig, deshalb gibt es die Zufriedenheit, aus der sich das Bevölkerungslimit errechnet. Das Bevölkerungslimit ist das zweite ganz zentrale Element, denn das zwingt dich all die Bedürfnisse tatsächlich zu erfüllen. Es ist unmöglich ein Dorf mit tausend Einwohnern zu haben, die alle nur Gemüse essen. Weil man damit das Bevölkerungslimit niemals auf 1000 bekommt. (Außerdem ist das System sehr nett, weil es zu jedem Zeitpunkt nur eine kleine handvoll neuer Bedürfnisse gibt die man realistisch erfüllen kann. Es ist eine Art implizites Questsystem, man sucht sich ein Bedürfnis aus, schaut, welche Technologien man dafür erforschen muss und welche Gebäude man dafür bauen muss, und schon weiß man, was man als nächstes tun sollte).
Alternativ hätte sich die Zufriedenheit auch auf die Produktivität auswirken können. Aber das Balancing war der Grund, weswegen ich mich erstmal dagegen entschieden habe (siehe unten).
Also, zum Balancing: Es gibt über 20 verschiedene Gebäude, jeweils mit einer Vielzahl an Parametern. Man muss also für grob geschätzt über 200 Variablen die richtigen Werte finden (autsch!). Alle Gebäude sind in einer .json-Datei definiert (in der ersten Version waren alle Parameter noch direkt im Code definiert, ugh). json deshalb, weil ich damit sehr bequem mit Python alles lesen und schreiben kann :)
Ich habe also über alles nachgedacht, und man merkt schnell, das nicht alle Parameter gleich kritisch sind:
Rohstoffkosten und Bauzeit: Ist fürs Balancing eigentlich fast egal. Die Baustofftypen (Holz, Stein, etc.) bestimmen, wann man ein Gebäude bauen kann, weil man erst später alle Baustoffe herstellen kann. Die Baustoffe definieren also quasi die Bevölkerungsstufe. Baukosten und Bauzeit beeinflussen im Wesentlichen nur, wie schnell sich das Spiel spielt. Ein bisschen warten ist ok, zu lange warten ist doof. Aber selbst wenn diese Werte falsch gesetzt sind, wird es nur nervig, aber nicht direkt unspielbar. Das ist bei der Lebensmittelproduktion z.B. ganz anders, es könnte ja sein, dass man 10 Arbeiter braucht um 5 zu ernähren - dann ist unmöglich und gescheitertes Balancing. Bei Baukosten kann man aber jedes Problem durch länger warten lösen.
Produzenten: Viele Gebäude sind Produzenten, d.h. in jeder Runde (Rundenlänge ist individuell für jedes Gebäude) produzieren sie
n Einheiten eines Rohstofftyps. Ggf. brauchen sie dafür aber
m Rohstoffe eines anderen Typs, der entsprechende Produzent dafür muss sich dann im Einflussbereich unseres Gebäudes befinden. Ein Gemüsefeld produziert z.B. pro Runde 2 Gemüse, der Bauernhof braucht aber 8 Gemüse pro Runde um Essen herzustellen. Ein Feld kann bis zu 8 Gemüse einlagern, d.h. ein Bauernhof benötigt 4 Felder, die reihum abgeerntet werden. (Denn 4 Felder produzieren entsprechend insgesamt 8 Gemüse pro Runde). Hier sind jetzt schon eine ganze Reihe Zahlen im Spiel, aber wie man sieht sind viele voneinander abhängig. Der Schlachter z.B. will 5 Schwein pro Runde, ein Schweinestall produziert aber nur 2. Das heißt, dass man 3 Ställe braucht um einen Schlachter voll auszulasten, aber nur 5 um 2 voll auszulasten. Jetzt kann man z.B. noch bestimmen, dass der Schlachter 5 Arbeiter braucht, der Stall aber nur einen. Wie gesagt, Arbeiter sind die wichtigste Ressource im Spiel. Deshalb will man einen Schlachter auf jeden Fall voll auslasten (weil er "teuer" ist) und baut daher eher 3 Ställe anstatt 2 (weil Ställe "billig" sind).
Diese Überlegungen haben jetzt mehr mit Spieldesign als mit Balancing zu tun. Denn man entscheidet quasi, wie man möchte, dass der Spieler spielt. Und auch wenn Produzenten im Grunde alle gleich funktionieren kann man so doch ein wenig Abwechslung rein bringen. Egal ob man jetzt sagt, dass ein Bauernhof 4 Felder oder 10 Felder bewirtschaften soll, man kann für beide Varianten später ein Balancing finden, das funktioniert (z.B. in dem die Produktivität pro Feld angepasst wird).
Arbeiter: Dieser Punkt ist mit am wichtigsten. Wie gesagt, die Hauptaufgabe des Spielers ist es immer seine Arbeiter clever und effizient einzusetzen. Welches Gebäude wie viele Arbeitskräfte braucht hat also einen enormen Einfluss auf die Balance. Die Siedlung braucht viele verschiedene Rohstoffe, und das Balancing muss derart sein, dass man alle im ausreichende Maße produzieren kann und danach nur wenige freie Arbeiter übrig bleiben. Wie wenig übrig bleiben definiert quasi den Schwierigkeitsgrad des Spiels.
Statt lange herumzuexperimentieren hab ich mich dafür entschieden, das optimale Balancing einfach auszurechnen (ha!). Ich lade also alle meine Gebäude in ein Python Script, und kann damit zunächst einmal ein paar nette Plots erstellen. Zum Beispiel für die Produktionsketten im Spiel:
Zum Vergleich ein Ausschnitt aus der json-Datei für die Definition eines einzelnen Gebäudes:
Rohstoffe werden über Strings identifiziert, dieser Plot ist also alleine schon deshalb nützlich, weil ich direkt sehe, ob die Ketten auch so aussehen, wie ich sie mir vorgestellt habe (wenn man sich z.B. verschreibt wartet das Gebäude auf Rohstoffe, die niemand produziert). Ein ähnlicher Graph wird außerdem auch benutzt um den Forschungsbaum zu erstellen (
https://zfx.info/viewtopic.php?p=66391#p66391). Den jedes mal neu zu layouten wenn man eine Technologie hinzufügen oder entfernen will ist super nervig, also ist es cool, das automatisiert zu haben.
Der Wachstum der Siedlung wird über die Einwohner (d.h. die Arbeiter) gemessen. Wenn das Balancing für jede Anzahl von Bewohnern funktioniert, funktioniert es auch insgesamt. Ich muss also für eine gegebene Einwohnerzahl berechnen, wie eine funktionierende Siedlung aussieht. Ich schaue also zuerst, wie man auf das benötigte Bevölkerungslimit kommt (hauptsächlich über das Erfüllen von Bedürfnissen wie z.B. die Produktion der richtigen Waren, oder das Vorhandensein der richtigen öffentlichen Gebäude). Daraus kann ich dann eine Liste an Gebäuden erstellen (4 Bauernhöfe, 16 Felder, 2 Brunnen, 3 Wohnhäuser und ein Lager) die mindestens benötigt werden um den Bedarf zu erfüllen. Für die Produzenten muss ich dafür z.B. den gezeigten Graph von unten nach oben durchgehen und nachrechnen. Man kann aber nicht alles einfach multiplizieren, da man ja mit Integern arbeitet - der eine Fleischer braucht eben 3 Schweineställe, weil man nicht 2.5 Ställe bauen kann. Außerdem braucht der Schuster z.B. Kleidung und Leder, die aber beide auch jeweils eigenständige Bedürfnisse sind. Wenn man also ab einer gewissen Bevölkerung den Schuster dazu nimmt, hat man vermutlich Glück, weil man zuvor schon leicht mehr Leder produziert hat als die Bewohner verbrauchen. Man muss vermutlich trotzdem die Lederproduktion weiter ausbauen, aber halt nicht so stark wie man es müsste, wenn man vorher noch gar kein Leder gehabt hätte. Synergieeffekte, quasi. Daher kann man auch nicht in jedem Rechenschritt aufrunden, sonst überschätzt man den Bedarf an Produzenten und die Balance geht kaputt. Das alles korrekt zu implementieren ist etwas frickelig und man muss aufpassen und viel testen.
Leider hab ich aber trotzdem noch einiges durch Heuristiken lösen müssen. Wie gesagt, Baukosten beeinflussen z.B. hauptsächlich, wie lange man zum Spielen braucht. Ich guck mir also an, welche Rohstoffe ich brauche um alle Gebäude die ich brauche zu bauen, und behaupte dann, dass der Spieler dafür eine gewisse Anzahl an Holzfällern und Steinmetzen bauen will - eigentlich würde ja jeweils einer reichen. Die Anzahl an Lager ist auch eher grob geschätzt, denn von wie vielen Produzenten Waren abgeholt werden können hängt entscheidend von der Wegstrecke ab - und davon wie die Lager innerhalb der Stadt verteilt sind, weil sich unterschiedliche Lager beim abholen ein wenig Konkurrenz machen - aber das ist eine andere Geschichte.
Nun gut, am Ende hab ich dann für eine gegebene Dorfgröße eine Liste an Gebäuden die sich im Dorf befinden müssen. Das rechne ich dann für jede Anzahl von Einwohnern aus und bekomme folgenden großartigen Plot:
Die blaue Linie zeigt, wie viele Dorfbewohner man mindestens braucht um die Anzahl Dorfbewohner (grün) zu versorgen. Man sieht hier, dass die Linien nahe beieinander sind, aber die blaue mal über und mal unter der grünen liegt. Man sollte meinen, dass die Anzahl der benötigten Arbeiter niemals über der Anzahl der verfügbaren liegen darf, aber aus mehreren Gründen stimmt das nicht. Zum einen ist die Gebäudeliste wie gesagt nicht komplett akkurat, sondern ein paar Werte sind nur gut geschätzt. Zum anderen versucht man ja meistens mehr zu produzieren als man verbraucht, daher man meist einen Vorrat von allen Rohstoffen im Lager mit dem man sich über Dürreperioden retten kann. Das Skript simuliert bei weitem nicht die gesamte Spiellogik, man muss die Ausgabe eher als einen Equilibriumszustand für eine langfristig stabile Siedlung ansehen in dem keinerlei kurzfristige Schwankungen berücksichtigt werden.
Wichtig ist auch die orangene Linie, die das Bevölkerungslimit anzeigt. Denn Waren produzieren macht ja Menschen glücklich und erhöht das Bevölkerungslimit. Das Bevölkerungslimit sollte immer ein Stück über der Anzahl der benötigten Arbeiter liegen. In diesem Beispiel sieht man auch, dass ab 250 Einwohnern Schluss ist, es gibt dann keine zusätzlichen Bedürfnisse mehr die man erfüllen kann um das Limit weiter zu erhöhen. Das ist zugegebenerweise merkwürdig. Aber entweder hat man dann halt an diesem Punkt einfach gewonnen, oder man schaltet eine zusätzliche Mechanik frei, die unbegrenzten weiteren Wachstum erlaubt. Muss ich mir noch überlegen.
Mit diesem Plot weiß man jetzt also dass alles ausbalanciert ist und im Spiel so funktionieren wird. Aber der Plot ist auch detailliert genug, um darin konkrete Probleme zu identifizieren. So gibt es etwa mehrere große Stufen (z.B. bei 120), das sind die interessanten Phasen im Spiel in denen man z.B. neue Produktionsketten baut die schwierig zu bauen sind, dafür aber einen großen Einfluss auf das Dorf haben.
Außerdem kann man sich die Gebäudeliste an jeder Stelle anschauen. Dann sieht man etwa, dass eine Siedlung mit 120 Einwohnern 2 Imker, aber 15 Fischer benötigt. Moment, klingt das nicht irgendwie albern? Nun, man hat bereits ausgerechnet, dass die Balance so prinzipiell funktioniert, aber ob man die Proportionen so mag ist eine ganz andere Frage. Aber jetzt kann man ein paar Werte anpassen, so dass man später 4 Imker und 7 Fischer braucht (z.B. in dem man die Produktivität der Fischer verdoppelt). Anschließend rechnet man wieder aus, ob die Balance passt. Das ganze geht in mehrere Richtungen, man kann z.B. auch sehen, wie sich die Gesamtzahl der Arbeiter auf die unterschiedlichen Bereiche aufteilt.
Ich versuche in der Regel etwas Varianz reinzubringen. Manche Gebäude sind teuer und brauchen vlt. Rohstoffe die es nur an bestimmten Teilen der Karte gibt. Diese Gebäude sind dann eher wertvoll. Andere baut man dafür häufiger und macht sich weniger Gedanken darüber. Es gibt z.B. mehrere Kapellen aber in der Regel nur eine einzige große Kirche. Das sind wieder Fragestellungen die viel mehr in den Bereich Spieldesign gehen. Das Balancing dient am Ende nur dazu sicherzustellen, dass das Spieldesign so funktioniert wie geplant.
Insgesamt funktioniert das System soweit ziemlich gut. Ich hab damit schon viel rumgespielt und z.B. mal ein sehr knappes Balancing erzeugt, das mich dann auch tatsächlich richtig gefordert hat, aber letztendlich spielbar war. Und das ganze ohne jegliches Herumexperimentieren oder Testen, weil eben alles berechnet ist. Ja ok, testen muss man trotzdem, weil es ja wie gesagt nur näherungsweise korrekt ist. Aber insgesamt ist der Testaufwand wirklich sehr gering.