Im Mai wurde der eigene LOD Creator als Teil der World- und Optimization-Tools weiter in den Produktionsablauf von Dark Continent eingebunden. Gezeigt wird hier bewusst nur eine einfache Low-Variante des Tools, nicht die vollständige interne Arbeitsversion.

Der sichtbare Schwerpunkt liegt auf dem Grundprinzip: Aus einem vorhandenen Mesh wird eine leichtere Variante erzeugt, die später für Distanzdarstellung, Performance-Tests oder vorbereitete LOD-Setups genutzt werden kann. Gerade bei größeren Szenen ist dieser Schritt wichtig, weil nicht jedes Modell dauerhaft mit voller Detailstufe gerendert werden sollte.

Für Dark Continent betrifft das vor allem Vegetation, Felsen, Ruinen, Props und größere Asset-Sets. Einzelne Objekte wirken für sich genommen oft unproblematisch, aber in einer großen Szene summieren sich Tris, Vertices, Schatten, Materialien und Renderer sehr schnell. Ein sauberer LOD-Workflow hilft dabei, diese Kosten kontrollierbarer zu machen.

Die hier gezeigte Variante ist deshalb bewusst klein gehalten. Sie soll nicht die komplette Tool-Komplexität zeigen, sondern den praktischen Nutzen: Modelle schneller vorbereiten, technische Last reduzieren und trotzdem genug visuelle Qualität erhalten, damit die Szene nicht kaputtoptimiert wirkt.

Für größere Unity-Projekte ist ein LOD-System kein optionaler Luxus, sondern ein grundlegender Teil der technischen Basis. Ohne LODs bleiben zu viele Details aktiv, auch wenn sie aus Spielersicht längst keine Rolle mehr spielen.

Der LOD Creator ist damit ein weiterer Baustein, um Dark Continent Schritt für Schritt stabiler, größer und besser skalierbar zu machen. Der Fokus liegt hier nicht auf einem einzelnen Screenshot oder einer kompletten Tool-Demonstration, sondern auf dem Aufbau einer sauberen technischen Pipeline für größere Spielbereiche.

In diesem Schritt lag der Fokus darauf, größere Weltbereiche technisch sauber vorzubereiten und gleichzeitig zu prüfen, wie sich Sichtbarkeit und Performance im aktuellen Aufbau verhalten. Dark Continent bewegt sich aktuell immer stärker in Richtung Spielwelt, Arealstruktur und direktes Spielgefühl. Deshalb werden technische Tests inzwischen nicht mehr nur isoliert betrachtet, sondern immer stärker im Zusammenhang mit der eigentlichen Umgebung.

Die gezeigten Bereiche wurden im Unity-Editor analysiert und für Occlusion-Tests vorbereitet. Dabei geht es nicht darum, einfach möglichst viele Dinge auszublenden, sondern darum, die Welt so aufzubauen, dass größere Areale später kontrollierbar bleiben. Sichtbarkeit, Renderlast, Kamerawege und die Struktur der Umgebung müssen zusammen funktionieren, damit die Spielwelt weiter wachsen kann.

Der Runtime-Test zeigt einen positiven Zwischenstand innerhalb der laufenden Optimierungsphase. Einzelne Elemente der Szene waren während der Tests bewusst deaktiviert, weil es hier zuerst um die technische Validierung ging. Der gezeigte Screenshot wurde in einer breiten Testauflösung aufgenommen und ist deshalb nicht als finaler 4K-Benchmark zu verstehen. Separate Tests in höheren Auflösungen zeigen aber bereits, dass die aktuelle Richtung auch dort stabil bleibt.

Der Tech Log könnte inzwischen deutlich mehr zeigen, als hier tatsächlich veröffentlicht wird. Es entstehen viele interne Werkzeuge, Prüfungen und technische Zwischenschritte, aber nicht alles davon gehört direkt nach außen. Einige Dinge sind zu spezifisch für die eigene Pipeline, andere würden zu viel über den Aufbau hinter dem Projekt verraten. Deshalb werden hier bewusst nur ausgewählte Einblicke gezeigt, die den Fortschritt nachvollziehbar machen, ohne die komplette Arbeitsweise offenzulegen.

Für die nächste Phase geht es weniger darum, einzelne technische Tests für sich allein zu präsentieren. Der Fokus liegt darauf, die Spielwelt weiter ins eigentliche Spiel zu bringen. Umgebung, Performance, Areale und Spielerführung sollen gemeinsam wachsen. Genau deshalb werden solche Grundlagen früh geprüft, damit spätere Inhalte nicht auf einem unsauberen Fundament aufgebaut werden.

Ziel ist es, das Maximum aus der Engine herauszuholen, ohne den Spielfluss aus den Augen zu verlieren. Technische Arbeit, World Building und Gameplay-Gefühl gehören hier zusammen. Der aktuelle Stand ist deshalb kein finaler Benchmark, sondern ein weiterer sauberer Schritt auf dem Weg zu größeren, stabileren und besser spielbaren Bereichen.

