Der Landvogt

[grinseengel]

Deine Ideen hören sich recht gut an. Ich möchte das aber nicht aus­ba­lan­cie­ren. Wird sicherlich ein Mordsspaß. Daran ist bei meinem Projekt überhaupt nicht zu denken. Das wird viel linearer ablaufen. Selbst bei einer linearen Konzeption ist das schon schwer. Z.B. Zelt = 5 Siedler, Haus = 10 Siedler, Konsumrate steigt mit jeder Ausbaustufe. Oder Krankheitsrisiko steigt linear an je mehr Siedler je Haus etc.

Es macht dann Sinn sich organisatorisch Gedanken darüber zu machen wie das Dorf aufgebaut sein sollte. Wo baue ich Parks, Produktionsanlagen, Wohnanlagen, damit die Wohnqualität dann zu einer Weiterentwicklung führt. Besonders bei Terrains, die über Brücken verbunden werden müssen. Wo stehen welche Rohstoffe zum Abbau zur Verfügung. Später dann noch Handelsreisende ins Spiel bringen, also Waren herstellen, die verkauft oder getauscht werden.

[Jonathan]

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.

[Matthias Gubisch]

Also den Teil dass die Effektivität der Produktion abhängig von der räumlichen Nähe ist finde ich toll, damit zwingt man den Spieler sich Gedanken über die Stadtplanung zu machen. Auch könnte ich mir gut vorstellen die Produktion von der Zufriedenheit der Arbeiter abhängig zu machen.
Wie diese bestimmt oder beeinflusst wird da gibt es ja viele Möglichkeiten (Whiskey/kein Whiskey hast du ja schon genannt)
Was ich nicht gut finden würde, wäre eine zufällige Schwankung der Produktion die ich als Spieler nicht beeinflussen kann, ich will meine Produktionsketten ja planen können, und nicht hoffen müssen das das alles schon irgendwie tut und wenn nicht am Ende einen Aufstand zu haben für den ich nix kann weil der Zufallsgenerator halt grad blöde dinge getan hat...

[Jonathan]

Ja, aber Boni hatte ich mir ein paar Gedanken gemacht, ich bin mir aber noch nicht sicher, wie das funktionieren soll. Gerade wenn man sagt, dass man sehr kontinuierliche Effekte haben will, die z.B. von der Zufriedenheit abhängen.
Klar, man könnte einen Boni haben, dass z.B. Felder 10% schneller arbeiten. Nur bringt das nichts, weil man immer noch 4 Felder für einen Bauernhof braucht. Aktuell ist halt die Anzahl der Gebäuden in einer Produktionskette sehr rigide. Man könnte also sagen, dass Felder doppelt so schnell arbeiten, jetzt braucht man nur noch 2 Felder statt 4. Aber dann hat man halt sehr konkrete und große Schritte, d.h. es ist schwer zu sagen, dass man jetzt Aufgrund der leicht erhöhten Zufriedenheit einen 15% Bonus bekommt. Man könnte jetzt das Gebäude-Verhältnis in den Produktionskette variabler machen, aber die einfachste Lösung wäre es, nur die Produktivität des letzten Gebäudes der Kette zu verändern (bei gleichbleibendem Ressourcenverbrauch). Denn wenn man an dieser Stelle statt 12 Brot auf einmal 13 Brot produziert ist das ok, weil ab dem Zeitpunkt ab dem Dinge im Lager sind alles "kontinuierlicher" ist.

Andererseits können so Systeme auch zu selbstverstärkenden Effekten führen. Wenn die Leute glücklich sind, produziert man viele Waren. Werden die Leute aber aus irgendeinem Grund doch unglücklich müsste man eigentlich mehr Waren produzieren um sie wieder glücklich zu machen, aber durch die gesunkene Zufriedenheit produziert man jetzt weniger Waren wodurch die Bewohner noch unzufriedener sind.
Das finde ich auf den ersten Blick etwas fragwürdig. Andererseits könnte man genau so eine Mechanik quasi als Profi-Modus mit höherem Schwierigkeitsgrad einbauen, und der Spieler muss nicht nur permanent eine funktionierende Siedlung haben, sondern eine sehr effiziente Siedlung, weil sonst schnell alles den Bach runter geht.

Naja. Erstmal die bisherige ToDo-Liste abarbeiten, dann sehen wir weiter :D

[grinseengel]

Sehr beeindruckend deine Ideen und deine Ausführungen zur Spielbalance. Das umzusetzen bin ich nicht in der Lage und ich verstehe auch so manche Prozesse die da angedacht hast nicht wirklich. Ich hoffe das der Spieler das dann auch versteht welche Hebel er wo, wie und wann zu verstellen hat.

