6 Monate, 3 Spieleprojekte, 0 veröffentlicht

Ich wollte diesen Beitrag eigentlich schon vor ein paar Wochen schreiben. Aber ich glaube, ein Teil von mir hoffte, dass mindestens eines der drei Spiele fertig wäre, wenn ich mich endlich hinsetze.

Keines ist fertig.

Also stehen wir hier: 684 Commits über drei Projekte in sechs Monaten, und nichts, was man herunterladen, spielen oder einem Freund schicken kann. Wenn du schon einmal außerhalb eines Vollzeitjobs etwas wirklich Neues gelernt hast — etwas Schwieriges, etwas, worin du nicht ohnehin schon gut warst — kennst du dieses Gefühl wahrscheinlich sehr genau.

Ich schreibe das trotzdem, weil ich glaube, dass die Geschichte, warum nichts veröffentlicht wurde, nützlicher ist als eine polierte Ankündigung von etwas Fertigem.

Der Anfangskontext

18 Jahre lang habe ich in der Werbung gearbeitet. Es ist gute Arbeit, anspruchsvoll, und ich weiß, wie man sie macht. Ich habe Kampagnen veröffentlicht, Teams aufgebaut, Bücher geschrieben, auf Bühnen gesprochen. In dieser Welt weiß ich, wie "fertig" aussieht.

Dann entschied ich Ende 2025, dass ich Game Development lernen wollte. Nicht Game Marketing. Nicht Game Strategy. Spiele wirklich bauen — Code, Art, Systeme und das Gefühl, wenn sich eine Figur auf dem Bildschirm bewegt.

Ich hatte keine Erfahrung mit Game Engines. Ich hatte noch nie ein 3D-Modell geriggt. Ich wusste nicht, was eine State Machine im Kontext von Animation bedeutet. Ich code seit ein paar Jahren, vor allem Web Apps und AI Products, aber Spiele sind eine völlig andere Disziplin. (Bitte korrigiert mich, wenn ich hier irgendwo falschliege — ich lerne noch.)

Das Erste, was ich lernte: Ein Spiel zu veröffentlichen ist schwer. Das Zweite: Man kann sich aus einem Dokument nicht in einen guten Game Loop hineindenken.

Man muss es in Bewegung sehen. Man muss es spielen, oder es wenigstens in die Godot-Runtime bringen und beobachten, ob Figur, Kamera, Steuerung und Feedback tatsächlich ein Gefühl erzeugen. Und dann muss man bereit sein zu bauen, zu löschen, zu schneiden und neu zu bauen, bis etwas Interessantes auftaucht.

So lief es.

---

Projekt 1: Das AI Pet Sanctuary (288 Commits)

Dezember 2025 – Februar 2026

Das erste Projekt begann mit einer einfachen Idee: Was wäre, wenn man ein Haustier hätte, das auf dem Computer lebt und mit AI mit einem sprechen kann? Kein Chatbot mit Tieravatar — ein richtiges Pet mit Verhalten, Habitat und Persönlichkeit.

Ich baute eine Full-Stack-Webanwendung. React im Frontend, FastAPI im Backend, Supabase als Datenbank. Für Gespräche nutzte ich Gemini, für Video Cloudflare Stream.

Der ambitionierte Teil war das Animationssystem. Ich wollte 18 Pet-Typen in sechs breiten Kategorien — Hunde, Katzen, Vögel, kleine Tiere, Fische, Reptilien. Jedes sollte sich bewegen, blinzeln und lebendig wirken.

Ich begann mit Rive-Animationen. Für diesen Use Case funktionierten sie nicht. Also ersetzte ich sie durch CSS- und JavaScript-Animationen. Danach baute ich eine Pipeline mit Google Veo 3.1, um Animationscontent zu generieren — AI Video Generation für die Pet-Bewegungen. Das funktionierte, aber es war fragil. Die API fiel aus, Licht war inkonsistent, die Skalierung verschob sich zwischen den Generations. Ich verbrachte mehr Zeit damit, gegen die Generation-Pipeline zu kämpfen, als die eigentliche Pet Experience zu gestalten.

