Schleichspiel

[Schrompf]

Hallo, ich bin Schrompf, und ich habe mich mal wieder verzettelt.

Es soll ein Schleichspiel werden: man kann im Gebusch (rostrote Flächen) geduckt schleichen und muss ansonsten aus dem Sichtfeld der Wachen bleiben. Im Level verteilt gibt es einen Zielgegenstand, den man an sich nehmen und wieder entkommen muss. Zusätzlich wird's wohl ein paar generische Wertgegenstände geben, die Zusatzpunkte geben. Man soll die Wachen auch meucheln dürfen und die Leichen verschwinden lassen.

Ob und wie weit ich damit komme, steht aber in den Sternen, denn ich habe mich mal wieder verzettelt. Ich wollte fix Level auf Boden-Poly-Basis bauen, aber ich hab der Konstruktion ein bissl zu viele Freiheiten erlaubt und jetzt ist das Levelbauen ne ganz schön mühsame komplexe Angelegenheit. Gameplay gibt's noch gar keins - rumlaufen krieg ich sicher noch hin, aber ob die Wachen jemals mehr als rumstehen können werden, bezweifle ich.

Wobei ich gerade ne Idee habe, wie ich das Ecken-Treffen mit der Maus einfacher gestalten könnte, so dass es mir nicht so oft die Levelgeometrie auseinanderreisst.

Aktueller Stand: ein halbes Level, kein Gameplay.

[joeydee]

Schonmal Glückwunsch zum Leveleditor :)

[grinseengel]

Das wird schon. Du hast ja noch ein paar Tage. Außerdem hast du ja den Rahmen zeitlich etwas flexibel gehalten. Auch nach der Action werden bestmmt alle an ihrem, ich gehe mal davon aus "unfertige Project", weiter arbeiten. Es zählt der Spaß an der Sache.

[Schrompf]

Danke! Und ja, ich mach wahrscheinlich weiter. Ich habe gerade mal wieder dieses eifrige Kribbeln, das hatte ich schon Jahre nicht mehr. Allein dafür war's das wert.

[Schrompf]

Needs more specular!

[Schrompf]

Specular funktioniert jetzt, auch wenn's nicht ganz der DeepRockGalactic-Look von LowPoly Mit Glanz ist, der mir vorschwab. Und es gibt jetzt Bewuchs, auch wenn die Verteilung auf sehr schmalen Bodendreiecken noch ein bissl ungleichmäßig / übern Rand hinaus verteilt. Egal. Ich find's sehr schick und fange jetzt ENDLICH mal mit dem Gameplay an.

Und ich verstehe noch ein bisschen mehr, warum Zudo so gern Milliarden Polys raushaut - es geht fix und ist echt hübsch. Ich hatte nur ein bissl Stress mit dem Aliasing und hab deswegen bissl weniger und dafür breitere Halme verteilt. Macht das Bild viel ruhiger. Für ne richtige Antialiasing-Lösung hab ich gerade keine Zeit.

[scheichs]

Sieht total kuschelig aus. Top!

[Schrompf]

Man sieht jetzt die Agentin, kann umschauen, rumlaufen und duckschleichen - die Agentin versinkt einfach nur ein Stück im Boden. Gleichzeitig habe ich für morgen noch familiäre Verpflichtungen gewonnen, ich kann also jetzt schon sagen, dass morgen nicht mehr viel dazukommen wird. Aber ich werde wohl noch ne Weile daran weiter machen - ich ziehe gerade echt einigen Spaß und Befriedigung daraus, ein Minimal Viable Product aufs Nächste zu stapeln

[mtorc1]

Kann mich scheichs nur anschließen. Bei den Screenshots kriegt man schon Lust aufs Probieren

[Schrompf]

Irgendwann muss man einsehen, dass man heute abend nicht mehr die Verfehlung der letzten Woche aufholt. Auf der positiven Seite: meine Tochter hat ihre Liebe für ihren Papa entdeckt und lässt sich bereitwillig mit Black Metal beschallen und vollnerden. Auf der negativen Seite: ich bin sehr viel weniger zum Coden gekommen, als ich vorher dachte, und hab mich dabei auch noch amtlich verzettelt.

