6か月、3つのゲームプロジェクト、リリース0本
full-time jobを続けながら、6か月間 game developer になろうとしていました。 3つのプロジェクトを作り、684 commitsを書き、リリースしたゲームは0本です。 何が起きたのか、何を学んだのか、そしてなぜ何もリリースできなかったのかを書きます。
この投稿は数週間前に書くつもりでした。でも、座って書く頃には、作っていた3つのゲームのうち少なくとも1つは完成しているだろうと、どこかで期待していたのだと思います。
どれも完成していません。
というわけで、今の状況はこうです。6か月で3つのプロジェクト、684 commits。そして、downloadして遊んだり、友人に送ったりできるものは何もありません。full-time jobの外で、本当に新しいこと、しかも自分がまだ得意ではない難しいことを学んだことがあるなら、この感覚はたぶんよく分かると思います。
それでも書くのは、何もリリースできなかった理由の方が、完成したもののきれいな発表よりも役に立つと思うからです。
最初の文脈
18年間、私は広告業界で働いてきました。良い仕事ですし、難しくもあります。そして私はその仕事のやり方を知っています。campaignを出し、teamを作り、本を書き、stageにも立ってきました。その世界では、「done」がどんな形をしているか分かります。
それから2025年の終わりに、ゲーム開発を学びたいと思いました。ゲームマーケティングでも、ゲーム戦略でもなく、本当にゲームを作ることです。コード、アート、システム、そして画面上でキャラクターが動く時の感覚まで含めて。
ゲームエンジンの経験はありませんでした。3Dモデルをリギングしたこともありません。アニメーションの文脈でステートマシンが何を意味するのかも知りませんでした。ここ数年はコードを書いていて、主にWebアプリやAIプロダクトを作ってきましたが、ゲームはまったく別の分野です。（このあたりで間違っていたら、ぜひ指摘してください。まだ学んでいる途中です。）
最初に学んだことは、ゲームをリリースするのは難しいということです。次に学んだことは、ドキュメントだけで良いゲームループにたどり着くことはできないということでした。
動いているところを見る必要があります。実際に遊ぶ必要があります。少なくともGodotのランタイムに入れて、キャラクター、カメラ、操作、フィードバックが本当に何かしらの感覚を作っているのかを見る必要があります。そして、面白いものが出てくるまで、作り、消し、削り、また作り直す覚悟が必要です。
何が起きたのか、順番に書きます。
Project 1: The AI Pet Sanctuary (288 commits)
2025年12月 – 2026年2月
最初のプロジェクトは、シンプルなアイデアから始まりました。AIを使って会話できるpetが、自分のcomputerの中に住んでいたらどうだろう、というものです。pet avatar付きのchatbotではありません。behaviors、habitat、personalityを持つ、実際のpetのような存在です。
私はfull-stack web applicationを作りました。frontendはReact、backendはFastAPI、databaseはSupabase。会話にはGemini、videoにはCloudflare Streamを使いました。
ambitiousだったのはanimation systemです。dogs、cats、birds、small animals、fish、reptilesという6つの大きなcategoryで、18種類のpetを作りたかったのです。それぞれが動き、まばたきし、生きているように感じられる必要がありました。
最初はRive animationsを使いました。このuse caseには合いませんでした。そこでCSSとJavaScriptのpet animationsに置き換えました。次に、Google Veo 3.1を使ってanimation contentを生成するpipelineを作りました。pet movementのためのAI video generationです。動きはしましたが、とてもbrittleでした。APIは失敗することがあり、lightingは一貫せず、generationごとにscaleが変わりました。実際のpet experienceをdesignするより、generation pipelineと格闘している時間の方が長くなりました。
habitat systemも作りました。full-screen immersive environmentsで、petが住む部屋は"The Study"と呼びました。Care screens。Memory screens。Conversation integration。途中で"Quiet Luxury"のfull redesignまでしました。最初のversionがprototypeに見えたからです。（実際prototypeでした。）
そしてpivotしました。
288 commits後、私はweb appは間違ったplatformだと判断し、native iOS versionの計画を始めました。 それが正しい判断だったのか、それともstrategyの服を着たboredomだったのか、今でも分かりません。petはbrowserよりphoneの方が親密に感じられる、と信じている部分もあります。一方で、単にReactに疲れていただけではないか、とも思います。
ただ、正直に言うと、リリースしなかった本当の理由はもっと単純でした。退屈だったのです。 habitat、animation system、conversation integrationをすべて作ったあと、実際に座ってpetとinteractionしてみると、2分で興味を失いました。注意を引き止めるほどcompellingなものがありませんでした。私はsecondary schoolの頃からgamesを遊んでいるので、この最初の反応は信じています。まだ直し方がいつも分かるわけではありませんが。今でも家族とMobile Legendsを遊んでいて、たいていMysticまで上がります。あれはpassive comfortのために遊ぶgameではありません。skillとattentionを要求します。このpet sanctuaryは、そのどちらも要求しませんでした。
私はplatformが問題だと言い続けていました。web appでは自分が望むimmersive experienceを出せない。iOSなら違うかもしれない。でも心の奥では、問題はReactではなくdesignだと分かっていました。platformを変えても、面白くないgame loopが急に面白くなるわけではありません。
何がうまくいかなかったのか
リポジトリを見返すと、正しい学びは「288 commitsでリリースなしは悪い」ではないと思います。コアループに引きがなければ、早く出しても、退屈なものを早く出すだけです。
本当の問題は、ループを証明する前に入れ物を変え続けたことでした。プロジェクトはmerge/order mechanicsからpure companionへ、没入感のあるhabitatへ、そしてiOSへ移りました。それぞれのピボットには理由がありました。でも私が十分にはっきり答えていなかった問いはもっと単純でした。これは毎日開きたくなるものか？
それは、1匹のペット、1つの部屋、1つの会話、1つの世話や遊びのインタラクションで検証できたはずです。代わりに私は、一番大事な問いへのランタイムでの答えを得る前に、6つの動物カテゴリにわたる18種類のペットと、完全なhabitat systemを作ってしまいました。このペットは、戻ってきたくなるほど面白いのか？
AI生成アニメーションは強力ですが、壊れやすいです。 うまくいくと本当にすごいです。うまくいかないと、プロダクトではなくプロンプトやAPIエラーをデバッグすることになります。代替パイプラインが必要でしたが、私は十分早く作りませんでした。
学んだこと
最初の仕事はスコープを切ることではありません。最初の仕事は、面白い部分を見つけることです。 それは時に、もっと作ることを意味します。時に、作ったばかりのものを消すことを意味します。間違いは探索そのものではありません。コア体験に生命があるかを教えてくれる、遊べる証拠なしに、長く探索しすぎたことです。
Project 2: 足場になったfox (35 commits)
2026年4月17日 – 5月12日
pet sanctuaryがiOSにpivotしたあと、Godot 4.6で新しいprojectを始めました。今度は、gameのふりをしたweb appではなく、本物のgame engineでゼロからgameを作りたかったのです。
最初のconceptはSpirit Fox Kit Sanctuary Simでした。小さなfoxがcozyなroomに住み、それをcareする。simpleで、warmで、containedなものです。
Godot projectをsetupしました。hidden tense silhouettes、より速いtwitch animations、stillnessのためのmicro-signalsを持つfox characterをdesignしようとしました。
でもこの文章は、prototypeを実際よりもlegibleに聞こえさせます。screen上では、foxはfoxとして読めませんでした。小さなmassの塊でした。usable shapeが見えず、その周りのroom visualsを判断するどころではありませんでした。
GUT test coverage付きのdraft room loopを作りました。Placeholder audio。Interactablesのhover cues。Room scene layout。実際に遊べるようにするcold-start playtest harness。
そして遊びました。
正直なところ、これは哲学的な問題というよりvisualの問題でした。foxはfirst readで失敗しました。room prototypeにはmechanically verified pathがあり、repoにもplaceholder-art buildのabbreviated solo gate passが記録されています。stillness、emergence beat、touch distinction、room problemは、そのstageではacceptableでした。
でも、小さなauthored beatとしてacceptableであることと、full gameを支えるほどvisually strongであることは違います。このprojectは、foxがexperienceを支えることに依存していました。そのshape、posture、appealが見えないなら、sanctuary loopにはまだ chance がありません。
そこで4月20日、開始からわずか3日後に、full pivot specを書きました。fox sanctuary simはまったく別のものになりました。warmなsafehouseと、探索するhostile territoryを持つlandscape action-adventureです。fox-first plansをpauseし、新しい方向性をdesignし始めました。
35 commits。1つのvalidated beat。1つのpivot。リリースなし。
何がうまくいかなかったのか
本当の問題は、animation signalsがunreadableなbase shapeを補えるかのように扱っていたことです。補えません。下にあるbodyにsilhouetteがなければ、twitchは意味を持ちません。
pivotは、最初のworkが無駄だった証拠ではありません。それは最初のworkをfoundationにしました。まだなかったのは、より大きなHearthkeeper directionが機能するというevidence、またはcore characterをcareしたくなるほどreadableにできるというevidenceです。
学んだこと
早いplaytestingは、prototypeが本当は何を証明しているのかを見せてくれます。 room prototypeはtone、pacing、relationship beatを証明しました。full gameは証明していません。そしてvisual readabilityの問題をすぐに露出させました。これは有用な情報ですが、次のstepは別です。foxをまたpolishする前に、character readを解き、最小のsafehouse -> run -> return loopを作ることです。
Game 1は、technically completeなloopでも退屈になり得ると教えてくれました。Game 2は、documentedでtestedなcharacter conceptでも、visualでは数秒で失敗し得ると教えてくれました。この2つの失敗があるから、Game 3ではよりrealなprogressが出ています。readability、motion、weapon feel、playable sliceがscreen上で機能しているかに、ずっと注意を払うようになりました。
evidenceからpivotすることは、driftingとは違います。 foxはruntimeで読めませんでした。だから方向を変えることは、自動的にdisciplineの失敗ではありません。改善すべきなのはfeedback loopです。最もriskyなvisualやgameplay questionをもっと早くscreenに出し、concept modeに残るのではなくevidenceで決めることです。
Project 3: Pipelineが動き始めたproject (361 commits)
2026年4月21日 – 5月13日
これは今も作業しているprojectです。そして、最初の2つのprojectからの学びがようやくcompoundし始めたprojectでもあります。
mech tactics gameです。playerはcombatでmech squadをcontrolし、battle後にはLLMが起きたことをanalysisしてdebriefを返します。post-match analysisのようなものですが、game state全体にaccessできるAIが書くものです。
repoには3つのtracksがありますが、もう同じ重みではありません。
Track A — The LLM Debrief System: 初期のAI validation trackでした。structured debriefsをtestするのに役立ちましたが、もうmain product pathではありません。
Track B — The 2D Phone Prototype: ここで初めて、比較的没入感のある2Dプレイヤー体験のための、実際に回るパイプラインを見つけました。実際のGodotランタイムには、lane-match combat loop、タッチジョイスティック、shop/modules、hero XP、ability cooldowns、スマホ画面でも読めるVFX motifs、enemy punish zones、neutral relay objective、HUDフィードバック、iOS export/testing flowがあります。アートのパイプラインも動き始めました。Nano Banana 2 (Gemini 3.1 Flash Image)が使える初期のヒーロー画像やキャラクター画像を生成し、MCPベースのピクセル cleanup workflowとAsepriteで、選んだ候補をcleaned sprites、animation frames、Godot-ready sheetsに変換しました。完成したゲームではありませんし、スマホでの受け入れ確認もまだです。でも最初の2つのプロジェクトより、「これはゲームっぽい」と感じられるところにかなり近づいています。
Track C — The Campaign and 3D Path: これが現在のプロダクト方向です。Track Bの有用な学びを残し、campaign memory loopを追加し、production combatを3D/2.5Dに移しています。これは2Dパイプラインよりずっと難しい問題です。2Dでは、sprite sheets、HUD tuning、procedural VFX、phone capturesで視認性をコントロールできます。3Dでは、あらゆる判断がモデリング、リギング、アニメーション、カメラ、ライティング、GLB export、weapon sockets、hit anchors、action timing、runtime performanceに触れます。
さらに、カスタムリギングのためにBlenderを統合し、locomotionのためにRokokoのmocap dataを持ち込み、full rig、animation tree、weapon socket integrationを持つhero mech characterを作りました。
3週間で361 commits。本物の2Dパイプライン。ずっと難しい3D実験。まだプロトタイプ段階です。
何がうまくいかなかったのか
ここは認める必要があります。2D pipelineは動き始めています。でも3D pipelineは、放っておくとproject全体を飲み込みます。
Track Bでは、パイプライン作業は見せかけの進捗ではありませんでした。Nano Banana 2 -> Aseprite workflow、タッチ操作、HUD、読み取りやすいability motifs、module feedback、phone captures、export loopは、プロダクトをより遊べるものにしていました。その作業は、プレイヤーが瞬間ごとに何を見て、何を感じる必要があるのかを教えてくれました。
今のリスクは違います。Track Cでは、3Dが何かとして感じられる前に、多くのパイプラインが必要です。model import、rig quality、animation names、weapon attachment、muzzle position、hit center、camera angle、lighting、movement、jump timing、attack timing、VFX、runtime inspection。これらは任意の細部ではありません。キャラクターが読めなければ、シーン全体が数秒で失敗します。
でも、遊べるエンカウンターが先導し続ける必要があります。そうでなければ、hero mechのweapon fit、jump compression、left-hand IK、mocap cleanupを何週間も改善しながら、プレイヤーにとって一番単純な問いに答えないままになります。操作して楽しいのか？
学んだこと
パイプライン作業は、遊べるスライスに仕え続ける時だけ有用です。 Track Bは、正しいパイプラインがより没入感のある2D体験を作れると教えてくれました。Track Cは、3Dがあらゆる改善のコストを上げると教えています。受け入れ基準は具体的に保つ必要があります。プレイヤーはhero mechを読めるか、動かせるか、狙えるか、撃てるか、命中を理解できるか、もう一度やりたいと思うか。
Trackにはゲートが必要です。 Track Aは役割を終えました。Track Bは再利用できる2Dのゲーム感覚と見せ方の学びを残しました。Track Cが現在の賭けです。問題は複数の道を探索したことではありません。明確なランタイム上の問いと判断基準なしに、それらを再び開くことです。
3Dゲーム開発は巨大なスキルギャップです。 リギング、アニメーション、mocap data、asset budgets、weapon sockets、camera framing、読み取りやすい動きは、私に専門経験がまったくない分野です。それらを学びながら、同時にGodot、ゲームデザイン、campaign architectureも学んでいます。学習曲線は急ではありません。垂直です。ここが一番驚いた部分だと思います。Web開発なら、1日で動くものを作れます。3D game devでは、キャラクターの腕を正しく曲げるだけで一晩使いました。（6か月前なら、この文の意味は分からなかったと思います。）
3つのプロジェクトに共通していたこと
自分に正直になるなら — そしてこの投稿は正直でなければ成立しません — パターンは"scope creep"ではありません。それは簡単すぎる説明で、この場合は間違っていると思います。
ゲームはbusiness decksのようには動かないと思います。少なくとも、この3つのプロジェクトはそう教えてくれました。前提が良く聞こえるからといって、アイデアが機能するとは分かりません。遊べる時、あるいは少なくともエンジン上で走っているのを見て、キャラクター、カメラ、インタラクション、フィードバックが何かをしていると感じられる時に分かります。
1. Runtimeが真実です
pet sanctuaryは、ペットとやり取りして退屈するまでは良さそうに聞こえました。foxは、Godotで見て形が読めないと分かるまでは良さそうに聞こえました。Track Bは、ループがスマホに近いランタイムに入ったことで動き始めました。タッチ操作、HUD、VFX、shop、XP、読み取りやすいmotifs、capture feedback。
これが本当のパターンです。有用な真実は、アイデアが見えて、遊べる形になった時にだけ来ました。
2. Explorationは必要ですが、evidenceが必要です
正しい学びは「ものを追加するのをやめる」ではないと思います。ゲーム開発には探索が必要です。作り、試し、消し、削り、作り直し、また試します。面白い部分を探しているからです。
規律が必要なのは、作業量ではありません。証拠のループです。各作業は問いに答えるべきです。これはゲームをより読み取りやすくするのか。より引き込むのか。より操作しやすくするのか。もう一度遊びたくなるものにするのか。
3. パイプラインは、ゲームをより遊べるものにする時に良いものです
Nano Banana 2 -> MCP cleanup -> Aseprite workflowは寄り道ではありませんでした。より良い2Dキャラクターとアニメーションをゲームに入れる助けになりました。Track BのHUDとVFX作業も見せかけの進捗ではありません。ランタイムをより明確にしました。
リスクは、パイプラインがプレイヤー向けの問いに答えなくなった時に生まれます。Track Cでは3D toolingは必要です。でも必ず一つのことに戻る必要があります。プレイヤーはhero mechを読めるか、動かせるか、武器を撃てるか、命中を理解できるか、もう一度やりたいと思うか。
4. ギャップはコーディング力ではありません。遊べるかを判断する力です。
私はSupabase、FastAPI、Reactでfull-stack applicationを作れます。3D modelをリギングし、GUT testsを書き、custom debugging toolsを作れます。まだ学んでいるのは、何かがゲームとして本当に面白いかを判断することです。Track Bは2Dで私を近づけてくれました。Track Cは、モーション、カメラ、ライティング、武器、アニメーションがすべて一緒に機能しなければならない時、それがどれほど難しいかを見せています。
これが最も重要な学びだと思います。コードは得意な部分です。難しいのは、このゲームが本当は何なのかを決め、面白くし、そしてリリースする価値が出るまでランタイム上の証拠に戻り続ける規律を持つことです。
全体として学んだこと
6か月を、自分や同じような場所にいる人にとって有用なものにまとめるとしたら、12月には分かっていなかったけれど今は分かると思うことはこれです。
-
最初のバージョンは、ランタイムで最もリスクの高い問いに答えるべきです。 pet sanctuaryには、私が戻ってきたくなる1つのペットインタラクションが必要でした。fox gameには、micro-signalsを考える前に、何もない部屋で読み取れるシルエットが必要でした。mech gameは、Track Bを通じて近づきました。画面上でループを見て、感じられたからです。
-
プレイテストは任意ではありません。ランタイムレビューも含まれます。 foxが形のない塊に見えた瞬間、このプロジェクトはまだ機能していないと分かりました。あの30分はプロジェクト全体で最も価値がありました。その視覚的な真実にもっと早く到達すべきでした。
-
学びは、予定していた成果でなくても有効な成果です。 私はゲームを作るつもりでした。ゲームはリリースしていません。でもGodot、LLM prompt engineering、character ideationのためのNano Banana 2、Aseprite animation cleanup、2D phone readability、HUD and VFX feedback、animation pipelines、3D rigging、mocap data、game feel、camera systems、visual readability、そしてtoolsを作ることとproductsを作ることの違いを学びました。これは何もないわけではありません。だからGame 3は、まだリリースしていなくても、Game 1とGame 2より良くなっています。
-
まだ正直なゴールラインを定義する必要があります。 一部の自分は、このプロジェクトを完成まで押し切って、ゲームをリリースしたと言いたがっています。別の一部は、学びこそがプロダクトだったのだから受け入れるべきだと思っています。どちらも正直な答えです。真実はその中間にあると思います。ゼロからやり直すのではなく、学んだことを尊重した絞り込んだスライスを出すことです。
次にやること
私はまだmech tactics projectに取り組んでいます。LLM debrief conceptは面白いですし、tactics game向けのAI-powered post-match analysisには、本当に新しいものがあると思います。
ただ、進め方を変えようとしています。ランタイムでの証明を先に、磨き込みは後に。遊べるスライスに存在する理由ができてからだけリリースする。最初の2つのプロジェクトは無駄ではありませんでした。それらはGame 3で見るものを変えました。キャラクターは読めるか。モーションの感触は良いか。武器の感触は正しいか。architectureを説明しなくても、誰かがエンカウンターを理解できるか。
もし今日新しいゲームを始めるなら、大きなarchitecture planからは始めません。自分が本当に気にしている問いに答えられる、最速のランタイム証明から始めます。Game 3では今、その同じ規律をプロジェクト内でやる必要があります。1人のキャラクター、1つの武器、1つのエンカウンター、1つの明確な受け入れテスト。
このうちどれかを完成まで押し切るのか、それとも学びがプロダクトだったと受け入れるのか、まだ分かりません。timelineについては間違っているかもしれません。でも、どの単独プロジェクトよりもパターンの方が重要だと思います。
あなたへの質問
これは本当に聞きたいことで、rhetorical questionではありません。あなたもここに来たことがありますか？（普段認めているより、多くのbuildersが経験しているのではないかと思います。）
何かを何か月も作り続けて、結局shipしなかったことはありますか？最終的に完成させましたか。それとも離れましたか。もし離れたなら、それは正しい判断でしたか。それとも今でも考えますか。
私はcareerの中で、いろいろなものをshipしてきました。campaigns、platforms、products。でもそれらは、18年のexperienceがあるdomainでした。game developmentは新しく、「technicallyに作れる」と「良いgameである」の間のgapは、思っていたよりずっと大きいです。
もしそのgapを越えたことがあるなら、何があなたをまたpivot awayしないようにしたのか、ぜひ聞きたいです。LinkedInでreplyしても、直接noteを送ってもらっても大丈夫です。本当に知りたいです。
今回はここまでです。同じような経験がある方は、ぜひ考えを聞かせてください。LinkedInでも、直接のメッセージでも大丈夫です。
それでは、
Chandler
