In den letzten zwei Tagen lag der Fokus auf einem Bereich des Enemy-Combat-Systems, der nach außen kleiner wirkt, intern aber mehrere Zustände gleichzeitig berührt hat. Der Run-Attack-Flow musste sauber vom normalen Approach, vom Armed-State und von den restlichen Combat-Übergängen getrennt werden, damit der Gegner in diesen Abläufen kontrollierter und glaubwürdiger reagiert.

Rein auf den Code reduziert war das kein kompletter Neuaufbau, sondern eher eine gezielte Erweiterung und Umstrukturierung im Bereich von einigen hundert Zeilen. Genau solche Abschnitte kosten in der Praxis aber oft mehr Zeit, als der reine Umfang zunächst vermuten lässt, weil nicht die Zeilenzahl entscheidet, sondern das präzise Zusammenspiel von Distanzen, Cooldowns, Prioritäten, Commit-Punkten und Übergängen. Gerade im Combat merkt man schnell, wie stark schon kleine Überschneidungen das Spielgefühl verändern können.

Eine einfachere Lösung wäre an dieser Stelle durchaus möglich gewesen. Die Run-Attack hätte sich deutlich grober anbinden, billiger auslösen oder im Zweifel auch ganz aus dem Ablauf herausnehmen lassen. Genau das war hier aber nicht das Ziel. Statt eine schnelle Abkürzung zu nehmen, wurde das Verhalten so lange angepasst, bis es sich sauber in den bestehenden Combat-Flow einfügt und nicht nur irgendwie funktioniert.

Der eigentliche Aufwand lag deshalb weniger im bloßen Schreiben des Codes und stärker im Testen, Vergleichen und Abstimmen der Zustände. Run-Phase, normaler Approach, Armed-State, Commit-Distanz, Rückfall auf regulären Nahkampf und die Rückkehr in den normalen Combat-Flow mussten so zusammenspielen, dass der Gegner nicht zu früh auslöst, nicht unruhig nach vorne snappt und nicht zwischen mehreren Absichten gleichzeitig schwankt.

Ein wichtiger Teil der Arbeit war deshalb auch die technische Sichtbarkeit des Verhaltens. Relevante Zustände wurden zusätzlich im Inspector und über Debug-Logs kontrollierbar gemacht, damit die Abstimmung nicht nur nach Gefühl erfolgt. Dadurch ließ sich deutlich besser nachvollziehen, wann die Run-Phase wirklich aktiv ist, wann ein Angriff vorbereitet werden darf und an welchem Punkt der Commit tatsächlich greifen soll.

Parallel dazu wurde auch der Animator-Flow klarer getrennt. Run, Run-Attack und die Rückkehr in den regulären Combat-State mussten strukturell sauberer voneinander abgegrenzt werden, damit die Logik nicht an mehreren Stellen gleichzeitig gegeneinander arbeitet. Genau diese Trennung macht das Verhalten nicht nur stabiler, sondern schafft auch eine bessere Grundlage für spätere Erweiterungen im Combat-System.

Der Run-Attack-Fix war damit kein billiger Schnellschuss, sondern eine bewusste Feinarbeit an einem empfindlichen Teil des Combat-Systems. Der reine Codeumfang blieb überschaubar, die eigentliche Arbeit lag aber in der sauberen Abstimmung der Parameter, im wiederholten Testen und in der Entscheidung, nicht den einfachen Weg zu nehmen, sondern das Verhalten so fein anzupassen, bis es am Ende wirklich stimmig ins Combat-System passt.

Bereits Ende Februar wurde Dark Continent auch auf technischer Seite an einer wichtigen Stelle weiter saubergezogen. In diesem Schritt erfolgte der Wechsel auf Unity 6.3, um das Projekt frühzeitig auf eine stabilere Editor-Version zu setzen.

Hintergrund dafür war nicht ein großer Zusammenbruch des Projekts, sondern eher die Erfahrung, dass sich kleinere Fehler und wiederkehrende Editor-Probleme mit der Zeit summieren können. Gerade bei einem Projekt, das inzwischen deutlich größer geworden ist und bereits mit umfangreicheren Arealen, Terrain und mehreren verknüpften Systemen arbeitet, ist es langfristig sinnvoller, solche technischen Punkte früh abzufangen.

Der eigentliche Versionswechsel verlief dabei erfreulich ruhig. Im Kern gab es nur einen echten Error, der auf ein Serializable-Feld zurückzuführen war und nach dem Entfernen direkt behoben werden konnte. Alles Weitere ließ sich schnell manuell korrigieren, ohne dass größere Systeme umgebaut werden mussten.

Auch wenn solche Schritte nach außen oft unspektakulärer wirken als neue Features, gehören sie bei einem größeren Unity-Projekt fest zum Entwicklungsprozess dazu. Nicht jeder Fortschritt zeigt sich sofort in neuen Bildern, Gegnern oder Gameplay-Systemen. Manchmal besteht der wichtigere Teil darin, die technische Grundlage rechtzeitig sauber und belastbar zu halten.

Der Wechsel auf Unity 6.3 war damit kein großes Problemfeld, sondern ein sinnvoller technischer Zwischenschritt, der die Basis des Projekts stabilisiert hat, bevor spätere Systeme weiter ausgebaut wurden.