Wollte heute z.B. fix die "Kreis mit Richtung vs. Dreieck"-Kollision ausm Wurmspiel kopieren, um das Movement zu implementieren, und habe dabei festgestellt, dass die Abstandsberechnung für flache Winkel Bullshit ist. Fuck ey. Hab jetzt was nur mit "Kreis vs. Dreieck" zusammengehäckt, das man fürchte ich leicht gamen kann, um sich durch Wände zu drücken, und hab nen neuen Eintrag auf der Wurmspiel-Aufgabenliste. Effizienz bei der Arbeit geht anders.

Wenn ihr es ok findet, werde ich die kommende Woche noch daran weiterbauen. Man kann sich jetzt über Hindernisse bis 1,25m Höhe hinwegschwingen, wenn man Space hält. Und der Editor ist etwas angenehmer auf bodenbasierte Polygone ausgerichtet und kann jetzt Objekte platzieren und rotieren - alles mit Undo.

[scheichs]

Haben die Deadline doch eh bewusst "schwammig" gehalten. Bin gespannt auf die spielbare Version!

[joeydee]

Dafür dass du eigentlich *gar* keine Zeit hattest, bist du weit gekommen, sehr cool!

[grinseengel]

Wenn ihr es ok findet, werde ich die kommende Woche noch daran weiterbauen.

Ich denke das passt bestimmt für Alle. Ich benötige auch noch etwas Zeit. Schönes Wetter, Familie, Hund etc. fordern alle ihre Beachtung.

[joeydee]

Ich denke das passt bestimmt für Alle.

Auf jeden Fall. Ich habe auch noch vor ein wenig weiterzumachen.

[Schrompf]

Ein herzliches Hallo meiner ProcGen-Wächtergruppe - 4x mit festem Seed, die sehen also immer gleich aus. Die Haarfarbe setzt sich noch nicht nennenswert von der Hautfarbe ab, und ich finde gerade keinen Seed, so dass einer der Männer auch mal nen Zopf hat, aber hey... für Wächter reicht's, und wenn ich das jemals ernsthaft aufziehen will, wird's sowieso ein fertiges Asset aus irgendnem Store.

Muss mir noch irgendne 80%-Lösung für die Laufwege der Wächter ausdenken. Ich hab eigentlich keinen Bock, hier ne Skriptlösung einzuziehen. Vielleicht reicht es ja, einen Strauß Wegpunkte mit Bedeutung "bis hier her, dann 10s stehen" einzuziehen und jedem Wächter eine Gruppe davon zuzuordnen. Mal gucken.

[edit]Achja, und es gibt jetzt Kisten - Missionsziel und Bonus, jeweils offen und zu, ebenso im Code erzeugt - die man öffnen kann, indem man rantritt, mit der Maus fokussiert, und dann <E> oder LinkeMT hält. Und man kann hinten aus dem Fenster raus auf so nen Felssims und weiter vorne wieder rein in den Schlafraum der Wachen. Irgendwo da gibt's aber Polys, wo man durch den Boden sackt - ich muss wohl nochmal einen sehr taktischen Breakpoint setzen und mal ausgeschlafen und nüchtern debuggen, was da faul ist.

[Schrompf]

Gibt jetzt einfache Posen für den aktuellen Zustand der NPCs. Aktuell gibt's nur diverse Idle-Tätigkeiten: stehen, sitzen, liegen, rauchen. Das reicht erstmal, um die Standardverhalten der NPCs zu implementieren, Als nächstes geht's jetzt mal an die Spielmechanik - dass NPCs die Spielerin sehen und übersehen können, und dass sie entsprechend in andere Erregungszustände wechseln. Da hängt dann schon wieder ein bissl was dran - Sichtbarkeitsprüfung, Wegesuche für's Verfolgen der Spielerin, Spielende bei Erreichen derselben. Bis zum Stammtisch nächste Woche werde ich in jeder Disziplin sicher was zusammengehackt kriegen

[Schrompf]

Letztens im Stammtisch schon gezeigt: es gibt jetzt ne grundlegende Spielmechanik: NPCs können einen entdecken und auch wieder verlieren, rennen zur letzten bekannten Position und von da aus ein bissl hin und her, und kehren dann irgendwann zum Tagesablauf zurück. Die Agentin wird im hohen Gras geduckt nicht gesehen, ansonsten aber schon, und je nach Aktivität auch gehört. Noch zu tun: nicht auf Teppichboden und auf Gras. Und wenn die NPCs noch nicht ausgescheucht sind, kann man sie auch durch 1s Halten der Maustaste meucheln. Die Leiche löst dann aber noch nix aus bei den anderen NPCs, das steht auch auf der Liste.