[Jonathan]

Wenn du konkrete Fragen hast, kann ich die gerne beantworten. Der Text ist ein bisschen eskaliert, ich glaube ich habe da letztendlich eine Stunde lang dran geschrieben (:D), da wäre es schade, wenn es das nicht wert war. Andererseits war die Intention aber auch nicht, unbedingt jedes Detail zu erklären, sondern eher das 'Big Picture' zu beschreiben: Also welche Strategien ich verwende um das Problem zu lösen und wo die interessanten Schritte bei der Umsetzung waren.

Was den Spieler angeht: Ich hoffe, dass sich der Spieler viel viel weniger Gedanken um die Balance machen muss, als ich. Letztendlich ist die Game-Loop ja ungefähr so:

- Halbfertige Siedlung in der 3D Welt angucken
- Nach Problemen suchen:
- - Zu wenig Waren (z.B. Kleidung): Mehr Produktionsketten für diese Ware bauen
- - Untätige Gebäude (z.B. Schneider): Die Lieferanten überprüfen (für mehr Schaffarmen im Einzugsbereich sorgen)
- - Zu wenig Arbeiter: Entweder Bevölkerungslimit erhöhen oder unwichtige Betriebe stilllegen
- - Waren werden zu langsam abgeholt: Mehr Lagerhäuser bauen oder für kürzere Wege sorgen
- Alles ist in Ordnung. Überlegen wie man die Stadt ausbauen kann.
- - Nächste Technologie erforschen, neue Produzenten bauen, mehr Häuser, etc.
- Zurück zum ersten Schritt

Theoretisch muss man da gar nicht über Zahlen nachdenken. Wenn man ein Problem korrekt identifiziert hat sollte die Lösung auf der Hand liegen, gute Balance bedeutet dann, dass die Lösung umsetzbar ist und das Problem löst. D.h. meine Aufgabe ist es, für (fast) jede Siedlung zu garantieren, dass es einen Zustand gibt in dem sie funktioniert. Die Aufgabe des Spielers ist es, diesen Zustand zu finden und zu erreichen.

[Matthias Gubisch]

Sehr spannende Gedanken, bin mal gespannt was ihr davon dann umsetzt

Die letzte Version haut auf jeden Fall genuegend Spass gemacht dass ich einen neue Version wieder spielen wuerde :)

Wenn ich mal groß bin bau ich um meine Rendererexperimente auch mal ein Spiel :D

[Jonathan]

Was haltet ihr von der Idee eines Videotutorials? So eine Art Lets-Play, in dem die Grundlagen vorgestellt und erklärt werden? Wäre sowas als Ersatz für ein Ingame Tutorial geeignet? Würdet ihr sowas anschauen bevor ihr das Spiel spielt und wie lange sollte/darf so ein Video sein?

[NytroX]

Ich würde es nicht angucken.
Und erinnere dich: in deine Manual hat auch schon niemand reingeschaut. Und die war nicht groß.
Alles was nicht ingame ist, kannste vermutlich vergessen. ¯\_(ツ)_/¯

[Schrompf]

Ja, am Tutorial führt kein Weg vorbei.

[bruebaker]

Jeb glaube auch das es ohne ingame tutorial nicht geht, gerade in einem Aufbau spiel kann man das doch ganz gut mit soner art berater verknüpfen, also einem ingame Charakter

[Endgegner]

Jeb glaube auch das es ohne ingame tutorial nicht geht, gerade in einem Aufbau spiel kann man das doch ganz gut mit soner art berater verknüpfen, also einem ingame Charakter

Karl Klammer! ;)

Aber Spaß beiseite – ich glaube auch, dass ein Ingame-Tutorial hier die beste Wahl wäre. Entweder ins Hauptspiel eingeflochten (dann sollte es entweder überspringbar oder zumindest nicht zu aufdringlich sein) oder als separater Menüpunkt.

Oft helfen auch schon ein paar Tooltips oder Beschreibungstexte weiter, z.B. wenn man sich nicht an alle Spielmechaniken erinnern kann oder nach längerer Pause wieder spielt.

[Jonathan]

Gut, das Stimmungsbild ist da sehr eindeutig :D

Glücklicherweise hatte ich ja schon vor einiger Zeit Angel-Script in meine Engine integriert. Mit ein paar Hilfsfunktionen und entsprechenden Skript-Anbindungen sollte man damit was Gutes umsetzen können.

