Vitalij Mik

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.

Goose statt Crush: weniger Tokens für die gleiche Arbeit

2026-10-31T00:00:00+00:00

Jetzt, wo ich auf DeepSeek umgestiegen bin und genauer sehen kann, wofür ich Tokens ausgebe, wollte ich mir mal die Agenten anschauen, die ich verwende. Bei Codex hatte ich Codex CLI und Crush zusammen benutzt. Mir ist immer wieder aufgefallen, dass ich mit Crush relativ früh an mein Stunden-Limit gekommen bin.

Tatsächlich haben sich auch andere mit der Frage des Tokenverbrauchs beschäftigt, und so bin ich auf den Artikel hier gekommen: https://arxiv.org/pdf/2607.22585

Hier wird goose CLI als Basis genommen und mit OpenHands und OpenCode verglichen. Der Beitrag ist von Juni 2026, es kann also sein, dass das zum Zeitpunkt, wo du es liest, nicht mehr stimmt.

Auf jeden Fall fand ich interessant, dass goose CLI 40-mal weniger Tokens verbraucht als OpenCode. Damit kann man für das gleiche Geld die gleiche Leistung erbringen.

Warum ich bei goose wieder vorbeigeschaut habe

Goose kannte ich schon früher. Ich habe es immer wieder lokal mit einem 9B-Modell getestet, leider funktionierte es damals nicht so gut. Das 9B-Modell konnte die Toolcalls in goose nicht besonders gut umsetzen, oft gab es Fehler und Endlosschleifen.

Anschließend habe ich dann Crush gefunden, und damit konnte ich mit einem 9B-Modell lokal arbeiten. Das Problem war aber, dass ich nicht nur ein 9B-Modell hatte, sondern auch nur ein ca. 42k-Token-Fenster. Meine Grafikkarte RTX 3060 Ti hat nur 8 GB VRAM, und ich bin da eingeschränkt.

Das heißt, Crush konnte zwar besser die Tools aufrufen und Dateien lesen, aber ich hatte dafür immer wieder Context-Zusammenfassungen, wo dann Inhalte aus dem Kontext geflogen sind. Es war also nur möglich, kleine Dinge umzusetzen.

Zum aktuellen Zeitpunkt kann man also nichts Wesentliches mit wenig VRAM lokal umsetzen.

Der erste Test: ein einfaches „Hi“

Wie dem auch sei, ich habe mir also goose installiert und als Erstes einfach nur „Hi“ getestet, um den initialen Tokenverbrauch zu messen.

Bei Crush habe ich ca. 12k Tokens benutzt.

Man muss hier aber bedenken, dass ich die Crush-Toolcalls schon eingeschränkt habe. Ich habe zum Beispiel alle LSP-Tools deaktiviert, da ich lokal kein LSP verwende.

Und hier haben wir goose:

4k Tokens bei einem einfachen „Hi“. Sind auf jeden Fall dreimal so wenig.

Die komplexere Aufgabe

Als Nächstes wollte ich eine komplexere Aufgabe umsetzen, damit ich den Vergleich zu gestern habe. Ich ließ goose das, was ich vorher über bash installiert hatte, als Paket zu Void hinzufügen. Dazu kam noch das Paket lightpanda. Das ist ein Headless-Browser für KI, damit man auch Inhalte von Webseiten laden kann, die JavaScript benötigen, ohne extra Chrome oder Firefox im Headless-Modus zu starten.

Das Ganze war ein Rust- und Zig-Build. Mir ist in der Statistik in DeepSeek aufgefallen, dass man mit goose wirklich weniger Tokens benutzt und mehr Output-Tokens generiert werden.

Output-Tokens sind eigentlich die wichtigen Tokens. Das ist ja das Wissen, das ausgegeben wird.

Ich bin mir noch unsicher, wie ich die Statistik selbst bewerten soll. Ich habe weniger Tokens gebraucht für eine komplexe Aufgabe, aber genauso viel bezahlt, weil eben mehr Output-Tokens kamen. Vielleicht kann man das noch mit dem caveman skill besser steuern.

Ich sammle aktuell nur Erfahrungen, konkret kann ich noch nichts sagen.

Was ich von einem Agenten erwarte