Das hier zeigt nur einen kleinen technischen Ausschnitt aus der laufenden Arbeit im April. Für sich genommen war das kein großer Entwicklungsblock, sondern eher ein kompakter Zwischenschritt. Gerade solche kleinen Teile finde ich trotzdem interessant für den Tech Log, weil sie sichtbar machen, wie die eigentliche Systemarbeit im Hintergrund entsteht.

Im gezeigten Video geht es vor allem um die Arbeit direkt im Unity-Editor, also um Struktur, Kontrolle und das saubere Zusammenspiel einzelner Komponenten. Zu sehen ist kein fertiges Feature im klassischen Sinne, sondern eher ein technischer Blick auf einen kleinen Teil des Setups, der später mit dafür sorgt, dass größere Abläufe überhaupt stabil funktionieren können.

Solche Schritte wirken von außen oft unscheinbar, gehören aber zum eigentlichen Fundament der Entwicklung. Ein System entsteht nicht nur aus den sichtbaren Ergebnissen im Spiel, sondern auch aus vielen kleinen Prüfungen, Anpassungen und Zwischenständen im Hintergrund. Genau dort entscheidet sich oft, ob etwas später sauber erweiterbar bleibt oder an zu vielen Stellen wieder auseinanderläuft.

Gerade deshalb finde ich es sinnvoll, auch solche kleineren Abschnitte gelegentlich zu zeigen. Nicht, weil dieser Teil für sich genommen besonders spektakulär wäre, sondern weil er einen ehrlichen Einblick in die tatsächliche Arbeit hinter dem Projekt gibt. Wer selbst entwickelt oder sich für technische Abläufe interessiert, kann daran oft besser nachvollziehen, wie solche Strukturen im Alltag wirklich aufgebaut und geprüft werden.

Der gezeigte Ausschnitt steht also bewusst nicht für ein komplettes System, sondern nur für einen kleinen technischen Teilbereich innerhalb der laufenden Arbeit. Genau solche Zwischenstände gehören für mich aber ebenfalls in den Tech Log, weil sie zeigen, dass Entwicklung nicht nur aus großen Features besteht, sondern auch aus vielen kleinen, kontrollierten Schritten, die später das eigentliche Ganze tragen.

Ein aktueller Teil der Combat-Arbeit betrifft die technische Prüfung der Treffererkennung am Gegner. Dabei geht es nicht nur um einfache Kollisionen, sondern um klar definierte Trefferzonen, die später eine saubere und nachvollziehbare Auswertung einzelner Treffer ermöglichen sollen.

Die gezeigten Screenshots zeigen einen kleinen Ausschnitt dieses Zwischenstands. Sichtbar sind der grundlegende Aufbau der Hit-Zonen am Charakter, die Kontrolle der zugehörigen Objekte im Unity-Setup und ein laufender Test mit Debug-Ausgabe zur Validierung der getroffenen Regionen. Auf diese Weise lässt sich früh prüfen, ob die Zuordnung der Trefferbereiche stabil funktioniert und ob die Rückmeldungen im System sauber ankommen.

Gerade in einem kampforientierten Projekt ist dieser Schritt wichtiger, als es auf den ersten Blick wirkt. Treffer sollen nicht nur optisch stattfinden, sondern intern präzise erkannt, einer Region zugeordnet und für die weitere Combat-Logik verlässlich ausgewertet werden können. Genau dort entsteht später die Grundlage für nachvollziehbares Hit-Feedback und stabile Reaktionen im laufenden Kampf.

Ein Teil der Arbeit liegt deshalb nicht nur im eigentlichen Code, sondern auch in der Sichtbarkeit des Systems während des Tests. Durch die Kombination aus Szenenansicht, Objektstruktur, Inspector-Kontrolle und Debug-Ausgabe lässt sich deutlich besser prüfen, ob Treffer dort ankommen, wo sie erwartet werden, und ob die internen Zuordnungen mit dem visuellen Setup übereinstimmen.

Solche Validierungsschritte wirken im Vergleich zu offensichtlichen Gameplay-Features oft unscheinbar, gehören aber zu den technischen Grundlagen eines belastbaren Combat-Systems. Gerade weil spätere Zustandswechsel, Reaktionen und Schadenslogik auf dieser Erkennung aufbauen, muss die Struktur an dieser Stelle sauber und kontrollierbar bleiben.

Gezeigt wird hier bewusst nur ein begrenzter Teil des aktuellen Setups. Der Fokus liegt an dieser Stelle auf der strukturellen Prüfung und technischen Absicherung der Hit-Detection, nicht auf der vollständigen Offenlegung des gesamten Systems.

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.