Meine Idee ist es jetzt erstmal, ein Textfenster zu haben (bzw. Bilder einbetten ist auch möglich), das eine kurze Erklärung anzeigt und dann eine Aufgabe stellt ("Baue 5 Wohnhäuser") bevor man sich zum nächsten Text weiter klicken kann. Und so werden dann Schritt für Schritt alle wesentlichen Mechaniken mal gezeigt.

Um das ganze ein wenig anzureichern und nebenbei nicht eskalieren (im Sinne von Entwicklungsaufwand) zu lassen, will ich noch kleine "Rätselszenarien" einbauen. Um in einem Spiel, in dem man viele Möglichkeiten hat, auf alles was der Spieler tut reagieren zu können, muss man schon echt viel investieren. Was, wenn er eigentlich nur kurz die Holzproduktion vervollständigen soll, aus versehen aber die halbe Siedlung abreißt? Stattdessen will ich in vielen der Schritte einfach einen kleinen, sinnvollen Spielzustand laden und dem Spieler dann nur minimale Möglichkeiten geben.
Beispielsweise soll ein Straßennetz gebaut werden um den Holz vom Holzfäller ins Lager schaffen zu können. Dann wird eben ein Spielstand geladen, in dem man schon den Holzfäller und das Lagerhaus hat, aber die Straße noch nicht gebaut wurde, und sämtliche Handlungen, abgesehen vom Straßenbau, werden deaktiviert. Oder es sind zu wenig Arbeiter für alle Betriebe da. Man könnte jetzt mehr Häuser bauen, aber das ist deaktiviert, also ist der Spieler gezwungen die "Still legen" Mechanik zu verwenden um die Produktion zu priorisieren. Außerdem kann man Dinge wie Nahrungsverbrauch deaktivieren, um ein bisschen mehr Flexibilität zu bekommen und Siedlungen mit nur sehr wenig Gebäuden, die so nie in der Realität funktionieren könnten, zu verwenden.
Der Nachteil ist, dass der Spieler nicht Schritt für Schritt seine eigene Siedlung hochzieht. Der Vorteil ist aber, dass zu jeder Zeit jeder Tutorialschritt ausführbar ist und man immer in sehr vorhersehbaren Zuständen ist. Und der Spieler gezwungen wird, genau das zu tun, was er lernen soll.

[Jonathan]

Habe endlich nochmal weiter programmiert. Die gute Nachricht: Das Spiel ist besser (und fertiger) als ich es in Erinnerung hatte. Es ist beinahe komplett funktional, einzig gegen Ende, wenn man den Dom baut, fehlen noch ein paar Features um es interessanter zu machen. Ansonsten fehlt massig Polishing, aber dann wirds supi.

Die Grundfunktionen fürs Tutorial stehen auch soweit. Ein paar weitere Anbindungen für das Skriptsystem fehlen noch, aber dann muss ich nur noch das Tutorial umsetzen und irgendwie alle wichtigen Dinge damit abdecken. Schaun wir mal.

Heute habe ich allerdings mit Erschrecken festgestellt, dass mein Balancing-Tool nicht mehr tut. Beim Bauen viel mir auf, dass man viel zu viele Fischerhütten braucht und trotzdem ständig zu wenig Fisch hat. Und anstatt dumm zu raten, will ich wieder genau ausrechnen, wie man die Produktionsrate anpassen muss, damit es ausgeglichen ist.

Nur habe ich leider zwischenzeitlich das Bedürfnissystem komplett umgestellt. Früher musste man der Reihe nach bestimmte Bedürfnisse erfüllen um mehr Bürger zu bekommen. Das wirkte immer komisch und gekünstelt und war irgendwie auch schwer zu verstehen. Im neuen System gibt jedes erfüllte Bedürfnis Zufriedenheitspunkte aus denen dann die maximale Bevölkerungszahl abgeleitet wird ("Von einer größeren Stadt erwarten wir auch mehr" ist die Grundidee. Das ist immer noch irgendwie leicht komisch, aber irgendein System dieser Art benötigt man halt einfach). Jetzt kann man Bedürfnisse auch nur zum Teil erfüllen und hat zudem viel mehr Auswahl, was man wann erfüllt, was den Spielablauf viel spielerfreundlicher macht (Du musst die Zufriedenheit erhöhen, kannst dir aber aussuchen, wie).

Aber andererseits ist es jetzt auch super schwer zu sagen, welche konkreten Bedürfnisse eine Stadt mit 80 Einwohnern denn nun hat, welche Gebäude man braucht um diese abzudecken und ob diese Gebäude insgesamt knapp unter 80 Arbeiter benötigen (mehr wäre unmöglich, signifikant weniger wäre zu einfach...). Denn jetzt gibt es zig Kombinationen von erfüllten Bedürfnissen, die diese Bewohnerzahl ermöglichen, und vermutlich möchte man als Spieldesigner jetzt, dass die meisten, aber vielleicht nicht alle, davon tatsächlich umsetzbar sind. Also alles neu schreiben. Muss aber erst noch überlegen, wie genau...