Eigentlich habe ich relativ einfache Anforderungen an den Agenten:

Er soll wenige Tokens verbrauchen
Er soll konfigurierbar und erweiterbar sein
Er soll meine Provider unterstützen
Er soll wenig RAM verbrauchen
Er soll gut aussehen und gut bedienbar sein

Goose vs. Crush

Goose verbraucht bei mir ca. 240 MB RAM, während Crush nur bei 88 MB liegt. RAM-Nutzung ist relevant, wenn Subagenten gestartet werden. Codex war bei 300 MB. Hier gewinnt Crush natürlich.

Konfigurierbar und erweiterbar sind beide. Aber ich glaube, in goose könnte ich sogar den System-Prompt anpassen. Bei Crush geht es nicht. Ich kann höchstens eigenen Text dazuschreiben. Ich würde hier noch sagen, es ist ein Unentschieden, da ich mich mit goose noch nicht so stark beschäftigt habe.

Goose unterstützt DeepSeek direkt als Provider, während man es bei Crush manuell konfigurieren musste. Es gibt zwar DeepSeek, aber das wird über irgendeinen Open Router angeboten und nicht das direkte. Hier ist goose dann besser.

Vom Aussehen her gewinnt Crush. Es sieht viel besser aus. Tool-Ausgaben werden versteckt, man sieht im Output am Ende nur das, was einen wirklich interessiert. Bei goose wird alles in der Konsole ausgegeben und man muss ständig scrollen, das ist nicht besonders schön.

Goose hat noch zwei weitere Vorteile. Es gibt goose Desktop, das im Grunde wie Claude oder Codex Desktop aussieht. Wenn man eher so ein Interface bevorzugt, hat man die Möglichkeit, es zu nutzen.

Außerdem hat goose ACP-Unterstützung. Ich kann goose im Editor Zed konfigurieren und benutzen. Dann wäre vermutlich die Tool-Ausgabe und Übersichtlichkeit besser als bei der CLI-Lösung.

Crush hat noch den Nachteil, dass es in jedem Projekt einen .crush-Ordner anlegt, mit einer SQLite-Datenbank und weiteren Dingen. Goose legt das irgendwo zentral ab. Wenn ich es mal löschen will, lösche ich einen Ordner und fertig.

Fazit

Also hat alles bisher Vor- und Nachteile. Ich denke, ich muss es mehr in meinen Projekten einsetzen, um ein besseres Urteil zu fällen.

Eigentlich bevorzuge ich Crush auf der CLI. Vermutlich wäre das Beste, Crush zu forken und den System-Prompt sowie die Tool-Beschreibung für Bash zu verändern. Dann würde ich direkt weniger Tokens verbrauchen. Aber ich denke, ich werde erstmal Goose über den Zed-Editor als ACP einsetzen und schauen, wie gut es funktioniert.

Weiterführende Links

Von Codex-Abo zu DeepSeek Pay-per-Use: mein Fazit nach dem ersten Tag

2026-10-30T00:00:00+00:00

Stell dir vor, du zahlst jeden Monat 23 €, um in deiner Freizeit mit KI zu programmieren, und nach ein paar Stunden bist du gezwungen, eine Pause einzulegen, weil dein 5-Stunden-Limit erreicht ist. Wenn du aber mal einen Tag nichts machst, wird dir dieses Limit nicht gutgeschrieben.

Wenn du also einen vollen Monat lang nicht programmierst, zahlst du trotzdem weiterhin 23 €. Das hat mich aktuell so derart frustriert, dass ich mich mal nach Alternativen umgeschaut habe.

Mein Use Case ist eigentlich ein einfacher. Nach der Arbeit so ab 17 Uhr arbeite ich ein paar Stunden an einem Projekt. Die KI entscheidet nicht für mich, sie muss nicht über Nacht laufen. Sie soll einfach nur das machen, was ich will. Also nichts Intensives. Ich bin kein Poweruser. Aber dennoch bin ich besonders am Wochenende immer wieder an mein Limit gekommen.

Ich habe mir meine Statistik angeschaut: In den letzten 7 Tagen habe ich ca. 72 Millionen Tokens benutzt. Leider sieht man in der Oberfläche von Codex nicht, ob das gecachte Tokens waren und wie sich die Summe auf Input, Cache und Output verteilt.