Ich baute auch ein Habitat-System mit immersiven Vollbildumgebungen — ein Raum namens "The Study", in dem das Pet lebte. Care Screens. Memory Screens. Gesprächsintegration. Ein komplettes "Quiet Luxury"-Redesign zur Halbzeit, weil die erste Version wie ein Prototype aussah. (Was sie auch war.)

Dann pivotierte ich.

288 Commits später entschied ich, dass die Web App die falsche Plattform war, und begann, eine native iOS-Version zu planen. Ich weiß immer noch nicht, ob das die richtige Entscheidung war oder nur Langeweile, die sich als Strategie verkleidete. Ein Teil von mir glaubt, dass ein Pet auf dem Telefon intimer ist als ein Pet im Browser. Ein anderer Teil glaubt, ich war einfach müde von React.

Aber wenn ich ehrlich bin, war der echte Grund, warum ich es nie veröffentlichte, einfacher: Es war langweilig. Ich hatte all das gebaut — Habitats, Animationssystem, Gesprächsintegration — und als ich mich wirklich hinsetzte und mit dem Pet interagierte, verlor ich nach zwei Minuten das Interesse. Es gab nichts, das meine Aufmerksamkeit halten konnte. Ich spiele seit der Secondary School, also vertraue ich dieser ersten Reaktion, auch wenn ich noch nicht immer weiß, wie ich sie beheben soll. Ich spiele immer noch Mobile Legends mit meiner Familie und komme meistens bis Mystic. Das ist kein Spiel, das man für passive Gemütlichkeit spielt — es verlangt Skill und Aufmerksamkeit. Dieses Pet Sanctuary verlangte keines von beidem.

Ich sagte mir immer wieder, das Problem sei die Plattform. Eine Web App könne nicht die immersive Erfahrung liefern, die ich wollte. Vielleicht wäre iOS anders. Aber tief drin wusste ich, dass React nicht das Problem war — das Design war es. Kein Plattformwechsel würde einen uninteressanten Game Loop plötzlich spannend machen.

Was schiefging

Wenn ich mir das Repo anschaue, glaube ich nicht, dass die richtige Lehre lautet: "288 Commits ohne Release sind schlecht." Wenn der Core Loop nicht engaging ist, bedeutet früheres Shipping nur, dass man etwas Langweiliges früher shippt.

Das eigentliche Problem war, dass ich immer wieder den Container wechselte, bevor ich den Loop bewiesen hatte. Das Projekt ging von Merge/Order-Mechaniken zu Pure Companion, zu immersiven Habitats, zu iOS. Jeder Pivot hatte einen Grund. Aber die Frage, die ich nicht klar genug beantwortete, war simpler: Würde ich das jeden Tag öffnen wollen?

Ich hätte das mit einem Pet, einem Raum, einem Gespräch und einer Care/Play-Interaktion validieren können. Stattdessen baute ich 18 Pet-Typen über 6 Tierkategorien und ein komplettes Habitat-System, bevor ich eine Runtime-Antwort auf die wichtigste Frage hatte: Ist dieses Pet interessant genug, um zurückzukommen?

AI-generierte Animation ist mächtig, aber fragil. Wenn sie funktioniert, ist sie unglaublich. Wenn sie nicht funktioniert, debuggt man Prompts und API-Fehler statt des Produkts. Man braucht früh eine Fallback-Pipeline, und ich hatte sie nicht.

Was ich gelernt habe

Die erste Aufgabe ist nicht, Scope zu reduzieren. Die erste Aufgabe ist, das Interessante zu finden. Manchmal heißt das, mehr zu bauen. Manchmal heißt es, gerade Gebautes wieder zu löschen. Der Fehler war nicht die Exploration. Der Fehler war, zu lange zu explorieren, ohne einen playable proof zu haben, der mir sagt, ob die Core Experience Leben hat.