[gombolo]

Beeindruckend. Finde die Grafik echt gut und wenn ich reinzoomen sieht es immer noch gut aus :D Der erste Eindruck ist überzeugend. Werde mich mal die nächsten Abende daran setzen und etwas spielen ;)

[bruebaker]

Ein Screenshot vom aktuellen Stand. Man sieht eine Siedlung mit ~150 Einwohnern, diverse Betriebe, öffentliche Gebäude und viele fleißige Pferdefuhrwerke, die all die Waren transportieren. Neu sind unter anderem die Wassermühle und Fischerhütten, man muss also endlich die Flüsse ganz konkret in die Stadtplanung einbeziehen und sie sind nicht länger bloß Hindernisse, die man umbauen muss.

Landvogt_2021-07-27_16-24-19.jpg

Schaut man zu genau hin, sind noch diverse kleine Grafikglitches zu erkennen. Aber insgesamt bin ich schon ganz zufrieden mit dem aktuellen Zustand.

Oh: Und im Gegensatz zu Version 1.0 kann man jetzt jederzeit die Fenstergröße beliebig ändern (das ging schon seit einer Weile) und jederzeit zwischen Vollbild und Fenstermodus wechseln (das ist neu). Außerdem hab ich das Scrolling etwas weicher gemacht. Während der Entwicklung spiele ist der Übersichtlichkeit wegen eigentlich immer im Fenstermodus, jetzt jederzeit umschalten zu können, wenn man mal ernsthafter daddeln will ist aber definitiv nett :)

Wow schaut echt gut aus. Schön das du voran kommst!

[Jonathan]

Wow schaut echt gut aus. Schön das du voran kommst!

Vielen Dank!
Der Screenshot ist ja schon wieder ewig her, es wird wirklich bald Zeit für den neuen Release. Gerade ist leider wieder viel zu viel an nicht-essentiellen (d.h. nicht Hobbyspieleprogrammierung betreffend) Dingen zu tun, aber ich hoffe über den Sommer nochmal deutlich weiter zu kommen. Eigentlich "nur" noch polishing, aber gut, das sind wohl 80% der Arbeit. Andererseits fand ich das beim Hoppelhasen recht cool was wirklich fertiges abzuliefern, also mal schauen.

[bruebaker]

Wow schaut echt gut aus. Schön das du voran kommst!

Vielen Dank!
Der Screenshot ist ja schon wieder ewig her, es wird wirklich bald Zeit für den neuen Release. Gerade ist leider wieder viel zu viel an nicht-essentiellen (d.h. nicht Hobbyspieleprogrammierung betreffend) Dingen zu tun, aber ich hoffe über den Sommer nochmal deutlich weiter zu kommen. Eigentlich "nur" noch polishing, aber gut, das sind wohl 80% der Arbeit. Andererseits fand ich das beim Hoppelhasen recht cool was wirklich fertiges abzuliefern, also mal schauen.

Dann bin ich mal gespannt auf die nächste Version. (-:

[Jonathan]

Ein paar kleine Updates:

Der Vorteil an einer längeren Pause ist, dass man danach wieder eine frische Perspektive auf das eigene Spiel hat. Mir ist beispielsweise aufgegangen, dass der Start eigentlich zu schwierig ist: Wenn man nicht als aller erstes ein Haus baut, belegt der erste Betrieb alle freien Arbeiter und man muss ihn erst wieder kurzfristig stilllegen, um andere Gebäude bauen zu können. Ist so eine Art Soft-Lock.
Also hab ich jetzt die minimale Anzahl an Einwohnern erhöht; man hat also immer ein paar Leutchen, auch wenn man keinerlei Bedürfnisse erfüllt. Mit denen waren aber die Startressourcen (Nahrung) dann zu schnell aufgebraucht, wenn man am Anfang zu langsam ist, die ersten Bauernhöfe zu bauen. Man hätte die einfach erhöhen können, aber ich habe es jetzt stattdessen dahingehend geändert, dass die ersten paar Bewohner einfach überhaupt keine Nahrung brauchen. Das hat den netten Effekt, dass am Anfang fast gar nichts passiert, sobald die Stadt dann aber leicht anfängt zu wachsen, geht es im normalen Tempo weiter. So wird auch sichergestellt, dass man frühzeitig Produktion aufbaut und sich nicht auf die Startvorräte verlässt, denn ansonsten würde es eine Weile später dann so richtig knallen.
Alternativ hätte man auch sagen können, dass man zu aller erst ein Haus bauen muss, erst danach wird alles weitere freigeschaltet. Und dann vielleicht ein Lager, bevor man Produzenten bauen kann. Aber das würde dann etwas richtig "die ideale Baureihenfolge wird vom Spiel vorgegeben und erzwungen" gehen, und das macht ein Aufbauspiel ja auch sehr langweilig.

Eigentlich wollte ich ursprünglich nicht die "gute, herausfordernde Spielbalance" aufweichen, wenn man am Anfang schon nur 5 Gebäude hat, wie dumm muss der Spieler dann schließlich sein, um das nicht hinzubekommen? Ja, naja, sehr schlechte Sichtweise. Und die aktuelle Lösung gefällt mir eigentlich sehr gut, der Ressourcenverbrauch ist eine lineare Funktion mit Offset, sprich am Anfang ist es 90% einfacher, kurz danach nur noch 50% einfacher und über die Zeit pendelt es sich dann schnell beim alten Schwierigkeitsgrad ein. Aber dann hat man schon ein kleines Dorf gebaut und schon verstanden, wie das Spiel funktioniert und daher ist das dann genau richtig so. Und das Nette daran ist, dass die Änderung an der Spiellogik minimal war :)