Es gab auch Tage, an denen ich nichts getan habe, und man hatte die ganze Zeit im Hinterkopf: „Wenn ich heute das Limit nicht aufbrauche, dann ist das Geld weg.”

Ich habe mir also mal die Benchmarks der anderen Modelle angeschaut. Vorher hatte ich GPT6 Luna benutzt, das war für meine Zwecke völlig ausreichend. In der Liste habe ich dann DeepSeek V4.1 Flash gesehen, und es war besser als Luna bewertet.

Auf der Seite von DeepSeek hat mich besonders die Preisliste überzeugt. Du zahlst nur, was du verbrauchst, und außerhalb der Arbeitszeiten in China ist es günstiger. Da ich abends programmiere, liege ich automatisch außerhalb dieser Zeit.

Ein weiterer Punkt war, dass ich nicht direkt ein Abo abschließen muss. Einfach eine Art Prepaid-Konto: Ich lade eine Summe auf, und wenn sie aufgebraucht ist, kann ich die KI nicht mehr nutzen. Fette Rechnungen können so gar nicht erst entstehen. Ich habe erst mal 2 € aufgeladen und konnte es damit ausprobieren.

Der erste echte Test: Pakete unter Void Linux

Heute wollte ich mein Void-Linux-System etwas aktualisieren, und die Pakete waren dafür ein guter Test-Use-Case.

Bei Void Linux klont man das Paket-Repository lokal über Git. Pro Paket gibt es eine Template-Datei, in der die Version, die Art des Builds und die Build-Abhängigkeiten stehen. Außerdem steht dort zu jedem Paket der GitHub-Pfad.

Ich ließ mir also Code generieren. Der Code enthält eine feste Liste an Paketen, die ich aktualisieren will. Für diese Pakete wird die Template-Datei herausgesucht und die aktuelle Version ausgelesen. Danach wird auf GitHub beim Paket geschaut, ob es eine neuere Version gibt. Wenn ja, wird die neue Version ins Template geschrieben, anschließend der Build-Prozess angestoßen und danach die Build-Abhängigkeiten wieder gelöscht.

Heute habe ich OBS auf die Version 33.0 aktualisiert. Die neue Version braucht FFmpeg 8, das Void gar nicht hat. Also hat die KI mir ein neues Template angelegt, damit ich OBS über das Skript neu bauen kann. Natürlich wurde der Build-Prozess vorher lokal getestet, und für das Template hat sie die richtigen Dev-Abhängigkeiten ermittelt und eingetragen.

Den Code kannst du hier finden: https://gist.github.com/BlackScorp/4b2cbdd0305a012501fc732f6e2a7347

Du siehst also, es war etwas mehr als „färbe den Button grün”.

Was das am Ende gekostet hat

Ich glaube generell, dass man sich auf die Benchmarks mittlerweile nicht mehr verlassen kann. Alles, was in der Größenordnung von Qwen 3.8 27B oder darüber aufgelistet ist, reicht für die normalen Tasks völlig aus.

Ich vergleiche die Benchmarks gern mit der Formel 1. In der Regel reicht dir auch ein Fiat, um von A nach B zu kommen. Die Formel-1-Autos sind für den normalen Verbraucher nicht relevant.

Mit dem heutigen Task habe ich etwas über 22 Millionen Tokens verbraucht, und das hat mich 14 Cent gekostet. Bei Codex wären es bei 23 € auf 30 Tage gerechnet 0,77 € pro Tag. Das heißt, ich konnte vermutlich am Ende des Tages mehr machen für weniger Geld.

Und wenn ich mal nichts tue, kostet es mich auch nichts. Natürlich ist das nur ein einziger Tag, ich muss da noch mehr Erfahrung sammeln. Bisher ist es aber doch positiv.

Ein negativer Punkt

Ich habe den Agenten „Crush” verwendet und habe das Gefühl, dass damit irgendwie mehr Tokens verbrannt werden. Mit dem Agenten bin ich bei Codex schneller an das Limit gekommen als mit der CLI von Codex selbst. Das werde ich morgen mal mit dem Client von DeepSeek selbst ausprobieren.

