Vitalij Mik: godot

Loot und Inventar in Godot: UI mit eigenen Szenen umsetzen

2026-10-28T00:00:00+00:00

Heute habe ich mich an Loot und Inventar gesetzt. Schon am Anfang ist mir dabei ein Fehler aufgefallen: Ich hatte die KI nicht wirklich gesteuert. Bei der Demo dachte ich, sie würde schon wissen, was sie tut, und habe ihr zu viel Kontrolle über den Code gelassen, ohne selbst genau genug hinzuschauen.

Die World.cs war inzwischen für ziemlich viel zuständig: Gegner spawnen, Animationen abspielen, den Spieler steuern und Eingaben verarbeiten. Als ich dann noch die UI für das Inventar einbauen wollte, landete auch die erst einmal in dieser großen Klasse. Nach mehreren Versuchen war das Inventar trotzdem nicht sichtbar.

Im normalen Godot-Projekt würde ich dafür eine eigene 2D-Szene anlegen und ein Script schreiben, das sich nur um diese Szene kümmert. Also habe ich der KI den Hinweis gegeben, das Loot-Fenster und das Inventar als eigene Szenen aufzubauen. Das war der Wendepunkt: Die UI bekam eigene Scripts, während die World.cs die Menüs miteinander verbindet und den Ablauf in der Spielwelt steuert. Danach ließ sich das Verhalten viel besser umsetzen.

Zum Looten können Gegner eine Beutekiste fallen lassen. Wenn ich in ihrer Nähe die Leertaste drücke, öffnet sich das Loot-Fenster. Dort kann ich alles einsammeln, abbrechen oder einzelne Gegenstände auswählen. Ich kann auch zum Inventar wechseln und Gegenstände zwischen dem Loot und meinem Inventar hin- und herlegen. Gleiche Gegenstände werden dabei als ein Eintrag mit einer Anzahl angezeigt.

Rückblickend war nicht unbedingt das verwendete Modell – GPT-6 Luna mit Reasoning-Level „mittel“ – der entscheidende Punkt. Viel wichtiger war, dass ich konkreter beschrieben habe, wie die UI in Godot aufgebaut werden soll. Der Hinweis auf eigene Szenen und getrennte Scripts hat geholfen, die Aufgabe in kleinere, verständlichere Teile aufzuteilen.

Tasten und Layout

Bei der Umsetzung musste ich mir auch Gedanken über die Steuerung machen. Ich möchte das Spiel zunächst komplett mit der Tastatur spielen und später möglichst auch mit einem Xbox-Controller. Die aktuelle Steuerung funktioniert mit der Tastatur; den Controller habe ich bei der Tastenwahl erst einmal als Ziel im Hinterkopf behalten.

Auf der Tastatur habe ich deshalb die Taste „J“ als Bestätigung ausgewählt und „K“ zum Abbrechen beziehungsweise Wegwerfen vorgesehen. Mit „W“ und „S“ bewege ich die Auswahl innerhalb des Loot-Fensters oder des Inventars nach oben und unten. Mit „A“ und „D“ wechsle ich zwischen den Bereichen.

Ein typisches Grid-Layout wollte ich zunächst nicht umsetzen. Für den Anfang sollte eine einfache Liste reichen. Im Grunde dachte ich an Folgendes:

flowchart LR
subgraph Loot
UI["`Alles einsammeln | abbrechen
Item 1 2x
Item 2 1x
Item 3 3x
`"]
end
subgraph Inventar
  UI2["`Item A 1x`"]
end
UI -. Tauschen .-> UI2

Das Verhalten war gar nicht so leicht zu erklären. Am besten hat es funktioniert, als ich den Aufbau mit zwei Spalten in Excel verglichen habe: Die erste Spalte ist in Bereiche aufgeteilt. Oben wechselt man zwischen den Loot-Aktionen, unten wählt man die Gegenstände aus. Dazu kommt die zweite Spalte für das Inventar. Mit diesem Bild konnte ich der KI besser beschreiben, wie die Auswahl zwischen den Bereichen funktionieren soll.

Zum Schluss mussten die Gegenstände noch nach Namen gruppiert werden, damit gleiche Items als Stapel mit ihrer Anzahl erscheinen. Für die Aufbewahrung während des Spiels gibt es eine Session-Klasse. Das ist eine eigene Klasse im Projekt, die von Godots Node erbt. Ihr Inventar ist aktuell eine statische Liste: Es bleibt beim Wechsel zwischen Stadt und Arena erhalten, wird aber noch nicht dauerhaft auf der Festplatte gespeichert.

Fazit

Nach den ersten Tagen merke ich schon, was passiert, wenn ich den Code aus der Hand gebe und nicht genau darauf achte, wie er aufgebaut ist. Die große World.cs hat die Arbeit an der UI erschwert. Mit eigenen Szenen und Scripts wurde das Ergebnis übersichtlicher und das Verhalten ließ sich besser umsetzen.

Immerhin kann ich jetzt zwischen Kampfszene und Stadt wechseln, Gegner besiegen und ihren Loot einsammeln. Es fehlt noch ein Ziel im Spiel: Wozu mache ich das Ganze, und was bringt mir der Loot?

Das sind spätere Fragen. Im Moment denke ich darüber nach, das Projekt mit klareren Regeln und Skills sauber neu anzufangen und mich langsam mehr um die Grafik zu kümmern. Ich merke schon, dass das Aussehen eine wichtige Rolle für den Spielspaß spielt. Vielleicht gehe ich das als Nächstes an.

Mein erstes Spiel mit Godot: Roguelike-Idee und erster Prototyp

2026-10-27T00:00:00+00:00

Mit diesem Blog habe ich mir einen lang gehegten Wunsch erfüllt. Jetzt ist der nächste dran: Ich möchte mein eigenes Spiel entwickeln.

Ich möchte mein eigenes Spiel entwickeln – und so sieht es momentan aus

Im Video ist der aktuelle Stand des Prototyps zu sehen: Ich gehe durch das Portal in die Kampfinstanz und stelle mich den Gegnern. Noch ist das Spiel ganz am Anfang, aber der erste Kampf ist bereits spielbar.

Dein Browser unterstützt keine Videowiedergabe.

Der aktuelle Stand des Prototyps.

Bei der Arbeit kenne ich den üblichen Weg: Eine Anforderung steht fest, daraus ergeben sich Akzeptanzkriterien und Aufgaben. Schritt für Schritt entsteht so ein Projekt. Bei meinem Spiel ist es anders. Es gibt noch keine fertige Anforderung und keinen genauen Plan. Da sind erst einmal nur ein paar Ideen und die Frage: Was könnte daraus werden?

Eine Idee mit vielen Durchläufen

Ich spiele gerne Roguelikes. An diesem Genre gefällt mir, dass es kurzfristige Erfolge mit einem langfristigen Ziel verbindet. Im Kampf stelle ich mich Gegnern, sammle Loot und freue mich über jeden gewonnenen Durchlauf. Gleichzeitig arbeite ich auf etwas Größeres hin: Mit dem Ausbau der Stadt möchte ich bessere Ausrüstung bekommen und mich später stärkeren Gegnern stellen.

In der Stadt beginnt der Spieler seinen Weg. Durch ein Portal gelangt er in ein Gebiet voller Gegner. Wenn er sie besiegt, soll er Beute und Ressourcen mit zurückbringen können. Damit könnte er nach und nach seine Stadt ausbauen: vielleicht mit einer Schmiede, einem Tränkeladen oder Möglichkeiten, Rohstoffe weiterzuverarbeiten.

Jeder Ausflug durch das Portal wäre dabei ein eigener Run. Die Runs könnten auch bestimmen, wie lange Ausbauten dauern. Ob diese Idee am Ende wirklich Spaß macht, weiß ich noch nicht. Genau das möchte ich herausfinden, indem ich zuerst die grundlegende Spielmechanik entwickle.

Warum ich das Spiel entwickeln möchte

Natürlich gibt es schon viele Spiele. Für mich ist aber nicht nur das fertige Spiel das Ziel, sondern auch der Weg dorthin.

Ich möchte mich mit C# beschäftigen. Die Sprache erinnert mich in Teilen an PHP, ist aber kompiliert – und eine solche Sprache wollte ich schon lange besser kennenlernen. Außerdem macht mir das Modellieren in Blender Spaß. Es ist für mich eine entspannende Beschäftigung nach der Arbeit und eine gute Alternative zum Doomscrolling.

Auch beim Einsatz von KI möchte ich dazulernen: Wie muss ein Projekt aufgebaut sein, damit eine KI sinnvoll mitarbeiten kann? Welche Fähigkeiten und Abläufe helfen dabei? Und lässt sich ein Projekt wie dieses gut mit einem GitHub-Kanban-Board organisieren?

Am Ende würde ich das Spiel gerne veröffentlichen. Als ersten Schritt kann ich mir itch.io vorstellen. Mein erstes Spiel direkt auf Steam zu veröffentlichen, wäre mir vermutlich noch zu früh.

Ein weiterer Grund für das Projekt ist, dass ich langfristig eine Grafikkarte anschaffen möchte, mit der ich leistungsfähigere KI-Modelle lokal ausprobieren kann. Mich interessiert, wie weit ich bei der Spieleentwicklung mit einem Modell aus der Qwen-Familie komme und wo seine Grenzen liegen. Für welche Aufgaben reicht die lokale KI aus? Wann ist ChatGPT oder ein anderes Frontier-Modell die bessere Wahl? An diesem eigenen Projekt möchte ich solche Modelle ausprobieren und miteinander vergleichen.

Der erste spielbare Schritt

Für den Anfang wollte ich nicht gleich die ganze Stadt, Beute und Ausbausysteme bauen. Ich brauchte erst einmal eine Figur, die ich steuern kann, und einen Ort, an dem ein Kampf stattfindet.

Dafür habe ich bei Mixamo ein Schwert-und-Schild-Modell samt Animationspaket heruntergeladen und ein neues Godot-Projekt angelegt. Mit Unterstützung von GPT-5.6 Luna entstand daraus der erste Prototyp: zwei Szenen, eine Figur mit Animationen und eine Steuerung mit WASD. Da ich das Spiel auf meinem Notebook auch ohne Maus spielen möchte, löse ich die Aktionen über die Tastatur. Mit der Leertaste geht es durch das Portal in die Kampfinstanz, mit J greift die Figur an.

In der Kampfinstanz tauchen Gegner auf. Sie können mich angreifen, ich kann sie besiegen – und ich kann selbst sterben. Für den Moment ist das der Kern des Prototyps. Spieler und Gegner verwenden noch dasselbe Modell; die Gegner sind lediglich rot eingefärbt.

Danach kamen nach und nach weitere Elemente dazu: eine Schadensanzeige, eine Minimap und ein erster gegnerischer Angriff mit roter Warnfläche. Bleibe ich darin stehen, nehme ich viel Schaden. Entferne ich mich zu weit von den Gegnern, kehren sie an ihre Ausgangsposition zurück und erhalten ihre volle Energie zurück. Außerhalb des Kampfes soll sich außerdem die Lebensenergie meiner Figur wieder auffüllen.

Mehr ist es noch nicht – und das ist in Ordnung. Der Wechsel von der Stadt in die Kampfinstanz, der Kampf und die Möglichkeit zu sterben bilden meinen ersten spielbaren Versuch. Ob daraus ein spannender Kreislauf werden kann, muss sich noch zeigen. In den nächsten Teilen möchte ich erzählen, wie ich den Prototyp weiterentwickle und welche Ideen dazukommen.