Vermutlich baue ich irgendwann noch einen zweiten Schwierigkeitsgrad ein, der viel vergebender ist und ein wenig Richtung Sandkastenmodus geht. Der dann vielleicht auch für Schönbauer geeignet ist. Ein dritter Schwierigkeitsgrad wäre auch cool, in dem das Spiel quasi zum Puzzle wird und wirklich nur dann schaffbar ist, wenn man die ideale Reihenfolge herausfindet und kontinuierlich nachjustiert. Halt für die Leute, die sowas mögen.

Als nächstes kommen aber erstmal Warnhinweise für Sachen, die in der Siedlung schief laufen, ähnlich dem "untätige Dorfbewohner"-Knopf in Age of Empires. Inklusive Zur-Position-Springen, wenn man drauf klickt. Ich denke, das dürfte vielen Einsteigern helfen.

Das nächste Spiel wird aber auf jeden Fall weniger komplex, eigentlich hab ich gar keine Lust so viel an der Benutzeroberfläche zumzudoktoren. Den Langvogt gut spielbar zu machen verschlingt einfach derartig viel Zeit, dass es langsam ein wenig nervt...

[Schrompf]

Spannend. Ne klare Kommunikation, woran es in der Siedlung scheitert, wird wahrscheinlich die schwierigste Aufgabe in dieser Art Spiel. Aber es geht vorwärts! Das freut mich.

[Jonathan]

Update:

(jajaja, die Straßen sehen kaputt aus, das kommt noch)

Ich hab einiges an Arbeit in die Marktkarren gesteckt. Angefangen hat es mit Rechtsverkehr, denn zuvor fuhren entgegenkommende Wagen einfach in der Mitte der Straße durcheinander hindurch, da es keine Kollision zwischen Karren gibt (erstens wäre das etwas aufwändig, zweitens bringt das aber auch die Spielbalance durcheinander: Wenn es auf einmal Staus gibt und die Siedlung vor die Hunde geht, weil Waren nicht ankommen. Man könnte Wegfindung ausbauen und das zu einem spannenden Spielelement machen, aber lassen wir das erstmal). Mit Rechtsverkehr fahren dann zumindest entgegenkommende Karren auf unterschiedlichen Seiten.

Bisher waren die Wagen ein starres Modell, d.h. es gab keine Drehachse zwischen Pferd und "Anhänger". Wenn sie nun am Rand der Straße fahren, sieht das eindeutig zu albern aus. Deswegen sind es jetzt zwei Modelle und es gibt einen Knickpunkt (sieht man links im Bild ganz gut). Und weil ich schon die Rotation für beide Teile getrennt ausrechnen musste, hab ich sie auch noch an die Geländehöhe angepasst, fahren Wagen jetzt über Hügel knicken sie entsprechend auch um die horizontale Achse und sind viel besser ausgerichtet, als zuvor.

Als kleines Gegenbeispiel, so sah es vorher aus (Pferd läuft immer geradeaus, auch wenn es dafür fliegen muss):

Und weil ich dann schon so viel Arbeit investiert habe, hab ich gleich noch individuelle Waren für die Karren eingebaut. So sieht man immer direkt, was jetzt da eigentlich transportiert wird, oder wo die dringend benötigten Steine bleiben. Früher gab es nur ein Standardmodell für generische Waren.