---

Projekt 2: Der Fuchs, der zum Zwischenschritt wurde (35 Commits)

17. April – 12. Mai 2026

Nachdem das Pet Sanctuary Richtung iOS pivotierte, startete ich ein neues Projekt in Godot 4.6. Diesmal wollte ich ein Spiel von Grund auf in einer echten Game Engine bauen, nicht eine Web App, die so tut, als wäre sie ein Spiel.

Das erste Konzept: ein Spirit Fox Kit Sanctuary Sim. Ein kleiner Fuchs lebt in einem gemütlichen Raum, und man kümmert sich um ihn. Einfach, warm, begrenzt.

Ich setzte das Godot-Projekt auf. Ich versuchte, einen Fuchscharakter mit hidden tense silhouettes, schnelleren Twitch-Animationen und Micro-Signals für Stillness zu entwerfen.

Aber dieser Satz lässt den Prototype lesbarer klingen, als er war. Auf dem Bildschirm las sich der Fuchs nicht als Fuchs. Er war eine kleine Massekugel. Ich konnte keine brauchbare Form erkennen, geschweige denn den Rest des Raums darum herum beurteilen.

Ich baute einen Draft Room Loop mit GUT-Testabdeckung. Placeholder Audio. Hover Cues für Interactables. Room Scene Layout. Einen Cold-Start-Playtest-Harness, damit ich das Ding wirklich spielen konnte.

Und dann spielte ich es.

Die ehrliche Wahrheit ist visueller und weniger philosophisch: Der Fuchs scheiterte beim ersten Read. Der Room Prototype hatte einen mechanisch verifizierten Pfad, und das Repo hält sogar einen abbreviated solo gate pass für den Placeholder-Art-Build fest. Stillness, der Emergence Beat, Touch Distinction und das Room Problem waren für diese Phase akzeptabel.

Aber akzeptabel für einen kleinen authored beat ist nicht dasselbe wie visuell stark genug, um ein ganzes Spiel zu tragen. Dieses Projekt hing daran, dass der Fuchs die Experience trägt. Wenn ich seine Form, Haltung und Appeal nicht sehen konnte, hatte der Sanctuary Loop noch keine Chance.

Also schrieb ich am 20. April — nur drei Tage nach dem Start — eine vollständige Pivot Spec. Aus dem Fox Sanctuary Sim wurde etwas ganz anderes: ein Landscape Action-Adventure mit warmem Safehouse und feindlichem Gebiet zum Erkunden. Ich pausierte die fox-first Pläne und begann, eine neue Richtung zu entwerfen.

35 Commits. Ein validierter Beat. Ein Pivot. Nichts veröffentlicht.

Was schiefging

Das eigentliche Problem war, dass ich Animationssignale behandelte, als könnten sie eine unlesbare Grundform kompensieren. Das konnten sie nicht. Ein Twitch ist egal, wenn der Körper darunter keine Silhouette hat.

Der Pivot war kein Beweis, dass die erste Arbeit verschwendet war. Er machte sie zur Grundlage. Was mir immer noch fehlte, war Evidenz, dass die größere Hearthkeeper-Richtung funktionieren würde, oder dass ich ihren Kerncharakter lesbar genug machen kann, damit man sich für ihn interessiert.

Was ich gelernt habe

Frühes Playtesting zeigt, was ein Prototype tatsächlich beweist. Der Room Prototype bewies Tone, Pacing und einen Relationship Beat. Er bewies kein ganzes Spiel, und er zeigte sofort das Visual-Readability-Problem. Das ist nützliche Information, aber sie zeigt auf einen anderen nächsten Schritt: den Character Read lösen und den kleinsten Safehouse -> Run -> Return Loop bauen, bevor ich den Fuchs wieder poliere.

