ZFX + Developia

Richtig schön fleischig! Sieht toll aus und passt gut genug zu deinen eigenen Assets.

Mit etwas Color-Cycling könntest du vielleicht noch interessante Varianten davon erzeugen. Ein grüner, schleimiger Golem?

Der neue Boss gefällt mir optisch richtig gut, jetzt muss ich nur noch schauen, wie ich bei künftigen Bossen grafisch auf dasselbe Niveau komme. Aber: Challenge accepted!

Die Hexe, jetzt als Support

Die alte Hexe wurde zur Support-Einheit umfunktioniert, weil es inzwischen einen Zauberer gibt, der ihre frühere Rolle übernommen hat.
Sie kann jetzt eine Schutzbarriere auf Einheiten anwenden (armor +1) – damit verlängert sie effektiv deren Überlebenszeit.


Gegner-Spawning: jetzt planbarer

Gegner werden nun am Ende jeder Runde gespawnt. Das gibt dem Spieler Zeit zum Planen und Positionieren der Einheiten. Zuvor war das Spawning zufällig verteilt, was einfach zu chaotisch war. Ich will eine Gegnerwelle gegen die man planen kann.


Das Katapultproblem

Das Katapult hat mir einiges an Kopfzerbrechen bereitet. Ich wollte, dass es auch Verbündete treffen kann (friendly fire), aber das machte es fast unbenutzbar. Ohne friendly fire wirkte es wiederum unrealistisch und zu stark.
Mein aktueller Lösungsansatz:
Das Katapult deckt nur einen festlegbaren 90°-Bereich ab – den muss der Spieler manuell setzen. So kann man gezielt eigene Gebäude oder Einheiten ausschliessen, zumindest theoretisch.

Gefällt mir, wie Du da spielmechanisch rangehst!

Ich mag auch irgendwie, wie die Kreise auf die einzelnen Tiles gemappt werden. Das sollte ich mir vermutlich abgucken, es gibt beim Landvogt ja auch viele Gebäude mit Einzugsradius, bloß wird der halt als Kreis dargestellt und dann ist es im Zweifelsfalle nicht ganz klar, ob ein anderes Gebäude noch innerhalb oder außerhalb des Radius ist...

Danke Schrompf :), ich gebe mir Mühe was neues zu erschaffen und nicht immer den einfachsten Weg zu gehen.

Jonathan: Ja die Klarheit wo sich eine Selektion auf dem Terrain befindet war mir wichtig, wenn du was abschauen kannst, nur zu :). Ich habe auch mit normalen Kreisen begonnen, aber das hat zu sehr viel Verwirrung geführt.

Neue Version ist online!
Wie immer war es komplizierter als gedacht… Diverse Pfade waren noch nicht relativ gesetzt, und trotzdem blieben die Fehlermeldungen aus. Dann kamen noch ein paar kleine Korrekturen dazu – und schwupps, 10 Builds später war’s endlich soweit.


Trotz vorhandenem Tutorial bleibt noch einiges versteckt:
Viele Gebäude bieten Upgrades, manche sind selbsterklärend, andere eher… Texte sind nicht lokalisiert und noch Devtexte.

Die Kakapostatue bietet einige göttliche Fähigkeiten, die sowohl in der Bauphase als auch im Kampf weiterhelfen können.
Der Undertaker kann kleine Manipulationen am Terrain machen, falls mal ein Gebäude nicht platziert werden kann wo man es möchte.

Die elementaren Kräfte sind optional, aber eher schwer zu bekommen. In meinem letzten Testlauf hatte ich z. B. nur ein paar Einheiten mit dem Element "HOLY". Erkennen kann man sie daran, dass sie etwas anders ausschauen. Was genau diese Kräfte tun? Teilweise sichtbar in den Einheiten-Stats, einige bieten gar spezielle Aktionen (EARTH -> teleportieren).

Ich bin gespannt, wie und ob es läuft – es steckt wieder viel drin. Der Survival-Modus ist was ich am besten getestet habe, Battle wurde schon lange nicht mehr angefasst.

Probier’s aus – und gerne Rückmeldung, wenn was hakt oder besonders gut gefällt!

Version auf Itch.io:
https://falkenbrew.itch.io/blood-of-the-undead

Ich dreh mich grad etwas im Kreis.

Intro Schlacht
Meine Idee: Eine grosse Szenario-Schlacht als Einstieg in die Story – eine Stadt wird überrannt von Skeletten, Zombies und Vampiren.
Das Ziel: Ein paar Überlebende retten, während um sie herum alles zerfällt.
Mein Wunsch für eine beeindruckende Stadt: Richtige Mauern, auf denen auch Einheiten stehen können.

Aber damit kommen die Probleme:
- Hinter den Mauern werden Einheiten versteckt
- Das Bild müsste man in 90°-Schritten drehen können, um alles sehen zu können

Soweit die Theorie… alles bislang nur im Kopf – aber dann hab ich angefangen, es umzusetzen.