Insgesamt ist damit jetzt im Dorf einiges los und es wirkt schon viel lebendiger. Aufbauspiele leben ja auch vom Zuguckfaktor, ich bin mit dem Ergebnis also soweit sehr zufrieden. Auch wenn es im Detail noch zahlreiche kleine Glitches gibt, aber man muss ja nicht immer so weit reinzoomen. Hier nochmal als Video:

2024-06-24_17-24-45_Landvogt_small.mp4

(9.56 MiB) 81-mal heruntergeladen

Übrigens: In der GUI sind jetzt auch die Warnungen eingebaut: Rechts oben in der Leiste ploppen Icons auf, es gibt auch einen kleinen Warnsound und sie fangen an zu wackeln, um Aufmerksamkeit zu erzeugen. Es gibt Warnungen für stillgelegte Gebäude (die Warnung wackelt erst nach einer Minute, weil man sie ja aktiv still legt), nicht mehr erfüllte Bedürfnisse (sieht man im Video gut), nicht abgeholte Waren, fehlende Arbeiter und so weiter. Klickt man das Icon an, springt die Kamera zum entsprechenden Gebäude und man kann sich kümmern. Ist die Leiste komplett leer, läuft es rund in der Stadt :)

[Schrompf]

Wow, sehr cool. An Kreuzungen fahren sie noch durcheinander, aber ich fand das gar nicht so störend. Bei kleineren Trägereinheiten (Menschen z.B.) könnte man die einfach grafisch auseinander schieben, wo sie kollidieren, und wenn es langsam genug geht, sieht das aus, als ob sie aneinander vorbeigehen. Cool wäre noch, dass sie ins Scheunentor eines Hauses abbiegen, wenn sie irgendwo ankommen.

[Jonathan]

Aktuelle Baustelle: Bodentexturen. Dazu erstmal ein aktueller Screenshot:

Angefangen hat es damit, dass mir die Landschaft zu klein war. Kippt man die Kamera oder zoomt man weit raus, sieht man gähnende Leere. Im Landvogt 1.0 wurde das im Wesentlichen durch sehr restriktive Kamerabewegungen gelöst. Aber irgendwie mag ich den Aquarium-Effekt, man soll nicht nur bauen, sondern auch manchmal schauen, und auch wenn die Modelle nicht super detailliert sind, wieso nicht auchmal reinzoomen und die Kamera kippen? Meine Güte, ich will halt einfach Berge im Hintergrund :P

Das hätte man Brute-Force machen können, ich habe aber lieber erstmal Tessellation vernünftig eingebaut. Braucht man ja sicherlich auch nochmal. Näheres dazu hier: viewtopic.php?p=73739#p73739

Nachdem große Terrains jetzt gingen, mussten die natürlich auch irgendwie erstellt werden. Uff. Näheres dazu hier: viewtopic.php?t=5513

Als nächstes wollte ich wieder vernünftige Flüsse haben. Denn man hat, von Objekten abgesehen, im Wesentlichen bloß Boden, Berge und Flüsse, das sind die 3 zentralen Elemente, also braucht's jetzt wirklich wieder gutes Wasser. Wasser soll aber auch fließen, dafür braucht man Flow-Maps. Das bin ich vor Uhrzeiten mal angegangen, seit dem hab ich tatsächlich keine neuen nennenswerten Maps mehr erstellt. Näheres zum alten stand gibts hier: viewtopic.php?p=65720#p65720

Als kleines Update: Krita funktioniert top, das Video von damals war zwar für eine sehr alte Version, mit ein wenig suchen findet man aber ähnliche Features auch in der aktuellsten. Dann muss ich nur noch die Vorschau-Textur aus meinem neuen Terrain-Editor-Setup in Blender in den Hintergrund legen, einmal alle Flüsse per Maus abfahren, und die Flowmap exportieren. Dauert keine 5 Minuten, wenn man weiß nie. Hier das Ergebnis: (die R/G Werte kodieren einen 2D Richtungsvektor, quasi wie eine Normalmap, nur leicht anders):

Jetzt ist das Terrain also fertig und ich pflanze den ersten Wald. Es stellt sich heraus, dass es blöde aussieht, Objekte einfach so auf den Boden zu setzen. Viel besser sieht es aus, wenn es Materialspezifische Bodentexturen gibt. Schaut euch mal den Screenshot an, unter jedem Baum liegt Laub :) Und unter anderem Gebäuden (z.B. dem Marktplatz) passt sich der Boden auch an.