Game 1 lehrte mich, dass ein technisch vollständiger Loop trotzdem langweilig sein kann. Game 2 lehrte mich, dass ein dokumentiertes und getestetes Charakterkonzept visuell in Sekunden scheitern kann. Diese beiden Fehlschläge sind ein Grund, warum Game 3 mehr echten Fortschritt macht: Ich achte viel stärker auf Readability, Motion, Weapon Feel und darauf, ob der playable slice auf dem Bildschirm funktioniert.

Aus Evidenz zu pivotieren ist etwas anderes als Driften. Der Fuchs las sich in der Runtime nicht, also war der Richtungswechsel nicht automatisch ein Disziplinproblem. Was ich verbessern muss, ist der Feedback Loop: die riskanteste visuelle oder spielerische Frage schneller auf den Bildschirm bringen und dann mit Evidenz entscheiden, statt im Concept Mode zu bleiben.

---

Projekt 3: Das, bei dem die Pipeline anfing zu funktionieren (361 Commits)

21. April – 13. Mai 2026

Das ist das Projekt, an dem ich noch arbeite. Es ist auch das Projekt, in dem sich die Learnings aus den ersten beiden Projekten endlich zu verstärken begannen.

Es ist ein Mech-Tactics-Spiel. Man steuert eine Squad von Mechs im Combat, und nach jedem Battle analysiert ein LLM, was passiert ist, und gibt ein Debrief. Stell dir Post-Match-Analyse vor, aber geschrieben von einer AI, die Zugriff auf den gesamten Game State hat.

Das Repo hat drei Tracks, aber sie sind nicht mehr gleich wichtig:

Track A — Das LLM Debrief System: Das war der frühe AI-Validation-Track. Er half mir, structured debriefs zu testen, ist aber nicht mehr der Hauptproduktpfad.

Track B — Der 2D Phone Prototype: Hier fand ich zum ersten Mal eine praktikable Pipeline für eine relativ immersive 2D Player Experience. Die tatsächliche Godot-Runtime hat einen Lane-Match-Combat-Loop, Touch Joystick, Shop/Modules, Hero XP, Ability Cooldowns, phone-readable VFX motifs, Enemy Punish Zones, ein neutrales Relay Objective, HUD Feedback und iOS Export/Testing Flow. Auch die Art Pipeline begann zu funktionieren: Nano Banana 2 (Gemini 3.1 Flash Image) erzeugte brauchbare erste Hero- und Character-Images, dann verwandelten ein MCP-basierter Pixel-Cleanup-Workflow und Aseprite kuratierte Kandidaten in saubere Sprites, Animationsframes und Godot-ready Sheets. Es ist kein fertiges Spiel, und Phone Acceptance steht noch aus, aber es ist viel näher an "das fühlt sich wie ein Spiel an" als die ersten beiden Projekte.

Track C — Campaign and 3D Path: Das ist die aktuelle Produktrichtung. Sie behält die nützlichen Track-B-Learnings, fügt einen Campaign Memory Loop hinzu und bewegt Production Combat Richtung 3D/2.5D. Das ist ein deutlich härteres Problem als die 2D-Pipeline. In 2D kann ich Readability über Sprite Sheets, HUD Tuning, procedural VFX und Phone Captures kontrollieren. In 3D berührt jede Entscheidung Modeling, Rigging, Animation, Kamera, Lighting, GLB Export, Weapon Sockets, Hit Anchors, Action Timing und Runtime Performance.

Ich integrierte außerdem Blender für Custom Rigging Work, brachte Rokoko Mocap Data für Locomotion ein und baute den Hero-Mech-Charakter mit Full Rig, Animation Tree und Weapon Socket Integration.

361 Commits in drei Wochen. Eine echte 2D-Pipeline. Ein viel schwierigeres 3D-Experiment. Immer noch Prototype Territory.