Oben im Bild außerdem ein paar Ideen von Joeydee ausm letzten Stammtisch, um die Szene besser lesbar zu machen: AmbientLight hat jetzt eine kleine Richtungsabhängigkeit, zusätzlich ne (unnötig dichte) Atmosphäre zur besseren Tiefeneinordnung, außerdem ne einfache Höhenskalierung des AmbientLights als Ersatz für SSAO und Freunde, und obendrauf ein ganz einfaches Dithering, weil ich hier und da mit dem Ein-Farb-Grafikstil doch zartes Banding hatte.

Außerdem schwingt jetzt das Gras im Wind und wird von Charakteren auseinander gedrückt. Da liegt ne R16G16-Offset-Textur drunter, in die ich große Sprites mit Windwogen reinrendere und kleine NormalMap-artige Cookies für jeden Charakter. Ich mach bei Gelegenheit mal ein Video davon.

[Schrompf]

Viel passiert hier, aber auch ne riesige Pause zwischendurch. Nuja. Gerade habe ich ein bissl Ambient Occlusion eingebaut. Ich mach das nur auf großer Skale, und zwar nach einer Idee aus einem AssassinsCreed-GDC-Video. Man rendert die Höhe der Landschaft aus der Vogelperspektive aus, blurt die, und kann jetzt anhand der Höhendifferenz der Oberfläche zu dieser Blurhöhe ablesen, wie weit man unter einem Dach ist, oder wie nah an einem hohen Hindernis. Das geht theoretisch in Echtzeit, aber es gibt nichts genügend Großes, das sich hier bewegt. Die Menschen sind zu klein, um einen Abdruck in der HeightMap zu hinterlassen.

Das Ergebnis ist schon ganz ok. Nur Ambient:

Nanu, ist das Dateianhängen kaputt? Ich krieg immer ein Popup "HTTP-Fehler", wenn ich hier Bilder anhängen will.



Mit voller Beleuchtung, Nebel, Specular und allem:

[grinseengel]

Schön das du auch noch deinem Projekt weitermachst. Dann sind es tatsächlich noch drei Projekte die aus der letzten Action stammen.

[Schrompf]

Pfadfindung! Ich hatte zuerst versucht, Recast/Detour zu integrieren, aber allein die WorldGen wollte bei mir nie... Also habe ich "fix" eine eigene Pfadsuche eingebaut.

- Höhen der Boden-Polys in ne Achtelmeter-Map ausrasterizen lassen
- Stufen darin erkennen
- Aus den Höhen-Unterschieden benachbarter Felder live ne NavMap bauen, wo Felder mit zu hoher Nachbarhöhe als "Wand" markiert werden
- Daraus ein Distance Field, wie weit jedes Feld zum nahesten Wandfeld liegt
- auf den Feldern mit dem nötigen Mindestabstand zur Wand nen plumpen A*

Ist aktuell sehr geradlinig implementiert, die Map-Erzeugung ist so im Bereich 10ms, die jeweilige NavMap für das Set aus MaxStufenhöhe und MaxFallhöhe auch so 10ms. Die Pfadsuche ist aber rechentechnisch eskaliert, wenn der A* einen Umweg finden musste. Da ging es dann schnell mal auf viele Sekunden und hundertausende Felder im "Visited"-Set. Das kommt davon, wenn man sich den Code von ner KI skizzieren lässt. Abhilfe brachte zum Einen, das VisitedSet als plumpes 2D-Array zu speichern anstatt als std::set. Außerdem habe ich das Set der nächsten Schritte nicht mehr sortiert, sondern wähle einfach das std::min_element(). Jetzt sind wir bei 5ms im extremsten Fall, den diese Map zu bieten hat. Das ist schon erstmal ok, aber ich weiß ja auch, was für nen Monster-Rechner ich habe. Später geh ich da nochmal ran.

[Jonathan]

Ah ja, das wollte ich mir auch immer mal angucken. Ich nehme an, es geht hierum?

https://github.com/recastnavigation/recastnavigation

Das sah immer gut aus, aber was mich auch immer abgeschreckt hat, ist, wie alt das doch ist. Schaut man sich die Versionsgeschichte an, sieht es etwas zwiegespalten aus, es gibt immerhin kleinere Commits mit Anpassungen, aber ich würde keine neuen Features oder modernere Versionen erwarten.