Implementiert ist das über eine zusätzliche Material-Map, RGB-Werte als Stärke für 3 verschiedene zusätzliche Materialien. Das Terrain besteht aktuell aus Gras, Feld, Lehm und Sand (am Flussufer). Zusätzlich gibt es jetzt für Gebäude noch Laub, Erde und Pflaster. Das zu Implementieren war das eine, jetzt muss aber noch für 20 Gebäude definiert werden, wie der Boden gesetzt werden soll. Und natürlich soll das nicht bloß immer ein runder Blob sein. Deshalb gibt es jetzt Gebäude-Landschafts-Brushes:

An der richtigen Größe und Stelle in die Materialtextur kopiert, kann man damit den Boden passgenau für jedes Gebäude anpassen. Doch jetzt kommt das nächste Problem: Wie erstellt man all diese Brushtexturen? Und wie stellt man sicher, dass sie immer zum Gebäude passen und die richtige Größe und Position haben?

Zeit für ein neues Blender-Setup:

Ich habe eine Boden-Ebene, 40m x 40m. Die ist groß genug, für so ziemlich alle Gebäude die es aktuell gibt. Jetzt importiere ich in die Datei sämtliche Gebäude-Modelle und benutze den Texture-Painter um für jedes Gebäude eine andere Textur zu malen. Anschließend kann man alle gemalten Texturen in einen Ordner exportieren und von dort ins Spiel kopieren. Diese Bodenebene liegt dabei genau im Ursprung und da die Gebäude im selben Koordinatensystem sind, wie sie später im Spiel geladen werden, braucht man als einzige zusätzliche Information die Ebenen-Größe (aktuell 40m, kann man aber pro Gebäude theoretisch beliebig anpassen). Wie man im Screenshot sieht, sind große Teile der Brush-Textur komplett leer. Der Brush wird aber bloß einmal beim setzen der Gebäude benutzt, und zusätzlich sind die Texturen alle recht klein )256 oder 512 Pixel, aktuell), hier zu optimieren wäre also Quatsch - man müsste dann ja pro Brush eine exakte Bounding-Box speichern, mehr Werte, mehr Komplexität, mehr Fehler (vermutlich).

Blender ist mittlerweile wirklich sehr vielfältig einsetzbar und die Jahre an Erfahrung lohnen sich da wirklich. Ohne Blender müsste ich entweder in meiner Engine einen Boden-Textur-Editor implementieren oder aber alle Gebäude aus der Vogelperspektive rendern und in ein 2D Programm wie Paint als Schablone laden. Oder per Trial&Error freihand zeichnen. Alles ziemlich blöde. Die Lösung in Blender ist was die Anzahl der Klicks angeht auch nicht ganz optimal, aber war innerhalb einer halben Stunde oder so aufgesetzt. Und solange ich nur ca. 20 dieser Maps malen muss und nicht 5000 lohnt sich der Zeitaufwand für einen eigenständigen Editor einfach nicht.

Es gibt noch einige andere Details, vielleicht kann ich das am nächsten Stammtisch mal detaillierter zeigen. Aber insgesamt läuft das System jetzt ganz gut, und so langsam bin ich mit der Optik happy. Nächste ganz wichtige Baustelle sind der sehr hässlichen Straßen und danach muss ich nochmal Gras und Steinchen rendern. Und dann neben Pferdekarren am besten auch noch echte Menschen einbauen. Eieiei.

[Jonathan]

Zum Thema größeres Terrain mit mehr Hintergrund hier nochmal zwei Bilder:

[Schrompf]

Sehr schick, ehrlich! Bissl Atmosphärendunst noch in die Entfernung, das sind 5min Shader-Arbeit, und fertig

[Jonathan]

Dankeschön :)

Sehr schick, ehrlich! Bissl Atmosphärendunst noch in die Entfernung, das sind 5min Shader-Arbeit, und fertig

Fake-News! Lüge! Ich hab gestoppt! :D Es hat 11 Minuten und 50 Sekunden gedauert!
Haha, ich hatte sowas tatsächlich schon im Zombiespiel eingebaut und hab mal Flugs den Shader rausgesucht und den Code-Schnipsel rüberkopiert. Ein bisschen debuggen weil Bezeichner kollidiert haben, dann nochmal 5 Minuten Schieberegler schieben bis ich mit den Parametern zufrieden bin. Das Resultat ist dann hier:

Und hier der Code:

Code: Alles auswählen

	// apply atmospheric desaturation:
	float gray = dot(scene_color, vec3(0.2126, 0.7152, 0.0722));
	float pixel_depth = length(v_fragment_position_in_world - u_CameraPositionInWorld);
	scene_color = mix(scene_color, vec3(0.6, 0.6, 0.8)*1.2*gray, pow(clamp((pixel_depth-500)/1000, 0, 1), 1));

