LDRZ Fortschritt #8: Von allem etwas mehr :)

Diesmal habe ich mir mal ein paar Minuten genommen, um den Level ein wenig zu vergrößern, mit einer kleinen Galerie zu versehen und weitere Monster zu platzieren. Auch hat der Dungeon-Innenarchitekt zugeschlagen und überall schöne Fackeln aufgehängt. Doch seht selbst:

Warum ich hier dann bereits an erste Performancegrenzen gestoßen bin, und wie ich diese gelöst habe? Lest selbst…

Größerere und schönere Level

Hier gab es soweit eigentlich noch keine Probleme. Ein bisschen fummelig war die „Treppe“ vom ersten Stock ins Erdgeschoss runter. Hier sind anfangs sowohl Skelette als auch Spieler hängengeblieben. Allerdings ließ sich das auch recht schnell lösen. Man muss nur sehr genau aufpassen, dass die Collider in etwa stimmig sind.

Die Fackeln selbst waren auch kein Problem und machen das ganze schon erheblich Stimmungsvoller. Allerdings warfen sie dann doch ein Problem mit auf: Die Wände sind nicht nahtlos. Im Video mag das nicht unbedingt sichtbar sein, doch beim Spielen empfinde ich es als äußerst störend. Durch die Flackernden Lichter der Fackeln werden die Übergänge sehr hässlich und ungleichmäßig beleuchtet. Alles tüfteln in Wings3D half nicht. Die Wände müssten theoretisch exakt passen (exakte breite von 5), tun sie aber nicht.

Leider bin ich hier auch noch zu keiner Lösung gekommen. Ich finde es sehr angenehm, den Level in Unity selbst zu bauen (bis auf die Bodenplatten), außerdem muss ich mir dann um die ganzen Kollisionen keine Gedanken machen, da jedes Wandstück bereits den korrekten Collider hat. Einfach nach dem Baukastenprinzip die Wände aneinanderstecken, drehen, kopieren, … Alternativ werde ich jetzt dann am Wochenende mal versuchen die einzelnen Räume direkt in Wings3D/Blender zu bauen. Also zumindest Wände und Boden. Der Dekokram kommt dann wieder per Unity rein. Soweit klingt die Idee gut, wie löst man das dann aber mit der Kollision? Mesh-Collider wollte ich eigentlich für solche Dinge vermeiden…

Unity Pro

Nachdem ich gesehen habe, dass man Unity Pro auch „mieten“ kann (57€ / Monat), habe ich meine Basic-Version mal auf die 30-Tage Testversion der pro geupgraded. Mal schauen, welche Vorteile das so bringt, und ob es sich wirklich lohnen würde, die Pro zu kaufen. Problem ist nur, das alles was ich jetzt weiterbaue später mit der Basic nicht mehr geöffnet werden kann, wenn ich mich doch zunächst für die Basic-Variante entscheiden sollte.

Aber gut – die einzelnen Skripte usw. lassen sich ja trotzdem wieder zurück ins Basic überführen. Wie sind hier eure Erfahrungen? Reicht die Basic, wann sollte man sich die Pro kaufen? Kann man warten bis das Game „fast fertig“ ist, und dann mit der Pro die fehlenden Shader-Effekte, Lightmapping und Co kurz nachziehen und das Projekt veröffentlichen?

Gegnerbewegungen und Performanceeinbußen

In Unity-Pro hat man Zugriff auf einen Profiler. Das erscheint mir vielleicht sogar mit das wichtigste Feature… Im Build-Mode funktionierte der Level aus dem Video auch nach wie vor noch mit 60fps, im Debug-Mode bin ich teilweise auf ca. 25Fps gefallen. Dank Profiler war das Problem schnell gefunden: Die Wegfindung via A* ist relativ teuer (belegte 80% der CPU).

Die Lösung hier relativ simpel. Den Gegnern Restriktionen auferlegen wann und wie sie ihre Wegsuche durchführen. Zum einen berücksichtigen sie nun die Entfernung zum Spieler (wenn der Spieler 30 Meter weit weg ist kann der vorher berechnete Weg nicht sooo falsch sein / sich nicht so schnell ändern), zum anderen lassen sie sich erheblich mehr Zeit. Wie man im Video sieht fällt es fast nicht auf (auf der Treppe waren sie kurz ratlos), und ich habe bereits hierdurch wieder volle FPS.

Da ich ohnehin an der Gegnerbewegung dran war, ging es hier gleich weiter. Zu Beginn hatten die Skelette erhebliche Probleme mit der Treppe. Sie haben sich gegenseitig blockiert, und auch in anderen Situationen war das sehr nervig. Der gefundene Weg: Die Skelette verringern den Radius ihres CharacterControllers je weiter sie vom Spieler entfernt sind. Dadurch können die Skelette deutlich enger aneinanderstehen und haben bei Hindernissen nicht so die Probleme. Je näher sie dem Spieler kommen, desto größer wird der Radius und sie verteilen sich etwas mehr in die Breite. So wird der Spieler trotzdem schön umrundet und die Skelette stehen nicht ineinander, wenn sie gegen den Spieler kämpfen.

Zudem habe ich in der Seitwärtsbewegung den Schritt zurück entfernt, wenn die Skelette noch weiter weg sind vom Spieler. So können sie gleichzeitig leicht zur Seite gehen, während sie weiter auf den Spieler zustürmen. Sicher ist es noch ausbaufähig, aber das Ergebnis ist bereits jetzt recht zufriedenstellend, was meint ihr?

Die Galerie

Wie ihr im Video vielleicht bemerkt habt ist ein Skelett leider an der Galerie hängen geblieben. Ich bin mir noch nicht ganz sicher weshalb, ansonsten funktioniert es aber bereits ganz gut. Hier musste ich viel mit dem Path-Scanner herumspielen, da er die Skelette zu nah um die Ecken hat gehen lassen.

Ich hatte es zunächst mit „Thick Raycast“ probiert (was nicht funktionierte), ein zusätzliches Häkchen bei „Collision testing“ führte schließlich zum gewünschten Erfolg.  Hier meine aktuellen Einstellungen:

astar

Wie löst Ihr eigentlich solche Kollisionsgeschichten? Taugt euch das A* PathFinder-Projekt etwas, und welche Settings benutzt Ihr hier? Was mich leider noch etwas stört ist, dass man mit dem von mir benutzten Grid-Graph leider keine sich überkreuzenden Wege (in unterschiedlicher Y-Höhe) abbilden kann. Wenn man dann aber mal den Branchenprimus Diablo3 anschaut. Meines Wissens nach gibt es hier auch keine überlappenden Wege :). Von daher werde ich wohl damit Leben können (bzw. müssen).

Soweit für dieses mal :). Als nächstes steht eine grooooße Refactoring-Runde an. Die Skripte sind ja primär aus Versuchen heraus entstanden und gewachsen. Wenn ich so weiter mache wird das ganze irgendwann nicht mehr wartbar. Zudem will ich mal den Levelbau in Blender testen. Seid gespannt, wie das Ganze dann das nächste mal ausschaut :)!

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.