Tagsüber kümmere ich mich als M365-Administrator um Exchange, Entra ID und Teams. Abends und am Wochenende baue ich an etwas völlig anderem: Journey TD, einem 2D-Tower-Defense-Roguelite in Pixel-Art. Am 11. November 2026 erscheint es auf Steam. Weil das hier ein Technik-Blog ist, will ich nicht nur erzählen, was das Spiel ist, sondern vor allem, wie es entstanden ist.
Kleiner Spoiler vorweg: Mein Admin-Alltag hat mir dabei mehr geholfen, als ich anfangs gedacht hätte.
JOURNEY TD
Die Idee: klassisches Element-TD trifft Roguelite
Meine Inspiration waren die Tower-Defense-Klassiker, die ich früher stundenlang gespielt habe, allen voran YouTD. Das Prinzip: Türme gehören zu Elementen, jedes Element hat seine eigene Identität, und der eigentliche Reiz liegt darin, die richtigen Kombinationen zu finden. Journey TD nimmt diese Idee und gibt ihr eine moderne Roguelite-Struktur. Jeder Run ist anders, aber der Fortschritt bleibt.
In jedem Run draftest du Elemente und schaltest damit deren Türme frei. Feuer, Eis, Sturm, Dunkelheit und Gift stehen von Anfang an zur Wahl, das sechste Element muss man sich erst verdienen. Die Türme sind dabei nicht nur Waffen, sondern auch Wände: Du baust das Labyrinth, durch das die Gegner laufen müssen. Wer Schadensarten und Rüstungstypen klug kombiniert, knackt auch die härtesten Wellen.
Zwei Dinge sind mir besonders wichtig. Das eine ist die DPS-Arena. An festgelegten Wellen pausiert der Run (im 150-Wellen-Modus siebenmal), und deine Türme müssen in zwei Kämpfen von je 20 Sekunden zeigen, was sie können: erst gegen ein Einzelziel, dann gegen eine ganze Gruppe. Je mehr Schaden, desto besser die Belohnung, von Bronze bis Diamant. Ein ehrlicher Test, ob der eigene Build wirklich trägt.
Das andere ist der Baumeister. Statt eines anonymen Bau-Cursors läuft eine sichtbare Figur über die Karte, sucht sich ihren Weg durchs Gelände und zieht jeden Turm mit dem Hammer hoch. Klingt nach einer Kleinigkeit, verändert aber spürbar, wie sich das Bauen anfühlt.
Gespielt wird auf drei Karten: Wald, Friedhof und Wüste. Jede bringt eigene Ereignisse mit, etwa das Totenglücksrad oder den Dschinn, und hat ihre eigene Bestenliste. Dazu kommen vier Modi: die klassischen Runs über 150 oder 300 Wellen, der Endlosmodus und das Kolosseum mit eigener Bestenliste.
Zwischen den Runs wird man dauerhaft stärker: Materialien in sechs Qualitätsstufen, 27 extrem seltene Machtrunen, der Transzendenzbaum mit 98 Knoten und darüber der Astralbaum mit endlosen Paragon-Stufen. Dazu kommen sechs Götter, deren Gaben und Prüfungen jedem Run eine Richtung geben.
| Journey TD auf einen Blick | |
| Genre | Tower Defense / Roguelite, 2D-Pixel-Art, Singleplayer |
| Engine | Godot 4 (GDScript) |
| Umfang | Über 160 Türme in 6 Elementen |
| Karten | Wald, Friedhof und Wüste – mit eigenen Events und Bestenlisten |
| Modi | 150 Wellen, 300 Wellen, Endlos und Kolosseum, dazu 6 Schwierigkeitsgrade |
| Progression | 27 Machtrunen, Transzendenzbaum (98 Knoten), Astralbaum mit Paragon-Stufen |
| Extras | 378 Achievements, Steam-Bestenlisten, Ghost-Rennen gegen den eigenen Bestwert |
| Sprachen | 9 Sprachen, darunter Deutsch und Englisch |
| Anforderungen | Windows 10 (64 Bit), 2 GB RAM, Grafikkarte mit OpenGL 3.3 |
| Release | 11. November 2026 auf Steam |
Der Tech-Stack: Warum Godot 4
Mein vorheriges Spielprojekt, ein Horde-Survivor namens Abyss Surge, lief noch in Unity. Für Journey TD bin ich auf Godot 4 umgestiegen, obwohl ich die Engine bis dahin nie benutzt hatte. Die Gründe waren pragmatisch: Godot ist Open Source, schlank, hat einen starken 2D-Workflow und verlangt weder Lizenzgebühren noch Umsatzbeteiligung. Und GDScript liest sich für jemanden mit Ruby- und Scripting-Hintergrund angenehm vertraut.
Unter der Haube ist das Spiel recht klassisch aufgebaut. Zentrale Manager für Spielzustand, Wellen und Türme laufen als Autoloads, also als global verfügbare Singletons. Die Karten bestehen aus gemalten 16-Pixel-Kacheln in TileMapLayern, gebaut wird auf einem Raster mit 48 Pixel großen Feldern. Die gesamte Oberfläche hängt an einem zentralen Godot-Theme. Panels, Rahmen und Farben sind damit an genau einer Stelle definiert, was bei Dutzenden Menüs und Tooltips enorm viel Arbeit spart.
Ein unterschätzter Teil der Arbeit ist alles rund um Steam: Achievements (am Ende sind es 378 geworden), Bestenlisten mit globaler, Freundes- und Umfeld-Ansicht, lokalisierte Rich Presence für die Freundesliste, Beta-Branches für Tester und eine eigene Demo-App. Dazu kommt ein Speichersystem mit Versionsnummer, damit das Spiel bei jedem Update weiß, in welchem Format ein Spielstand geschrieben wurde. Aktuell steht das Format bei Version 17. Und weil Journey TD auf möglichst vielen Rechnern laufen soll, reichen 2 GB RAM und eine Grafikkarte mit OpenGL 3.3.
Mein Entwicklungsprozess: Change Management für Spielcode
Ein Spiel dieser Größe allein neben dem Job zu bauen, funktioniert nur mit Disziplin. Ohne feste Abläufe verliert man sich schnell in halbfertigen Features und in Bugs, die man vor drei Wochen schon einmal behoben hatte.
Deshalb folgt bei mir jede Änderung demselben Ablauf:
- Kontext und Ziel. Was existiert schon, und was soll am Ende stehen?
- Erst planen. Bevor eine Zeile Code entsteht, wird der bestehende Code analysiert und ein konkreter Plan aufgeschrieben.
- STOP-Gate. Der Plan wird geprüft. Erst nach der Freigabe geht es an die Umsetzung.
- Erst ein Muster. Bei Grafiken und Sounds entsteht zuerst ein einzelnes Beispiel, dann die ganze Serie.
- F5-Check. Spiel starten und das Ergebnis mit eigenen Augen prüfen.
- Dokumentieren. Jede Änderung und jeder Bugfix landet in einer Wissensdatenbank im Projekt, mit Bezug zur Issue-Nummer.
Wer in der IT-Administration arbeitet, erkennt das Muster sofort. Das ist im Grunde Change Management: kein Change ohne Plan, kein Rollout ohne Freigabe, und was nicht dokumentiert ist, existiert nicht. Größere Systeme entstehen zusätzlich schrittweise über nummerierte Arbeitssitzungen (S1, S2, S3 …), jede mit einem klar abgegrenzten Ergebnis. Ein gestaffelter Rollout also, nur eben im Spielcode statt im Tenant.
Auch bei Tests bin ich streng geworden. Neue automatisierte Prüfungen müssen zuerst nachweislich fehlschlagen können, bevor ich ihnen vertraue. Mein Leitsatz dafür:
Ein Test, der nie rot werden kann, ist keiner.
Der Look: Arkan-Violett und Pixel-Art
Optisch hat Journey TD eine klare Linie: Das Spiel spielt in der Welt einer dunklen Magier-Akademie. Obsidian und Anthrazit bilden den Grundton, Arkan-Violett kommt überall dort zum Einsatz, wo etwas leuchten soll. Die Oberfläche ist handgemalt: dunkler Obsidian mit Steinrahmen und Amethyst-Kristallen, damit sich jedes Menü anfühlt, als wäre es aus der Spielwelt herausgeschlagen.
Damit über 160 Türme, Hunderte Icons und unzählige Effekte wie aus einem Guss wirken, arbeite ich mit festen Stilvorgaben und Referenzbildern. Jedes Element hat seine eigenen Farben und Projektil-Schweife, sodass man auch im größten Chaos einer Welle erkennt, welcher Turm gerade was tut. Und wo es geht, entstehen zusammengehörige Motive als ein einziges Bild statt aus vielen Einzelteilen, etwa ein Schrein samt Wächterfigur. Das wirkt deutlich stimmiger als zusammengestückelte Ebenen.
Was ich gelernt habe
Der gefährlichste Gegner ist nicht die Bosswelle, sondern das nächste coole System. Runen, Skillbäume, Materialien, Götter: Jedes Feature hat beim Bauen Spaß gemacht, aber zu viele parallele Progressionssysteme drohten das Spiel zu überfrachten. Irgendwann habe ich mir eine einfache Regel gesetzt: erst die bestehenden Systeme spielen und testen, dann neue bauen.
Balancing ist Datenarbeit. Für die Türme habe ich ein eigenes DPS-Benchmark-Tool gebaut, das Schadenswerte vergleichbar macht. Ohne solche Messungen wären Überarbeitungen wie die neue Skalierung von Schaden über Zeit oder das neu gestaltete Rüstungssystem reines Bauchgefühl gewesen.
Ein guter Satz schlägt jede Zahlentabelle. Jede Turm-Fähigkeit wird in einem einzigen verständlichen Satz beschrieben, in dem alle wichtigen Zahlen direkt drinstehen. Kein Zahlensalat, kein Suchen in Untermenüs.
Dokumentation ist das Gedächtnis des Projekts. Bei einem Spiel dieser Größe vergisst man schneller als gedacht, warum etwas genau so gebaut wurde. Die Wissensdatenbank im Projekt ist mein wichtigstes Werkzeug, sobald ich an ein System zurückkehre, das ich wochenlang nicht angefasst habe.
Beta und Community
Seit einigen Wochen läuft eine geschlossene Beta mit rund 50 Testern über einen eigenen Steam-Beta-Branch. Das Feedback kommt vor allem über unseren Discord, und es hat das Spiel spürbar besser gemacht. Dafür an dieser Stelle schon mal ein großes Dankeschön! Zum Release gibt es übrigens einen kompletten Reset: Alle starten mit einem frischen Spielstand bei null, auch die Tester.
Wer mitreden oder einfach nur zuschauen will, findet Journey TD auf Discord, im Subreddit r/JourneyTD und auf TikTok mit kurzen Clips aus der Entwicklung.
Wie geht es weiter?
Am 11. November 2026 erscheint Journey TD auf Steam. Wer neugierig geworden ist, kann das Spiel schon jetzt auf die Wunschliste setzen. Das hilft gerade kleinen Indie-Spielen sehr: Alle auf der Wunschliste bekommen zum Release eine Benachrichtigung, und viele Wishlists sorgen für mehr Sichtbarkeit auf Steam.
In den nächsten Beiträgen möchte ich tiefer in einzelne Themen einsteigen, zum Beispiel wie ich Achievements und Bestenlisten an Steam angebunden habe oder wie das Rüstungs- und Schadenssystem unter der Haube funktioniert. Wenn euch ein Thema besonders interessiert, schreibt es gern in die Kommentare.