Was schiefging

Hier ist der Punkt, den ich zugeben muss: Die 2D-Pipeline beginnt zu funktionieren, aber die 3D-Pipeline kann das ganze Projekt verschlucken, wenn ich sie lasse.

Für Track B war Pipeline-Arbeit kein Fake Progress. Der Nano Banana 2 -> Aseprite Workflow, Touch Controls, HUD, lesbare Ability Motifs, Module Feedback, Phone Captures und der Export Loop machten das Produkt spielbarer. Diese Arbeit zeigte mir, was ein Spieler von Moment zu Moment sehen und fühlen muss.

Das Risiko ist jetzt anders. In Track C braucht 3D viel Pipeline, bevor es sich überhaupt nach etwas anfühlt: Model Import, Rig Quality, Animation Names, Weapon Attachment, Muzzle Position, Hit Center, Camera Angle, Lighting, Movement, Jump Timing, Attack Timing, VFX und Runtime Inspection. Das sind keine optionalen Details. Wenn die Figur nicht lesbar ist, scheitert die ganze Szene in Sekunden.

Aber der playable encounter muss weiter führen. Sonst kann ich Wochen damit verbringen, Weapon Fit, Jump Compression, Left-Hand IK und Mocap Cleanup des Hero Mechs zu verbessern, ohne die simple Spielerfrage zu beantworten: Macht es Spaß, das zu steuern?

Was ich gelernt habe

Pipeline-Arbeit ist nur dann nützlich, wenn sie dem playable slice dient. Track B zeigte mir, dass die richtige Pipeline eine immersivere 2D Experience schaffen kann. Track C zeigt mir, dass 3D die Kosten jeder Verbesserung erhöht. Ich muss das Acceptance Gate konkret halten: Kann der Spieler den Hero Mech lesen, bewegen, zielen, feuern, den Hit verstehen und es wieder tun wollen?

Tracks brauchen Gates. Track A hat seine Aufgabe erfüllt. Track B produzierte wiederverwendbare Learnings zu 2D Game Feel und Presentation. Track C ist die aktuelle Wette. Das Problem ist nicht, dass ich mehrere Pfade erkundet habe. Das Problem ist, sie ohne klare Runtime-Frage und klare Entscheidungsregel wieder zu öffnen.

3D Game Development ist ein massiver Skill Gap. Rigging, Animation, Mocap Data, Asset Budgets, Weapon Sockets, Camera Framing und readable motion sind Disziplinen, in denen ich null professionelle Erfahrung habe. Ich lerne sie, während ich gleichzeitig Godot, Game Design und Campaign Architecture lerne. Die Lernkurve ist nicht steil — sie ist vertikal. Ich glaube, das hat mich am meisten überrascht. In Web Development kann ich an einem Tag etwas Funktionales bauen. In 3D Game Dev verbrachte ich einen ganzen Abend damit, den Arm einer Figur richtig biegen zu lassen. (Das ist so ein Satz, den ich vor sechs Monaten nicht verstanden hätte.)

---

Was diese drei Projekte gemeinsam haben

Wenn ich ehrlich mit mir bin — und dieser Beitrag funktioniert nur, wenn ich das bin — ist das Muster nicht "Scope Creep". Das wäre zu einfach, und in diesem Fall glaube ich, dass es falsch ist.

Ich glaube nicht, dass Spiele wie Business Decks funktionieren — zumindest haben mich diese drei Projekte das gelehrt. Man weiß nicht, ob eine Idee funktioniert, weil die Prämisse gut klingt. Man weiß es, wenn man sie spielen kann, oder sie wenigstens in der Engine laufen sieht und spürt, ob Figur, Kamera, Interaktion und Feedback irgendetwas tun.

1. Die Runtime ist die Wahrheit