Gibt es eigentlich irgendetwas anderes, was grob in die Richtung geht? Hab da nie echte Alternativen zu gesehen...

@Schrompf: D.h. du hast quasi Dense-Grid und machst dann "brute-force" A*? Ich meine, das klingt solide und robust, aber auch nicht super elegant. Auf dem Bild kann man es schlecht erkennen, aber inwieweit funktioniert das gut mit schrägen Winkeln? Ich nehme an, du hast Tiles auch diagonal verbunden, aber dann hast du ja auch erstmal nur 45 Grad Winkel (scheint im Bild der Fall zu sein), wenn man aber z.B. im 30 Grad Winkel durch den Raum laufen würde, gäbe es dann Treppenstufen?

[Schrompf]

Weiß nicht genau, was die Wörter bedeuten, aber ich glaube schon: ein Ground Grid (weil's bei mir keine Stockwerke geben kann) und darauf A*. Das Ergebnis sind dann so Tippelschritte, die maximal 90° oder 45° führen können.

Es fehlt noch:
a) Pfadverkürzung, also unnötige Zwischenpunkte rausholen. Das würde auch die 45°-Beschränkung rausholen.
b) Feldgewichte, damit der nicht schräg übern Rasen latscht, wenn er auch den Weg daneben nehmen könnte.

Da wollte ich halt Weg/Beton/Teppich ein Gewicht 1 geben, Gras ne 2 und Versteckfeld ne 5, und dann latschen die hoffentlich im Normal-Betriebsmodus außen rum. Die Parametrisierung des Systems (mit MaxStufenhöhe und MaxFallhöhe) ist darauf ausgelegt, dass sie im Alltag sehr bequem laufen und Schwierigkeiten vermeiden, aber beim Jagen auch über Mauern hinwegsetzen und Dir ausm Fenster hinterher springen. Beim Jagen werde ich dann auch die Gewichte für Gras und Feld deutlich reduzieren.

Achja, und außerdem c) Objekte in die Map mit eintragen. Das ist das Schöne an dem DistanceField-System, dass ich dann die Felder rund um einen Baumstamm einfach auf Unmöglich setzen kann, und dann laufen die da auch drumrum.

[edit] Und ja, dieses Raycast/Detour. Alter ist ja egal, wird wohl auch solide eingesetzt. Die voxeln die ganze Map, bestimmen daraus auch die Lichte Höhe der Felder, und rekombinieren dann zu größeren Quads. Dabei kann das Ding auch kleine Lücken erkennen und überspringen. Ist solide Tech, angeblich, nur dass ich halt am allerersten Schritt gescheitert bin, nämlich dem Ausvoxeln meiner Map. Dafür, dass die Lib so alt und so viel verwendet ist, ist deren GettingStarted doch ganz schön armselig.

[scheichs]

Also ist schon ganz nice! Prinzipiell würde ich Dir Recast/Detour schon empfehlen, aber es ist vllt für deinen Anwendungsfall gar nicht nötig, weil die Level eh relativ klein sind und dann auch n Grid es tut.

[Schrompf]

Klingt, als hättest Du auch Erfahrungen damit gesammelt? Wie lief's bei Dir?

[scheichs]

Uff, das war 2010-2013 Konkurrenzprodukt von unserer Firma. Ich hab das selber nicht benutzt. Wir hatten 'ne typische AI-Middleware (u.a halt auch Navmesh-basierte Navigation + Movement darauf etc.) als Produkt für alle gängigen Plattformen und Recast/Detour war die OpenSource Alternative dazu.
Bei uns gab's dann z.B. auch einen Editor dazu in den du deine Levelgeometrie importieren konntest und damit Dein Navmesh bauen konntest, z.B. für richtig grosse Level, wo Du sowas nicht zur Laufzeit machen willst sondern mit dem Game auslieferst ... andere Zeiten.

Anyway, das war alles von der Funktionalität her recht ähnlich zu unserem Zeug, was auch recht gut IMHO war. Für größere Mengen an NPCs willst Du natürlich auch Avoidance und richtig schnelle Pfadsuchen haben und bitte auch robust ;)

Wir hatten natürlich auch gute Tutorials und Beispiele!

[Zudomon]

Ein spannendes Thema, mit welchem ich mich leider noch nie beschäftigt habe.

Wenn ich mir den Screen so ansehe und mir jetzt überlegen sollte, wie man da den Weg finden könnte, würde ich folgendes machen:

