Vitalij Mik: gamedev

Das Problem mit den Händen

2026-11-02T00:00:00+00:00

In meinem letzten Beitrag habe ich versucht, aus einem 2D-Bild eine 3D-Figur zu erstellen. Das hat nicht sonderlich gut funktioniert, also habe ich mir gedacht, ich erstelle die 3D-Figur selbst in Blender. Schließlich habe ich ja ein 2D-Bild, das ich als Referenz benutzen kann.

Damals habe ich mir das Bild nur grob angeschaut. Bei der Vorbereitung der Bilder für Blender sind mir dann die ersten Fehler aufgefallen, also wollte ich die erstmal verbessern. Der erste Fehler war die Ansicht von hinten: Die KI hat einfach den vorderen Teil kopiert und das wars. Also musste ich das erstmal nachbessern.

Das Bild habe ich dann in Einzelbilder aufgeteilt und in Blender als Referenz hinterlegt. Als ich dann seitlich draufgeschaut habe, ist mir aufgefallen, dass ich die Breite der Brust und der Hüfte nicht bestimmen kann. Der Arm ist seitlich drüber. Ich benötige also eine T-Pose, und ab hier ging es los mit den Problemen.

Eigentlich dachte ich mir, wie schwer kann es denn sein, die Arme einfach auf Schulterhöhe zu bringen.

So sah das erste Ergebnis aus:

Dann sagte ich der KI, dass die Hände so nicht aussehen, bitte korrekt umdrehen.

Hat wohl auch nicht funktioniert. Das wurde in Codex generiert. Ich dachte mir, ich probiere mal Google Gemini aus. Habe ihm das originale Konzept hochgeladen und dachte, dass Gemini es eventuell besser hinkriegt.

Die alten Arme waren noch drin. Nächster Versuch.

Keine Ahnung, wieso die Daumen da jetzt oben sind. Dann dachte ich mir, vielleicht hilft ein neuer Chat mit frischem Kontext.

Ab diesem Zeitpunkt gebe ich erstmal auf. Ich habe ja die Hand von oben, unten und von der Seite. Das, was hinten wird, wird sich dann vermutlich von alleine ergeben.

Vielleicht sollte man das Thema nicht zu perfektionistisch angehen. Ich fand es aber interessant, wie oft ich versucht habe, die Hand zu verbessern, und am Ende bin ich nicht zu einem guten Ergebnis gekommen. Bei den Bildern habe ich ja nur die Hände gezeigt. Dazwischen sind noch mehr Fehler immer wieder aufgetreten.

Es gab falsche Proportionen, falsche Farben, Hände in anderen Darstellungen waren verdreht.

Ich glaube, wenn man da nicht genauer auf die Details schaut und offensichtliche Dinge falsch dargestellt werden, kann das Spiel sehr schnell als “KI-Slop” angesehen werden.

2D zu 3D ist schwieriger, als man denkt

2026-10-29T00:00:00+00:00

Heute wollte ich mal zur Abwechlung etwas visuelles gestalten. Ich dachte ich beginne mit der Hauptfigur, schließlich werde ich die in der nächsten Entwicklung immer wieder sehen.

Wie fängt man da überhaupt an? Ich habe in dem Bereich keine Erfahrung. Auf jeden Fall wollte ich Mechas haben. Ich habe immer Mechas geliebt. Die Animes wie “Vision of Escaflown” oder “Gundam Brotherhood of Steel” sehen extrem gut aus. Früher habe ich auch viele Stunden in das MMORPG RF Online invistiert und das nur wegen der Rasse “Accretia”. Also habe ich die Beispiele als Vorlage benutzt. Ich lies Codex erstmal ein paar Referenzbilder downloaden und anschließend mir ein Concept Art daraus generieren als Basis.

KI-generiertes Bild

Das Ergebnis sieht echt super aus. Im Spiel wäre das für mich eher die Endgame Ausrüstung also wollte ich das als Basis nehmen und vereinfachen. Man muss ja irgendwo unten Anfangen und sich dann hoch hinaus arbeiten. Also gab es einige Iterationen. Und für den Anfang sah das für mich am besten aus.

KI-generiertes Bild

Es hat weniger details als das Original aber mir fehlten einfach die Fähigkeit es besser zu beschreiben und ich dachte mir, ich mache es wie bei Software. Es wird nach und nach einfach verbessert und fertig. Es ist also v0.1-alpha

Jetzt kam das nächste Problem. Das Bild steht, aber ich brauche es als 3D Objekt damit ich es eben Animieren kann. Es gibt viele Anbieter bei denen man mittels KI ein Bild hochladen kann und daraus entsteht dann ein 3D Model. Ich will diese aktuell nicht verwenden weil ich einfach nicht extra Geld ausgeben will. Ich zahle ja jetzt schon für Codex.

Eine andere Methode wäre “Visual Hull”. Dabei wird ein 2D Bild in unterschiedlichen Perspektiven. Also Link, Vorne, Hinten, Oben und Unten abgebildet. Es wird daraus eine Silouette ermittelt und dann kann man die einzelnen Punkte zusammen verbinden.

Der nächste Schritt wäre also mein Konzept Orthogonal zu generieren mit den einzelnen Seiten. Das Ergebnis sieht so aus.

KI-generiertes Bild

Mit GTP-6 Luna und Medium können da echt gute Bilder entstehen. Ich dachte mir das Ergebnis wäre schon fast fertig. Nur noch ein bisschen.

Codex hat anschließend die Bilder einzeln ausgeschnitten, den Hintergrund Transparent gemacht und ein Python Script geschrieben was de Visual Hull nachbilden soll.

Das Ergebnis sah dann überhaupt nicht gut aus

Es gibt also schon ein Grund wieso die Anbieter für 3D Modelle, Geld verlangen. Das Thema habe ich mir einfacher vorgestellt.

Blender hat ja auch einen MCP-Server. Damit kann eine KI ebenfalls Modelle erstellen. Das habe ich natürlich ausprobiert, und dabei ist Folgendes herausgekommen:

Ich glaube aber, dass ich da erst einmal keine Zeit investieren will. Ich habe ja das Bild aus allen Seitenansichten. Als Nächstes werde ich mich selbst an Blender setzen und die Figur erstellen.

Ich habe früher schon mit Blender experementiert und ein paar Tutorials abgearbeitet, mal sehen ob ich mich noch an alles erinnern kann und ob der Skill wie mit Fahrradfahren ist.

Aber generell kann man sagen, dass man die KI für eine Konzeption sehr gut verwendne kann, wahrscheinlich fehlen mir Skills um Probleme in den Bildern jetzt schon zu erkennen. Das werde ich wohl in der Zukunft dann herausfinden.

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.

Vitalij Mik: gamedev

Das Problem mit den Händen

2D zu 3D ist schwieriger, als man denkt

Loot und Inventar in Godot: UI mit eigenen Szenen umsetzen

Tasten und Layout

Fazit

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

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

Eine Idee mit vielen Durchläufen

Warum ich das Spiel entwickeln möchte

Der erste spielbare Schritt

Quellen