Rotation in 2D
Im Gegensatz zu 3D ist 2D-Rotation richtig mühsam – vor allem, wenn das gesamte System nicht darauf ausgelegt ist.
Beispiel: Meine simplen Hänge/Terrain-Tiles haben klar definierte Bildchen im Texture-Atlas.
Eine Drehung zerstört das Setup und verlangt andere.
Hier sind die Einheiten nicht gedreht und die Tiles sind ziemlich falsch.

Ich habe einige Sachen noch hingebogen, aber nicht alles.

Die Burg
Etwas frustriert hab ich’s dann erstmal gelassen und mich gefragt:
Wie sieht eine Burg überhaupt in meiner Perspektive aus?
Erste Versuche:

Nach ein paar Überarbeitungen:


Erkenntnisse & Frust
Tja… stellt sich raus, einige meiner Grundannahmen waren falsch:
Das Terrain wird zuerst gerendert, also sind Einheiten immer über dem Terrain sichtbar, auch hinter Mauern
Dadurch ist nichts verdeckt. Das macht die ganze Rotation eigentlich überflüssig – aber es sieht nicht gut aus.

Wie weiter?
Vielleicht kann ich das Problem durch gutes Map-Design entschärfen, aber irgendwie fühlt sich das gerade sehr unbefriedigend an.

Also ehrlich gesagt bin ich mir recht unsicher ob ich als Spieler überhaupt die Kamera drehen können will. Die meisten Echtzeitstrategiespiele (die ich gespielt habe) machen das nicht (Age of Empires, War Craft), und in Anno geht das zwar, aber ich mache es höchstens mal kurz und kehre dann in den ursprünglichen Winkel zurück. Ich will mir ja die Map merken können, "die Kaserne ist links neben dem Turm" ist leichter als "die Kaserne ist östlich des Turms", wenn Osten permanent woanders ist.

Age of Empires 2 hat ja auch Klippen, aber die können nix verdecken. Die Einheiten können ganz einfach nicht von hinten / oben so nah an die Mauer laufen, als das sie verdeckt würden. Der Spieler wird das sehr schnell akzeptieren, insbesonders wenn das Leveldesign so ist, dass der Spieler nie in die Situation kommt, dass er es gerne tun würde. Vor allen Dingen wenn du das bloß für ein paar Level benutzen willst, würde ich das so umsetzen. Quasi kein neuer Code erforderlich, keine kompliziertere Steuerung und den Atmosphäreboost hast du trotzdem. Zweitens würd ich die Mauern einfach nicht so hoch machen, das untere Bild ist besser als das obere. Je höher die Mauer, desto komischer ist es, kann man nicht dahinter stehen.

Alternativ kannst du halt deine Renderreihenfolge vernünftig implementieren und dann z.B. Einheiten erlauben etwas näher an die Mauern zu gehen so dass sie halb verdeckt sind. Wieder gilt das selbe: Ist das Leveldesign gut, muss die Spiellogik nicht so toll sein. Wenn es wenig visuellen Clutter gibt (also z.B. keine Blumen) dann reicht es völlig nur die Oberseite der Figuren zu sehen. Also setzt man die Blumen entsprechend mit etwas Abstand zur Mauer und schon hat man das Problem entschärft, ohne Code anzupacken.

Danke Jonathan, das hört sich sehr vernünftig an!

marcgfx hat geschrieben: ↑06.10.2025, 11:21 Danke Jonathan, das hört sich sehr vernünftig an!

Immer gerne :) Btw. die Idee mit "Leveldesign muss zur Spielmechanik passen" ist mir vor langem schon gekommen, jetzt war mal ein guter Zeitpunkt darüber zu reden.

Damals spielte ich "Indiana Jones und der Turm von Babel", was zeitgleich mit Tomb Raider 4 erschienen war. 2 sehr ähnliche Spiele, allerdings waren alle Level in Tomb Raider aus gleich großen Blöcken gebaut, während Indiana Jones beliebige Polygone konnte. Das war super, weil die Level sehr viel komplexer oder detaillierter sein konnten. Leider war die Steuerung etwas kaputt, wollte man an schräge Kanten springen funktionierte das beispielsweise nicht zuverlässig. In Tomb Raider ist immer sofort klar, welcher Sprung funktioniert. 1 Kasten weit ist ein Hopser, 2 Kästen sind ein Hopser mit Hochziehen, 3 Kästen Hopser mit Anlauf und hochziehen und 4 Kästen weit ist unmöglich. In Indiana Jones sind die Abstände kontinuierlich, und es ist auch mit Übung schwer zu sagen, ob man einen Sprung gerade noch so schaffen kann oder ob der gerade so unmöglich ist. Die Lösung ist Level zu bauen, die einfach nicht Distanzen in diesem Grenzgebiet haben, damit es trotzdem für den Spieler immer sofort klar ist, ob ein Sprung möglich ist oder nicht.