Alle Bodenpolygone nehme, auf denen man laufen kann. Schauen welche Kanten die sich teilen. Da es ja 2D sein soll, könnten man auch Kanten mergen, die sich in ihrer Y Ausrichtung ändern, natürlich nur in einem gewissen Bereich... so wie an der Rampe am Eingang. umgekehrt könntest du eventuell noch einfließen lassen, ob eine Kante z.B. dann nur einseitig nutzbar ist und da eine größere Y Toleranz beim mergen zulassen. An den Fenstern würde ich so einen Fall sehen... man kann zwar aus einem Fenster springen (sofern die Höhen nicht zu krass ist, aber nicht wieder durchs Fenster rein).
Wenn du also die Kanten kennst und alle Dreiecke hast, auf denen man laufen kann, würde ich trivialerweise immer die Mittelpunkte der Dreiecke nehmen... und dann Pfade zu den Nachbardreiecken aufbauen. Vielleicht kann dann noch eine Gewichtung mit rein... du wolltest ja, dass über den Rasen nicht gelaufen wird. Allerdings würde ich sagen, je nach Situation sollte man diese Regel außer Kraft setzen. Wenn da jemand nur sporadisch sucht oder sich umschaut, dann nicht über den Rasen. Wenn er dich aber sieht, dann drauf los stürmen, egal ob Rasen oder nicht.
Mit den Pfaden zwischen den Dreiecksmittelpunkten, der Gewichtung und der Pfadrichtungsnutzung sollte man doch jetzt bestimmen können, welcher Pfad am wahrscheinlichsten ist.

Vielleicht dann noch später als Optimierung die 3 Dreiecksvertices dazu nehmen, statt nur den Mittelpunkt. Aber hier soweit zum Mittelpunkt verschoben, dass das Körperausmaß mit beachtet wird. Dann würde der Gegner an der Wiese entlang gehen, ohne auf diese zu treten.
Vielleicht währen auch Edge-Mittelpunkte noch sinnvoll. Die Türen sind ja recht eng. Und die Edge-Mittelpunkte würden genau mittig durch die Tür führen.

Also ich würde da erstmal sowas versuchen, statt da über ein Grid zu gehen. Glaube so würdest du auch direkt die festen Winkel vermeiden.
Bei großen Dreiecken könntest du ja auch die Punkte noch etwas shaken, damit ein bisschen "Zufall" mit rein kommt.

[Jonathan]

Weiß nicht genau, was die Wörter bedeuten, aber ich glaube schon:

Haha, vieles war wohl teilweise aus anderen Themengebieten rüberportiert, ich weiß ja auch nicht, welchen Slang die coolen Path-Finding Kiddies von heute so schwätzen.

Klingt so, als hätten wir uns gut verstanden, aber vlt. noch ein paar Anmerkungen:

Mit "dense grid" meinte ich, dass wenn du einen großen, leeren Raum hast, du da alle 12 cm einen Nav-Punkt hast, was die Suche natürlich sehr teuer macht. Im Extremfall bräuchtest du jedoch nur einen an jedem Eingang, weil im "großen leeren Raum" ja jeder andere Punkt dann auf direkter Linie zugänglich wäre. Wenn es jetzt funktioniert ist ja erstmal alles gut, bloß sind die 5 ms pro Suche (so hab ich das jetzt verstanden) auch schon ein wenig an der Schmerzgrenze. Für 50 FPS wären das ja 4 Suchen pro Frame, und dann hat man noch 0 ms fürs Rendering und alles andere übrig. Klar, man könnte eine Warteschlange (oder extra Thread) benutzen, und nur eine Suche pro Frame erlauben, die Figürchen würden dann die ersten paar Frames erstmal in Himmelsrichtung loslaufen und dann den richtigen Pfad einschlagen (merkt man vermutlich quasi gar nicht) und so weiter. Aber vielleicht will man halt doch die Suche was schneller machen.

Ich erinnere mich jedenfalls noch an die seligen Counter-Strike zeiten, wo ich mir zum Offline-Spielen PODBot installiert habe und dann händisch auf Maps Navpunkte verteilen musste, damit die Bots damit funktionieren. Für populäre Maps gabs fertige Dateien, aber für neue Maps die ich damals gerne ausprobiert habe, musste ich mir meine Bot-Mitspieler immer erst "erarbeiten". Hach waren das Zeiten :)