Das Pet Sanctuary klang gut, bis ich mit dem Pet interagierte und mich langweilte. Der Fuchs klang gut, bis ich ihn in Godot sah und die Form nicht lesen konnte. Track B begann zu funktionieren, weil der Loop in eine phone-like Runtime kam: Touch Controls, HUD, VFX, Shop, XP, lesbare Motifs und Capture Feedback.

Das ist das echte Muster. Die nützliche Wahrheit kam erst, als die Idee sichtbar und spielbar wurde.

2. Exploration ist notwendig, aber sie braucht Evidenz

Ich glaube nicht, dass die richtige Lehre "hör auf, Dinge hinzuzufügen" ist. Game Development braucht Exploration. Man baut, probiert, löscht, schneidet, baut neu und probiert wieder, weil man das Interessante sucht.

Der Teil, der Disziplin braucht, ist nicht die Menge an Arbeit. Es ist der Evidence Loop. Jedes Stück Arbeit sollte eine Frage beantworten: Macht das Spiel dadurch lesbarer, engaginger, kontrollierbarer, replay-würdiger?

3. Pipelines sind gut, wenn sie das Spiel spielbarer machen

Der Nano Banana 2 -> MCP Cleanup -> Aseprite Workflow war keine Ablenkung. Er half mir, bessere 2D-Charaktere und Animation ins Spiel zu bringen. Die HUD- und VFX-Arbeit in Track B war ebenfalls kein Fake Progress. Sie machte die Runtime klarer.

Das Risiko entsteht, wenn die Pipeline keine spielerbezogene Frage mehr beantwortet. In Track C ist 3D Tooling notwendig, aber es muss immer zu einer Sache zurückkehren: Kann der Spieler den Hero Mech lesen, bewegen, die Waffe abfeuern, den Hit verstehen und es wieder tun wollen?

4. Die Lücke ist nicht Coding Skill. Sie ist playable judgment.

Ich kann eine Full-Stack-Anwendung mit Supabase, FastAPI und React bauen. Ich kann ein 3D-Modell riggen, GUT Tests schreiben und custom Debugging Tools bauen. Was ich noch lerne, ist zu beurteilen, ob etwas tatsächlich als Spiel interessant ist. Track B brachte mich in 2D näher heran. Track C zeigt mir, wie viel schwieriger das wird, wenn Motion, Camera, Lighting, Weapons und Animation zusammen funktionieren müssen.

Ich glaube, das ist die wichtigste Erkenntnis. Code ist der Teil, in dem ich gut bin. Der schwierige Teil ist zu entscheiden, was das Spiel eigentlich ist, es interessant zu machen und dann die Disziplin zu haben, immer wieder zur Runtime-Evidenz zurückzukehren, bis es wert ist, veröffentlicht zu werden.

---

Was ich insgesamt gelernt habe

Wenn ich sechs Monate in etwas Nützliches destillieren soll — für mich oder für jemanden, der in einer ähnlichen Lage ist — dann weiß ich heute, glaube ich, Folgendes, was ich im Dezember nicht wusste:

1. Die erste Version sollte die riskanteste Frage in der Runtime beantworten. Mein Pet Sanctuary brauchte eine Pet-Interaktion, die mich zurückkommen lässt. Mein Fuchs-Spiel brauchte eine lesbare Silhouette in einem leeren Raum, bevor ich über Micro-Signals nachdachte. Mein Mech-Spiel kam durch Track B näher, weil ich den Loop auf dem Bildschirm sehen und fühlen konnte.

2. Playtesting ist nicht optional, und Runtime Review zählt. In dem Moment, in dem ich den Fuchs als formlose Masse sah, wusste ich, dass das Projekt noch nicht funktionierte. Das waren die wertvollsten 30 Minuten des gesamten Projekts. Diese visuelle Wahrheit hätte ich früher erreichen sollen.