Und ich kann keine Bilder über DeepSeek generieren, nur anschauen und verstehen kann es sie. Ich denke aber, dass ich für diesen Fall einfach Google Gemini verwenden werde. Da habe ich 100 freie Bilder am Tag, die ich generieren kann, das sollte reichen.

Fazit

Wenn du einen ähnlichen Use Case wie ich hast, dann probiere DeepSeek mal aus. Ein Prepaid-Guthaben macht den Einstieg leicht, und man sieht direkt, was ein einzelner Task wirklich kostet.

Weiterführende Links

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.

Quellen

Dynamische Funktionen mit Jekyll und GitHub Pages

2026-10-25T00:00:00+00:00

Die Idee: ein eigener Blog

Ich wollte schon immer mal einen eigenen Blog führen und meine Experimente dokumentieren. Ein Blog zu führen erlaubt es, eigene Gedanken besser zu strukturieren und Probleme besser zu verstehen und zu verarbeiten. Er ist also nicht nur für andere Leser gedacht, sondern auch für mich selbst.

Ich habe allerdings besondere Ansprüche an einen Blog und wenig Zeit gehabt, um ihn aufzusetzen.

Bei „statisch“ denken viele vielleicht zuerst daran, dass es keine dynamischen Funktionen wie Kommentare geben kann. Genau das wollte ich ausprobieren: Kann ich einen Blog mit einem Static-Site-Generator betreiben und trotzdem Kommentare und automatische Abläufe integrieren?

Meine Idee war: Ich öffne einen Markdown-Editor meiner Wahl und kann direkt mit dem Schreiben loslegen. Code und Syntax-Highlighting sollten auf jeden Fall drin sein. Der Text sollte versionierbar sein und einfache Diagramme sollten auch möglich sein.

Außerdem will ich die Freiheit haben, das Layout komplett selbst zu gestalten, und ich möchte kein Geld fürs Hosting ausgeben. Ich will mich auch nicht um Updates von Server und Infrastruktur kümmern.

Doch wie funktioniert das im Detail?

Grundlegendes

Auf GitHub besteht die Möglichkeit, ein Repository mit dem Namen <username>.github.io anzulegen. Alles, was du hier veröffentlichst, ist auch unter der URL https://<username>.github.io erreichbar.

Standardmäßig versucht GitHub, in diesem Repository den Static-Site-Generator Jekyll zu verwenden. Du könntest zum Beispiel eine Datei .nojekyll und eine index.html mit „Hallo Welt“ anlegen und nach dem Pushen des Git-Commits das Ergebnis sehen.

Ich möchte in meinem Fall aber Jekyll verwenden, da bei einem Blog automatisch RSS-Feeds, Tags und Ähnliches generiert werden können.

Docker setup

Bevor ich überhaupt loslegen kann, muss ich ja irgendwie eine Vorschau lokal haben. Ich könnte zwar ein Jekyll-Template verwenden, dieses immer wieder auf GitHub deployen und schauen, was am Ende herauskommt. Das würde aber zu lange dauern.

Deshalb habe ich mir als Erstes ein Dockerfile mit Jekyll gebaut.

FROM ruby:3.3

WORKDIR /site

ENV BUNDLE_GEMFILE=/site/jekyll/Gemfile

COPY Gemfile Gemfile.lock ./jekyll/
RUN bundle install

Der Container musste noch in einer docker-compose.yaml konfiguriert werden. Das sieht dann so aus:

name: blog

services:
  jekyll:
    build: .
    command: ["bundle", "exec", "jekyll", "serve", "--host", "0.0.0.0", "--port", "4000", "--force_polling"]
    ports:
      - "127.0.0.1:4000:4000"
    volumes:
      - ..:/site
    environment:
      JEKYLL_ENV: production

Jetzt konnte ich die ersten Dateien ablegen und mir unter http://localhost:4000 die Vorschau anzeigen lassen. Ich musste nichts bei GitHub commiten und nicht warten.