Das sah dann ungefähr so aus:
https://www.youtube.com/watch?v=7MHKdEUhWmQ
https://www.youtube.com/watch?v=uTCujp0r4ek

[Schrompf]

Jonathan! Das ist nicht mehr das Jahr 2002! :-) Ich habe 32 Cores und C++17 std::future, und ein inzwischen ziemlich stabiles Concurrent Job-System, das alles von Boost losgeworden ist außer den beiden ASM-Files, die den StackSwitch machen. 5ms sind schnell genug. Außer dass ich beim DungeonSpiel halt gelernt habe, dass es noch Leute mit älterer Hardware gibt, mit weniger Kernen und langsameren Kernen, und für die muss ich da später nochmal ran.

[edit] Das ist freundlich gemeint, nicht herablassend! Nur zur Sicherheit.

[joeydee]

Ich habe jetzt die meisten Kommentare nur grob überflogen, vielleicht wiederholt sich das, aber Grid drauflegen ist bischen ... hm, von hinten durch die Brust ins Auge, mit Hilfe von gekochtem Wasser, das man sich auf Vorrat einfriert ;)
Ich glaube, du denkst komplizierter, als es sein muss.

Für A* (und andere) sind generell ja lediglich die Infos "Nachbarkpnoten" und "Verbindungskosten" interessant, da gibts sonst keine Restriktionen. Die Knoten müssen also nicht in einem Grid liegen (auch wenn praktisch jedes Tutorial davon ausgeht), und es können auch mehr oder weniger als 4 Nachbarn sein. Das kann also ein beliebiger Graph sein.

Für 2D-Obstacles (damals für die Lauffläche eines Adventures) hatte ich mal einen Graphen folgendermaßen aufgebaut:
- Alle konkaven Ecken im Laufflächen-Polygon finden (also nach innen gerichtete Ecken, von der Lauffläche aus gesehen sind die konvex), typischerweise um einen Radius nach innen versetzt.
- Jeden dieser Punkte auf direkte Sichtlinien (=Lauflinien)* zu anderen prüfen, sichtbare als Nachbarn listen, und die Entfernung als Kosten (plus evtl. Mehrkosten durch Umgebung wie Gras, Stufen etc.)
* "sichtbar" und "erreichbar" verwende ich hier synonym.
Als Algo zum Aufbau hatte ich damals glaube ich Brute Force: Jeder Punkt prüft stur Verbindungen zu allen anderen auf Outline-Schnitt (Aufwand n*(n-1)/2 hielt sich trotzdem in Grenzen). Aber im Showroom hatte ich mal einen Algo zur Triangulation, der reihum und rekursiv immer den nächsten sichtbaren Konkav-Punkt sucht und quasi alles in konvexe Bereiche unterteilt, denke sowas würde ich heute nehmen.

Für eine Abfrage:
- Figuren-Pos und Ziel-Pos temporär zum Graphen hinzufügen, d.h. schauen welche Knoten aktuell sichtbar sind, und entsprechend neue Lauflinien sowie den Knoten hinzufügen. (Im Fall eines besseren Grid-Erstellungs-Algos: schauen, in welchem Konvex-Teil man ist, und dessen gefundene Konkav-Knoten als Nachbarn nehmen)
- A* oder Dijkstra o.ä. drüberjagen.

[Jonathan]

Jonathan! Das ist nicht mehr das Jahr 2002! :-) Ich habe 32 Cores und C++17 std::future, und ein inzwischen ziemlich stabiles Concurrent Job-System, das alles von Boost losgeworden ist außer den beiden ASM-Files, die den StackSwitch machen. 5ms sind schnell genug.

Ah, ok, na dann: Nice.

Vielleicht sollte ich sowas ähnlich auch einbauen, ich benutze tatsächlich aktuell genau 2 Threads - und der zweite ist nur optional zum Texturen laden. Wenn ich im Landvogt Straßen baue, kann das Spiel schonmal für 0.3 s stocken, weil ein globales Straßenmesh neu generiert wird. Das könnte man sicherlich auch schneller hinkriegen - andererseits ist es IMO für den Nutzer angenehmer, wenn ein kurzer Hänger durch eine Nutzerinteraktion ausgelöst wird und nicht durch einen Hintergrundprozess. Aber die Straße könnte halt auch erst mit kurzer Verzögerung erscheinen, ist ja kein Ballerspiel hier...