Man nimmt also die aktuelle Farbe, ermittelt den Grau-Wert davon (das erste dot-Produkt, mit Betonung auf den Grün-Kanal - die Gewichte hab ich aus irgendeinem Artikel) und versetzt ihn einen leichten Farbstich (dritte Zeile, das Grau-Blau). Dann wird abhängig von der Entfernung zur Kamera eine Interpolation zwischen der Original-Farbe und der Grau-Farbe durchgeführt - gewichtet mit einer Potenzfunktion. Der Offset (-500) bestimmt, wie lange die Farbe unverändert bleibt, der zweite (/1000) wie schnell der Farbwechsel danach ist.

Zoomt man sehr weit heraus, wird der Effekt etwas extrem und sieht albern aus. Aber für normale Stadtansichten schafft er jetzt etwas mehr Tiefe.

[scheichs]

Also die Tech und Basis ist auf jeden Fall schon sehr gut. Ich bin allerdings auch noch am überlegen, was mir da noch ein wenig fehlt. Für meinen Geschmack, darf der Nebel noch etwas stärker sein und auch gerne auf der Skybox liegen. Eventuell kannst du ihn auch noch mit der Höhe skalieren.

[TomasRiker]

Nice. Man sieht die sich wiederholende Detailtextur allerdings recht deutlich. Und die Auflösung der Skybox sieht sehr niedrig aus.

[Jonathan]

Nice. Man sieht die sich wiederholende Detailtextur allerdings recht deutlich. Und die Auflösung der Skybox sieht sehr niedrig aus.

Joah. Allerdings muss man bedenken, dass der Spieler 98% der Zeit dieser Perspektive hier hat:



Da finde ich das Tiling nicht so sichtbar. Wirklich zufrieden bin ich mit den Texturen aber noch nicht, besonders wenn man sehr nahe reinzoomt, sieht das Gras irgendwie recht komisch grützig aus. Na gut, da soll ja später eh noch 3D Gras drüber kommen.

Ich bin gerade aber eh auch schon wieder an der nächsten Baustellen: Viel ist zuletzt umgebaut und kaputt gegangen, ich will es jetzt einmal wieder so zusammen stellen, dass man es von vorne bis hinten durchspielen kann, und dann erst weitere Details verbessern.

Ich kann mich letztendlich auch einfach nicht so lange an einzelnen Texturen etc. aufhalten. Gerade mal geschaut, der Data-Folder hat weit über 1000 Dateien, mit Modellen, Texturen, Sounds, GUI, Config-Dateien etc. kommt da echt unglaublich viel zusammen. Es gibt buchstäblich einhundert Texturen die ich eigentlich gerne verbessern würde, aber nichts davon macht das Spiel unspielbar und es muss ja auch irgendwann fertig werden, deshalb muss ich mich um die wichtigen Dinge kümmern. Alleine diese "blöden" Boden Brushes von denen ich oben geschrieben habe: Aktuell gibts es so um die 33 Gebäude (mal schauen ob alle reinkommen), ich hab bisher 7 davon gemalt, und viele davon auch eher grob. Da könnte man locker einen ganzen Tag Vollzeit rein investieren, um das alles wirklich gut zu machen. Aber eigentlich will ich auch noch einige Gebäude anpassen, und dann muss man natürlich auch die Brushes wieder neu machen, und und und...

[Schrompf]

Joa, das hört nie auf. Ich hätte die Boden-Brushes aus den Modellen gerechnet, einfach ne 2D-Distance-Funktion für ein Dreieck aufstellen und übern Mesh laufen lassen. Aber ich verstehe, dass man das auch scheuen kann.

Ich hab ein Problem mit Deiner Nebel-Funktion. Das Licht aufm Weg durch die Atmosphäre macht ja ganz schlicht betrachtet: von der orginalen Farbe geht immer mehr verloren, von Blau schon eher und von Rot erst später. Und gleichzeitig wird immer mehr generische Himmels-Helligkeit (das diffuse Graublau) in den Lichtweg reingestreut aufm Weg zur Kamera. Ich würde also den Grauwert aus der Formel komplett rauslassen, weil es mit immer mehr Strecke immer egaler wird, welche Farbe da ursprünglich losstrahlte.

Bonuspunkte dann, wenn Du Deinen Blendfaktor als float3 berechnest, mit kleineren Distanzen für Blau als für Rot. Das pow(..., 1) ist überflüssig, oder? In Echt wäre von der Ur-Farbe nach einer Strecke noch ein "pow(e, -strecke) übrig, übersetzt also "Alles bei Entfernung 0" bis "immer weniger, aber immer noch mehr als nüscht nach ganz viel Strecke".