Als Nächstes war das Layout dran. Ich habe zunächst versucht, mir mit Codex ein paar Layoutvorschläge generieren zu lassen. Das hat allerdings nicht besonders gut funktioniert. Besser lief es, als die Layouts als Bilder generiert wurden. Mit Bildern konnte Codex irgendwie besser umgehen als mit HTML. Nach einigen Vorschlägen habe ich mich für das Layout entschieden, das du gerade siehst. Es sollte dunkel und schlicht sein und Orange als Highlightfarbe haben.

Der Rest war nur noch, die Styles aus dem Bild zu extrahieren und im Blog zu konfigurieren. Natürlich hat das die KI für mich gemacht.

Beiträge erstellen

Nach dem Setup konnte ich dann direkt loslegen. Die Beiträge landen im Unterordner _articles/<Name>/index.md. Alle Bilder, die zum Blogbeitrag gehören, landen auch in diesem Ordner.

Die index.md ist in zwei Teilen aufgebaut. Ganz oben stehen die Metainformationen zum Beitrag, wie zum Beispiel die URL, wann der Artikel veröffentlicht wurde, das Layout, die Tags oder Keywords. Das ist das Front Matter.

Darunter kommt ganz normal mein Inhalt. Syntax-Highlighting geschieht über CSS und Diagramme kann man mit dem Mermaid-JavaScript-Framework im Browser rendern. Mehr braucht man erst mal nicht.

Dynamische Kommentare

Jetzt gehört ja zu jedem Blog auch die Kommentarfunktion. Diese kann man auf einer statischen HTML-Seite relativ schwierig umsetzen. Viele würden ein Iframe von Disqus oder Ähnlichem einbinden. Ich entschied mich für einen anderen Weg. Auf GitHub gibt es Workflows, die man bei bestimmten Events auslösen kann. Außerdem hat GitHub eine Diskussionsplattform. Hier können GitHub-Nutzer sie wie eine Art Forum verwenden. Es gibt eine besondere Kategorie „Ankündigungen“. In dieser Kategorie kann nur ich als Betreiber einen Eintrag erstellen, und andere Nutzer dürfen nur kommentieren.

Meine Idee war jetzt folgende: Wenn ich einen Beitrag veröffentliche, erstelle ich eine neue Ankündigung. Die URL der Ankündigung hinterlege ich im Front Matter meines Blogbeitrags. Anschließend erstelle ich einen Workflow auf GitHub. Dieser holt sich die neuesten Kommentare und exportiert sie als JSON in den Ordner _data/comments.

Jekyll liest die Kommentare und zeigt sie unter dem Blogbeitrag an. Der Trigger für den Workflow ist also ein Kommentar.

Der Prozess besteht also aus mehreren Schritten. Die Skriptausführung geschieht über actions/github-script. Ich kann eine Node.js-Datei erstellen und darin alles abarbeiten.

Den kompletten Workflow mit Triggern findest du in der publish.yml des GitHub-Actions-Workflows.

Automatische Ankündigungen

Nachdem ich den Blog und die Workflows mehrfach ausprobiert hatte, bin ich auf die Idee gekommen, dass ich auch automatisch Ankündigungen anlegen kann. Das Skript dazu habe ich in Bash geschrieben. Die Idee ist, alle Artikel herauszusuchen, die published: true im Front Matter haben und keinen comments_key. Wenn es den comments_key nicht gibt, dann gibt es noch keine Ankündigung für den Beitrag. So kann man die Ankündigung automatisch erstellen, ihre ID auslesen und ins Front Matter schreiben. Der Job würde nächtlich laufen oder dann, wenn ich ihn manuell über GitHub starte.

Fazit

Dank GitHub, KI und Jekyll konnte ich mir nun meinen Traum erfüllen und einen eigenen Blog starten. Vielleicht wäre es auch eine Idee für dich. Wenn du einfache Seiten hast und nicht unbedingt dynamischen Content direkt benötigst, kannst du durchaus einiges über Static-Site-Generatoren und GitHub Actions lösen.

Ich habe auf jeden Fall jetzt die Möglichkeit, einfach einen Text in Markdown zu schreiben und das Layout für alle Blogbeiträge direkt zu bearbeiten. Ich kann den Blog auch mal selbst hosten. Und wenn jemand einen Gastbeitrag bei mir machen möchte, kann er das über einen Pull Request im Projekt machen.