In vielen Jahren mit dem Unity-Editor habe ich schon einiges gesehen. Kuriose Animator-Zustände im Play-Mode gehören irgendwie dazu. Aber dieser hier war neu.

Es gibt diesen Moment im Development, wenn du der KI dein Movement- und Combat-System erklärst, ihr den Animator gibst, deine Parameter, deine States, kurz gesagt den heiligen Gral deines Setups, und hoffst, dass danach noch irgendetwas funktioniert.

Du erwartest kleine Verbesserungen. Vielleicht sauberere Transitions. Ein bisschen Struktur. Nichts Dramatisches. Nur ein kleines Upgrade.

In der Praxis kann es danach passieren, dass der Charakter plötzlich Äxte im Kreis schwingt, in einem Tempo, bei dem selbst die Animations-Preview nicht mehr hinterherkommt, während mehrere States gleichzeitig überzeugt sind, sie hätten gerade Priorität. Kurzzeitig entstand dabei sogar eine eigene Kampfform, intern liebevoll Axt-Wirbelwind genannt.

Und du sitzt davor, schaust dir das an, scrollst kurz durch den Animator und denkst dir langsam:

„Ah… ok.
Jetzt verstehe ich, wie manche dieser Systeme in anderen Spielen entstehen.
Nicht aus Design.
Sondern aus genau diesem Moment,
in dem jemand kurz mit den Schultern zuckt und sagt:
‚Ja… passt schon. Ship it.‘“

Der Fehler ist inzwischen behoben. Am Ende lag es nicht am System selbst, sondern daran, dass entscheidende Parameter in der Beschreibung gefehlt haben. Ein paar Zustände, die für mich selbstverständlich waren, wurden schlicht nicht berücksichtigt. Was für einen Menschen sofort klar gewesen wäre, hat in der Anweisung gefehlt und genau dort wird Unterstützung schnell nutzlos.

Aber genau solche Momente gehören dazu, wenn man ein Combat-System nicht nur zusammenklickt, sondern wirklich selbst aufbaut und manchmal auch versucht, sich dabei helfen zu lassen.

Aktuell verschiebt sich der Schwerpunkt stärker auf Systemarbeit, die im Spiel selbst nicht immer sofort sichtbar ist. Ein Teil davon ist die Vorbereitung auf spielbare Kampfsituationen. Bevor ich dort weitergehe, habe ich zuerst einen Workflow-Engpass gelöst, der mich bei größeren Asset-Packs sonst regelmäßig ausbremst.

Dafür ist ein Texturing Tool entstanden, in C# geschrieben und technisch in zwei Skripten umgesetzt, aber als ein zusammenhängender Ablauf gedacht. Es erstellt automatisch Materialien aus einem Texture Set und weist diese danach den richtigen Meshes und Renderern zu. Selbst 65 Texturen sind manuell keine Sache von drei Minuten. Wenn man es sauber macht, liegt man schnell bei 45 bis 90 Minuten. Mit dem Tool läuft das als Batch in wenigen Minuten durch.

Am Tool selbst habe ich rund zwei Stunden gearbeitet, vor allem für Fehlerfixes, Logik und eine robuste Zuordnung. Ziel war, dass der Ablauf auch bei größeren Asset-Mengen stabil bleibt, ohne dass wiederholende Aufgaben zur Zeitfalle werden.

In den letzten zwei Wochen lag der Fokus darauf, das Kampfsystem sauber mit dem bestehenden Movement und dem Animator zu verbinden. Genau hier entstehen die typischen Problemzonen: kleine Input Schwankungen sorgen für falsche Zustände, Animationen springen zu früh, und einzelne Mechaniken blockieren sich gegenseitig.

Ein großer Teil der Arbeit bestand deshalb nicht aus neuen Features, sondern aus Stabilität. Prioritäten mussten klar definiert, Übergänge kontrolliert und Randfälle abgefangen werden, damit der Spieler nicht in ungünstige State Kombinationen fällt.

In dieser Phase zeigen sich Probleme oft nicht als klassischer Bug, sondern als falsches Timing, unruhige Übergänge oder ein Combat Flow, der sich nicht sauber anfühlt. Genau deshalb ist eine klare Major Bugliste wichtig. Jeder, der selbst schon Animationen und State Machines integriert hat, kennt diese Stellen und kann anhand der Fixes nachvollziehen, was genau stabilisiert wurde.

Das Movement sitzt aktuell sehr stabil und fühlt sich insgesamt sehr gut an. Genau deshalb konnte der Combat Teil bewusst so getuned werden, dass Eingaben nicht einfach "durchgerattert" werden. Beim Schlagen existiert ein klares Zeitfenster für den Folgetreffer. Wer zu hektisch drückt, löst keinen zweiten Schlag aus, und wer zu langsam ist, verpasst das Fenster ebenfalls.

Der aktuell größere Abstand zwischen Attack 1 und Attack 2 ist dabei kein Versehen, sondern eine bewusste Entscheidung. Das System soll Rhythmus, Commitment und Lesbarkeit erzwingen, statt reines Button Spamming zu belohnen. Dieses Timing dient als Basis, bevor echte Gegner, Lock On und spielbare Kampfsituationen den nächsten Belastungstest liefern.