3. Learning ist ein valides Ergebnis, auch wenn es nicht das geplante war. Ich wollte Spiele bauen. Ich habe keine Spiele veröffentlicht. Aber ich lernte Godot, LLM Prompt Engineering, Nano Banana 2 für Character Ideation, Aseprite Animation Cleanup, 2D Phone Readability, HUD- und VFX-Feedback, Animation Pipelines, 3D Rigging, Mocap Data, Game Feel, Camera Systems, Visual Readability und den Unterschied zwischen Tools bauen und Products bauen. Das ist nicht nichts. Deshalb ist Game 3 auch besser als Game 1 und Game 2, selbst wenn es noch nicht veröffentlicht ist.

4. Ich muss noch eine ehrliche Finish Line definieren. Ein Teil von mir will dieses Projekt bis zum Ende pushen, damit ich sagen kann, ich habe ein Spiel veröffentlicht. Ein anderer Teil glaubt, das Learning war das Produkt und ich sollte das akzeptieren. Beides sind ehrliche Antworten. Ich glaube, die Wahrheit liegt irgendwo dazwischen: einen fokussierten Slice veröffentlichen, der respektiert, was ich gelernt habe, statt wieder bei null zu starten.

Was als Nächstes kommt

Ich arbeite weiter am Mech-Tactics-Projekt. Das LLM-Debrief-Konzept ist interessant, und ich glaube, dass in AI-powered Post-Match Analysis für ein Tactics Game etwas wirklich Neues steckt.

Aber ich versuche, meinen Ansatz zu ändern: Runtime Proof zuerst, Polish später, und erst etwas veröffentlichen, wenn der playable slice einen Grund hat zu existieren. Die ersten beiden Projekte waren nicht verschwendet. Sie haben verändert, worauf ich in Game 3 schaue: Liest sich die Figur? Fühlt sich die Motion gut an? Fühlt sich die Waffe richtig an? Kann jemand den Encounter verstehen, ohne dass ich die Architektur erkläre?

Wenn ich heute ein neues Spiel anfangen würde, würde ich nicht mit einem großen Architecture Plan beginnen. Ich würde mit dem schnellsten Runtime Proof starten, der die Frage beantwortet, die mir wirklich wichtig ist. Für Game 3 muss dieselbe Disziplin jetzt innerhalb des Projekts gelten: eine Figur, eine Waffe, ein Encounter, ein klares Acceptance Test.

Ich weiß noch nicht, ob ich eines dieser Projekte bis zur Fertigstellung pushen werde oder akzeptiere, dass das Learning das Produkt war. Ich könnte mich beim Timing irren, aber ich glaube, das Muster ist wichtiger als ein einzelnes Projekt.

Eine Frage an dich

Ich will das wirklich fragen, nicht rhetorisch: Warst du schon einmal hier? (Ich vermute, mehr Builder kennen diesen Ort, als wir normalerweise zugeben.)

Hast du Monate damit verbracht, etwas zu bauen, das nie veröffentlicht wurde? Hast du es am Ende fertiggestellt oder bist du weggegangen? Und wenn du weggegangen bist — war es die richtige Entscheidung, oder denkst du noch daran?

Ich habe in meiner Karriere Dinge veröffentlicht. Kampagnen, Plattformen, Produkte. Aber das waren Domains, in denen ich 18 Jahre Erfahrung hatte. Game Development ist neu, und die Lücke zwischen "ich kann das technisch bauen" und "das ist ein gutes Spiel" ist viel größer, als ich erwartet hatte.

Wenn du diese Lücke überwunden hast, würde ich gern hören, was dich davon abgehalten hat, wieder wegzupivotieren. Schreib mir gern auf LinkedIn oder direkt — ich bin wirklich neugierig.

---

Das war es von mir. Ich würde sehr gern eure Gedanken hören — besonders, wenn ihr etwas Ähnliches erlebt habt. Meldet euch gern auf LinkedIn oder schreibt mir direkt.

Viele Grüße,

Chandler