「ゲームって、AIを使えば自分でも作れるのかな？」
そんな軽い疑問から始まったのが、この連載です。
私は普段、機械設計の仕事をしています。
ゲーム制作の経験はほぼありません。
Unityも分からない。
プログラミングもできない。
それでも、ChatGPTに相談しながらゲームの仕様を考え、
Codexにコードを書いてもらえば、Steamで販売できるゲームまで作れるのでは？
と思い、実際に挑戦してみることにしました。
作っているのは、工場の生産ラインを設計する2Dパズルゲームです。
- コンベア
- ストッパ
- 投入機
- 加工機
- 出荷場
こうした設備を配置して、要求された生産能力を満たす工場を作ることを目指します。
このページでは、そんなゲーム開発の過程を第1回から順番にまとめていきます。
今後も新しい記事を公開するたびに、このページへ追加していく予定です。
- 【お知らせ】PUZFLO: Run the Line のSteamストアページを公開しました
- この連載はこんな人におすすめ
- 【第1回】すべては「ゲームって作れる？」から始まった
- 【第2回】自由設計型か？パズル型か？ゲームの方向性を決める
- 【第3回】ChatGPTとCodexの役割を決めてUnity開発を始める
- 【第4回】Unity＋Codexを導入｜初めて四角形を動かしてみる
- 【第5回】ゲーム仕様書を作成｜工場パズルの基本ルールを整理する
- 【第6回】MVPを作る｜工場パズルゲームの盤面とマス選択を実装
- 【第7回】MVP仕様書を作成｜CodexへSTEP形式で実装を依頼する
- 【第8回】コンベア配置システムを実装｜BlockBaseで設備の土台を作る
- 【第9回】ワークをコンベア上で流す｜ランダム供給と試運転を実装
- 【第10回】ストッパを実装｜ワークの流れを「整える」ゲームへ
- 【第11回】Goalを作って「何のために整流するのか？」を考える
- 【第12回】「一定間隔で出荷」から加工機中心のゲームへ方向転換
- 【第13回】加工機を実装｜BUSY中に次のワークが来たらNG
- 【第14回】MVP ver.0.1完成｜ここまでのゲームを一度整理する
- 【第15回】お金を追加｜工場を「育てるゲーム」へ大幅仕様変更
- 第16回｜設備に「性能差」と「価格差」を付けてみた
- 第17回｜投入機S・Mサイズを作って設備選びを始めた
- 第18回｜加工機にもS・Mサイズを追加して「個/s」で能力をそろえる
- 第19回｜ストッパの能力も「個/s」で考えてみた
- 第20回｜Goalを「最大出荷能力」を持つ出荷場へ変更
- 第21回｜Lサイズ設備と3種類のコンベアを追加
- 第22回｜設備詳細UIを作って「数字を見て設計するゲーム」へ
- 第23回｜複数ライン化と出荷場の仕様を再設計
- 第24回｜分岐・合流コンベアを実装
- 第25回｜土地拡張とカメラ操作を実装
- 第26回｜ChatGPTとゲームの「物足りなさ」を壁打ち
- 第27回｜ワーク4種類を決定
- 第28回｜ワークの「形」と「色」に意味を持たせる
- 第29回｜精密品用バッファコンベアを実装
- 第30回｜2種・3種・4種の混合投入機を実装
- 第31回｜識別分岐・優先合流コンベアを実装
- 第32回｜土地拡張そのものをパズルにする
- 第33回｜「ゲームを作れる？」から「面白いゲームを作れる？」へ
- 第34回｜ゲームタイトルを「PUZFLO」に決定
- 第35回｜PUZFLOを本気で遊んでみる
- 第36回｜ChatGPTとCodexでバグを修正
- 第37回｜ゲーム後半のFPS低下を調査
- 第38回｜Profilerで原因を調べてWindows版も確認
- 第39回｜ゲーム画面のUIを本格改善
- 第40回｜タイトル・ポーズ・設定画面などを整える
- 第41回｜Steamworksへ開発者登録してみた
- 第42回｜Steamストアページのゲーム情報を入力
- 第43回｜Steam用のカプセル画像とスクリーンショットを作成
- 第44回｜Steam用予告動画の前にゲームを英語対応
- 第45回｜Steam用の英語版ゲームトレーラーを制作
- 第46回｜Unityで作ったゲームをSteamへアップロード
- 第47回｜ついにSteamストアページを公開！
- 第48回｜2連・3連加工機・クロスコンベア・ロボットアームを追加
- 第49回｜FPSによって生産結果が変わる問題を改善！Tick処理を導入
- 第50回｜Tick処理を17ステップで実装！FPSを変えて再現性を徹底検証
- 第51回｜ゲーム終盤のFPS低下を改善！大規模工場でも60FPSを実現
- 第52回｜組立機を実装！複数のワークから1つの製品を作る
- 第53回｜2分割・3分割切断機を実装！ワークを増やす新しい設備
- 第54回｜ChatGPTとCodexでゲームを6言語に対応！
- 第55回｜Steam向け無料デモ版を制作！製品版と分けて管理する
- 第56回｜Steamworksへデモ版を登録！アップロードと審査申請に挑戦
- 第57回｜ついにSteamデモ版を無料公開！審査からリリースまで
- 初めて読むなら第1回からがおすすめ
【お知らせ】PUZFLO: Run the Line のSteamストアページを公開しました
この連載で、ChatGPTやCodexと一緒に少しずつ作ってきた工場パズルゲーム
『PUZFLO: Run the Line』のSteamストアページを公開しました。
「AIを使えば、ゲーム制作未経験でもSteamで販売するゲームを作れるのか？」
そんなところから始めた挑戦ですが、
ついにSteam上で「発売予定のゲーム」として公開されるところまで進みました。
PUZFLOは、コンベアや加工機などの設備を配置して生産ラインを作り、
設計する → 生産する → 問題を見つける → 改善する
を繰り返す、2Dの工場パズルゲームです。
まだ開発途中ですが、Steamストアページでは、
- ゲームの概要
- スクリーンショット
- ゲームプレイトレーラー
- 最新のゲーム画面
などを見ることができます。
この連載を最初から読んでいただいている方には、
「あのゲームがここまで変わったのか」と見てもらえると嬉しいです。
また、PUZFLOが少しでも気になった方は、
Steamページからウィッシュリストに追加していただけると、
今後の開発の大きな励みになります。
PUZFLO: Run the Line｜Steamストアページはこちら 👇
この下からは、PUZFLOがどのように生まれ、
どのようにSteam公開まで進んできたのかを、
第1回から順番にまとめています。
この連載はこんな人におすすめ
この連載は、ゲーム制作の専門的な解説というより、
「ゲーム制作未経験の機械設計者がAIを使ったら、どこまで作れるのか？」
を記録した開発日記です。
特に、
- AIを使ったゲーム制作に興味がある
- Unityを触ったことがない
- Codexでどこまで開発できるのか知りたい
- Steamで自作ゲームを販売してみたい
- 工場・生産ライン系のゲームが好き
- 機械設計とゲーム制作の共通点に興味がある
という方には楽しんでもらえると思います。
自分自身が初心者なので、
「分からないところからどう進めたか」
もできるだけそのまま残しています。
【第1回】すべては「ゲームって作れる？」から始まった
最初はゲームを作る予定すらありませんでした。
ChatGPTに、
「ゲームって作れる？」
と聞いてみたことがきっかけです。
そこから、どんなゲームなら自分でも作れそうか？
機械設計者だからこそ作れるゲームは何か？を考え始めました。
そして出てきたのが、
工場の生産ラインをテーマにしたゲームというアイデアです。
この時点では、まだ具体的なルールもありません。
ただ、
- コンベアをつなぐ
- ワークを流す
- 工場を改善する
という大まかな方向だけが決まりました。
この連載のスタート地点です。
【第2回】自由設計型か？パズル型か？ゲームの方向性を決める
次に考えたのが、どんなゲーム性にするのか？です。
最初に候補になったのは、大きく2つ。
自由に工場を作れる、自由設計型。
もう一つは、限られた設備や条件の中で正解を探す、選択・最適化型。
最終的には、選択・最適化型の工場パズルを採用しました。
設備を好き放題置くだけではなく、限られた条件の中で、
どうすれば効率の良いラインになるのか？を考えるゲームです。
今振り返ると、現在のゲームにつながるかなり重要な決定でした。
【第3回】ChatGPTとCodexの役割を決めてUnity開発を始める
ゲームの方向性が決まったところで、実際にどうやって作るのかを考えます。
ここで採用したのが、Unity＋Codexです。
正直なところ、Unityをいくつものゲームエンジンと細かく比較したわけではありません。
ChatGPTに聞いたらUnityが候補として出てきた。
そして、「無料でゲームを作れるの？」という驚きもあり、
そのまま試してみることにしました。
開発の役割も、
という形に整理しました。
この役割分担は、現在までほぼ変わっていません。
【第4回】Unity＋Codexを導入｜初めて四角形を動かしてみる
いよいよUnityをインストールします。
ゲーム制作未経験なので、画面を開いた時点で、
「難しそう……」という印象でした。
でも今回は、Unityを完璧に覚えることが目的ではありません。
できるだけAIに任せます。
そして最初にChatGPTから言われたのが、
「四角形を作って動かしてみましょう」でした。
正直、「工場ゲームを作りたいのに、なんで四角？」と思いました。
それでもCodexにコードを書いてもらい、
四角いWorkが画面上を右へ移動。
たったそれだけですが、初めて自分のゲームが動いた瞬間でした。
【第5回】ゲーム仕様書を作成｜工場パズルの基本ルールを整理する
動くことが確認できたので、ここから本格的にゲーム仕様を考えていきます。
作成したのが、ゲーム仕様書 Ver.1.0です。
この段階で考えたゲームの基本ループは、
依頼を受ける
↓
設計する
↓
試運転する
↓
問題を発見する
↓
改善する
↓
納品する
というもの。
さらに、「最小コストで要求仕様を満たす」という
考え方もゲームの中心に置くことにしました。
高性能な設備を使えば簡単。
でも高い。安い設備だけでは能力が足りない。
この、コストと性能のトレードオフが、現在のゲームにもつながっています。
【第6回】MVPを作る｜工場パズルゲームの盤面とマス選択を実装
仕様が決まったら、いよいよゲーム画面を作ります。
まず必要だったのが、工場のグリッドです。
検討した結果、最初のMVPでは、
12×8のグリッドを採用しました。
1マスにつき、1つの設備を置く。
- コンベア
- ストッパ
- 加工機
といった設備を、マス単位で配置していきます。
ただし、ワークまでマス単位でカクカク移動すると見た目が悪い。
そこで、設備配置はグリッド式。
ワークは滑らかに移動する。という方式にしました。
【第7回】MVP仕様書を作成｜CodexへSTEP形式で実装を依頼する
ここで初めて、MVP_Spec_v0.1.mdという仕様書を作りました。
ちなみに最初は、「mdって何？」という状態です。
でも、この仕様書をCodexに読ませ、
STEP1、STEP2……
と少しずつ実装させる方法がかなり使いやすいことが分かりました。
最初に作ったのは、12×8グリッド。
次に、セルをクリックすると黄色く選択される機能。
ここから、
仕様を決める
↓
Codexへ依頼
↓
Unityで確認
↓
問題があればChatGPTへ相談
という現在の開発スタイルが固まっていきました。
【第8回】コンベア配置システムを実装｜BlockBaseで設備の土台を作る
次は、設備をグリッド上へ配置する仕組みです。
当初は、コンベアだけ置ければいいかな？と思っていました。
しかしChatGPTから、
「今後設備が増えるなら、共通のBlockBaseを作った方がいい」
という提案がありました。
そこで、BlockBaseという設備共通の基底クラスを作成。
設備ごとに、
- 座標
- 向き
- 種類
- 有効状態
- 回転
などを持てるようにしました。
この段階で、
まで実装。
ようやく、工場を自分で組み立てている感じが出てきました。
【第9回】ワークをコンベア上で流す｜ランダム供給と試運転を実装
設備を置けるようになったら、次はワークを流します。
最初は、青いワークを1個だけ生成。
コンベアの向きに沿って、滑らかに移動させました。
コンベアが途中で切れていれば停止。
曲がっていれば方向転換。
これが動いたことで、それまで静止していた工場が、
初めて生産ラインらしく動き始めました。
さらに、ワークを10個程度、不規則な間隔で投入。
試運転。
リセット。
といった機能も追加しました。
そして重要なのが、毎回同じ供給パターンを再現すること。
改善前と改善後を、同じ条件で比較できるようにしました。
【第10回】ストッパを実装｜ワークの流れを「整える」ゲームへ
第10回では、ゲーム性を大きく変える設備、ストッパを追加しました。
それまでワークは、コンベアに乗ったらそのまま流れていくだけ。
でもストッパを置くと、一度ワークを止めて、
一定周期で1個ずつ送り出せるようになります。
イメージとしては、バラバラだったワークを、
一定の間隔へ整える設備です。
ここで初めて、設備を置くことで、ワークの流れそのものが変わる
というゲーム性が見えてきました。
単純にコンベアをつなぐだけではなく、
どう流すかを考える工場パズルへ変わり始めた回です。
【第11回】Goalを作って「何のために整流するのか？」を考える
ここで一つ大きな問題に気付きます。
ストッパを調整して、ワークを一定間隔にできる。
でも、「そもそも、なぜ一定間隔にする必要があるの？」ということです。
そこで第11回では、ゲームに明確な目的を持たせるため、
Goal（出荷地点）について考えました。
最初は、
- 目標出荷間隔：2.0秒
- 許容差：±0.2秒
のように、一定間隔でGoalへワークを送ることをクリア条件にする案を検討。
ここで初めて、配置 → 試運転 → 結果確認 → 改善
というゲームループが、かなりはっきりしてきました。
【第12回】「一定間隔で出荷」から加工機中心のゲームへ方向転換
Goalに目標間隔を持たせる案を考えていましたが、
ここでまた疑問が出てきました。
「なぜGoalが2秒間隔を要求するの？」
少しゲーム側の都合に見えてしまいます。
そこで考えたのが、加工機です。
例えば加工機が、2秒に1個しか処理できないとします。
そこへ1秒ごとにワークを送り込めば、当然、加工機前で詰まります。
これなら、ワーク間隔を整える理由がかなり自然です。
そこでゲームの目的を、
未加工ワークを加工機へ適切な間隔で供給し、
加工済みワークだけをGoalへ送り続ける
という形へ変更しました。
ワークの状態も、
- 白：未加工
- 青：加工済み
として視覚的に分かるようにします。
この変更で、ストッパは単に「間隔をきれいにする設備」ではなく、
加工機の能力に合わせて供給を調整する設備になりました。
【第13回】加工機を実装｜BUSY中に次のワークが来たらNG
第13回では、加工機を実際にゲームへ実装しました。
ワークが加工機へ入るとBUSYになり、
加工が終わると白いワークが青色へ変化します。
そして、加工中に次のワークが到着したらINPUT TIMING NG。
さらに渋滞がStart付近まで伸びた場合もNGとしました。
NG後は設備配置を消さず、そのままEDITへ戻ります。
これによって、
失敗 → 原因確認 → 改善 → 再試運転
という工場パズルらしい流れが、かなり形になってきました。
【第14回】MVP ver.0.1完成｜ここまでのゲームを一度整理する
加工機まで実装したところで、一度MVP ver.0.1としてゲームを整理しました。
ここまでで、
- グリッド
- コンベア
- ワーク搬送
- ストッパ
- 加工機
- Goal
- NG判定
- 試運転
- リセットなど、
基本的な仕組みが一通り動くようになっています。
そして一番大きかったのは、
「プレイヤーに何を考えてほしいゲームなのか」が見えてきたこと。
最初はワークを運ぶだけでしたが、
設備能力を見ながら、配置や供給タイミングを考えるゲームへ変わってきました。
【第15回】お金を追加｜工場を「育てるゲーム」へ大幅仕様変更
第15回では、ゲームにお金を追加しました。
これまでは無料で設備を置いていましたが、
今後は初期資金を使って設備を購入し、生産・出荷してお金を稼ぐ仕組みに変更します。
ゲームの流れも、
設備購入 → ライン設計 → 試運転 → 生産 → 利益 → 設備更新へ大きく変化。
ただし、今まで作ったグリッドやコンベア、加工機などはそのまま活用します。
そのため旧仕様をPrototype v0.1として残し、
新しい経済要素を加えたVer.0.2として開発を続けることにしました。
第16回｜設備に「性能差」と「価格差」を付けてみた
ここまでは、設備ごとの役割は違っても、
同じ種類の設備を選び分ける要素はほとんどありませんでした。
そこで第16回では、設備ごとに価格・能力・サイズなどの
データを持たせ、性能の違う設備を追加できる土台を作りました。
ここから、単に設備を置くだけではなく、
「どの設備を買うか？」を考えるゲームへ進み始めます。
第17回｜投入機S・Mサイズを作って設備選びを始めた
第17回では、投入機にS・Mサイズを追加しました。
安くて能力の低いSサイズと、
価格は高いけれど能力や安定性に優れるMサイズ。
コストを抑えるか、性能を優先するか。
最初に考えていた「コストと性能のトレードオフ」が、
少しずつゲームとして見えてきました。
第18回｜加工機にもS・Mサイズを追加して「個/s」で能力をそろえる
投入機に続いて、加工機にもS・Mサイズを追加しました。
このあたりから、投入機と加工機の能力を「個/s」で統一して比較するようになります。
投入能力0.45個/sなら、加工側にもどの程度の能力が必要なのか。
設備単体ではなく、ライン全体の能力バランスを見るゲームへ変わっていきました。
第19回｜ストッパの能力も「個/s」で考えてみた
第19回では、ストッパについても能力を個/sで考えるようにしました。
ところが、投入機・ストッパ・加工機を同じ能力に
すれば完璧かというと、実際にはそう簡単ではありません。
投入タイミングのばらつきや処理誤差によって、
同じ能力でもNGが発生することが分かり、
ラインには少し余裕が必要という考え方が出てきました。
第20回｜Goalを「最大出荷能力」を持つ出荷場へ変更
これまで単純なゴールだった設備を、
出荷能力を持つ「出荷場」へ変更しました。
出荷場にも「最大○個/s」という上限を設定。
これによって、
投入 → 加工 → 搬送 → 出荷
まで、ライン全体を同じ「個/s」で考えられるようになりました。
第21回｜Lサイズ設備と3種類のコンベアを追加
さらに設備選びを広げるため、
投入機・加工機にLサイズを追加しました。
コンベアも1種類から、Low / Medium / Highの3種類へ。
高性能設備を使えば簡単になる一方、価格や設置スペースも増えるため、
「どこにお金を使うか」という判断がさらに重要になってきました。
第22回｜設備詳細UIを作って「数字を見て設計するゲーム」へ
設備種類が増えてくると、
「結局どれを選べばいいの？」
という問題も出てきました。
そこで第22回では、設備をクリックすると、
能力・価格・サイズ・耐久性などを確認できる設備詳細UIを追加しました。
中でも一番大きく表示するのは、これまで統一してきた「 個/s 」。
ボタン名だけで設備を選ぶのではなく、
スペックを比較して設備を選ぶゲームへ一歩進みました。
第23回｜複数ライン化と出荷場の仕様を再設計
これまでは、基本的に投入機 → 加工機 → 出荷場
という1本のラインを調整するゲームでした。
ここからは投入機や加工機を複数台使えるようにして、
工場全体の生産能力を考えるゲームへ広げていきます。
さらに出荷場にも「目標出荷能力」や「必要な加工工程」といった条件を追加。
単純にワークを流すだけではなく、
要求された製品条件と生産能力の両方を満たすライン設計を考えるようになってきました。
第24回｜分岐・合流コンベアを実装
複数ラインを作れるようになったことで、
次に必要になったのがラインを分ける・まとめる設備です。
そこで、
- 分岐コンベア
- 合流コンベア
を追加しました。
1本のラインを2本へ分けたり、
複数のラインを再び1本へまとめたりできるようになり、
これまでの一直線なラインから、工場全体の流れを設計するゲームへ一歩進みました。
第25回｜土地拡張とカメラ操作を実装
設備やラインが増えてくると、今度は、工場が狭い。
という問題が出てきました。
そこで、最初から広い土地を使えるようにするのではなく、
ゲームを進めながら工場の土地そのものを拡張できる仕組みを追加。
さらに、広くなった工場を見渡せるように、
カメラの移動やズーム操作も整えていきました。
設備だけでなく、工場そのものが成長していく仕組みが入った回です。
第26回｜ChatGPTとゲームの「物足りなさ」を壁打ち
機能はかなり増えてきました。
でも実際に遊んでみると、
「ちゃんと動くけど、まだ何か物足りない。」
と感じるようになりました。
そこで、この回ではあえて実装を止めて、
ChatGPTと「どうすればもっとゲームとして面白くなるのか？」を壁打ち。
コンボ、スコア、受注、設計レビューなどさまざまな案を考えた結果、
設備側ではなく、流れるワークそのものに種類を持たせる方向へ進むことにしました。
第27回｜ワーク4種類を決定
ここまでのPUZFLOでは、
基本的にすべて同じワークを流していました。
そこで、
- 標準品
- 未加工品
- 精密品
- 短納期品
という4種類のワークを考えました。
ただ見た目が違うだけではなく、
精密品なら接触させたくない。
短納期品なら早く出荷したい。
といったように、
ワークによって最適なライン設計そのものが変わるようにしていきます。
第28回｜ワークの「形」と「色」に意味を持たせる
ワークが4種類になると、
「何のワークなのか？」
「何回加工されたのか？」
を同時に分かりやすく表示する必要があります。
そこで、
形 ＝ ワークの種類
色 ＝ 加工回数
というルールにしました。
丸・四角・ひし形・三角で種類を見分け、
色の変化で加工状態を確認。
ワークそのものが情報を持つようになり、
今後の識別・分岐・加工・出荷判定につながる基礎ができました。
第29回｜精密品用バッファコンベアを実装
精密品には、ワーク同士を接触させたくないという特殊なルールがあります。
ただ、普通のストッパで止めると、
後ろから来たワークと接触してしまいます。
そこで追加したのが、バッファコンベアです。
コンベアの速度差を使ってワーク間隔を調整し、
止めるのではなく、流しながら間隔を作る設備として実装しました。
設備を追加するだけでなく、
土地やコストとのトレードオフも増えてきました。
第30回｜2種・3種・4種の混合投入機を実装
ここまでの投入機は、
選んだ1種類のワークだけを流していました。
それでは、
「最初からワークごとにラインを分ければいい」
となってしまいます。
そこで、
- 2種混合投入機
- 3種混合投入機
- 4種混合投入機
を追加。
複数種類のワークが同じラインへランダムに流れることで、
流れてきたワークを見分けて処理する必要が出てきました。
ここから一気に、工場らしい自動化パズルへ近づいていきます。
第31回｜識別分岐・優先合流コンベアを実装
混合投入機を追加したことで、
次に必要になったのがワークの自動仕分けです。
そこで、識別分岐コンベアを実装。
ワークの種類を判定して、精密品、短納期品、未加工品などを
それぞれ必要なラインへ振り分けられるようにしました。
さらに、分けたラインを再びまとめるために、優先合流コンベアも追加。
これによって、
混ぜる → 見分ける → 分ける → 加工する → 優先してまとめる
という、本格的な生産ラインらしい流れが作れるようになりました。
第32回｜土地拡張そのものをパズルにする
設備が増えてくると、
12×11の工場でも土地が足りなくなってきました。
そこで12×11以降は、単純に工場全体を広げるのではなく、
- 10×1
- 8×2
- 6×3
- 4×4
といった土地パーツを自分で配置する方式へ変更しました。
土地にも形・価格・配置場所の違いがあり、
同じ土地を何度も購入すると価格も上がっていきます。
これまでの、「限られた土地に設備をどう置くか？」だけでなく、
「そもそも、どんな形の工場を作るか？」まで考えるゲームへ一歩進みました。
第33回｜「ゲームを作れる？」から「面白いゲームを作れる？」へ
ここまでで、
- 設備
- ワーク
- 分岐・合流
- 土地拡張
など、ゲームとして必要な仕組みはかなり揃ってきました。
でも、Steamで販売するなら、「ちゃんと動くゲーム」だけでは足りません。
そこで一度立ち止まり、
AIを使えばゲームは作れそう。
では、AIと一緒に「面白いゲーム」も作れるのか？
を考えることにしました。
ここから開発の目標が、
機能を増やすことから、遊んで面白いゲームへ
仕上げることへ少しずつ変わっていきます。
第34回｜ゲームタイトルを「PUZFLO」に決定
ゲームの方向性が見えてきたところで、
ずっと後回しにしていた正式タイトルを決めました。
ChatGPTと大量の候補を出しながら、
- 短い
- 覚えやすい
- ロゴにしやすい
- ゲーム内容をイメージできる
といった条件で検討。
最終的に、
Puzzle ＋ Flow ＝ PUZFLO（パズフロ）
に決定しました。
「ワークの流れを考えるパズル」という、
今のゲーム内容にも合った名前です。
名前が付いたことで、Unityの練習用ゲームではなく、
Steamで販売する1本のゲームという感覚も強くなってきました。
第35回｜PUZFLOを本気で遊んでみる
タイトルまで決まりましたが、
まだ「本当に面白いのか？」は別の話です。
そこで新しい設備を作るのを一度止めて、
自分でPUZFLOを何度も遊んでみることにしました。
実際にプレイすると、
ラインが詰まる。
原因を探す。
設備能力を見る。
配置を変える。
もう一度動かす。
という、「問題を見つけて改善する瞬間」が一番PUZFLOらしいと感じました。
ここから、設備をただ増やすのではなく、
プレイヤーが考えたくなる問題を増やすことを重視するようになります。
第36回｜ChatGPTとCodexでバグを修正
本気で遊び始めると、
今度は細かい不具合も見つかるようになりました。
例えば、
- ストッパ内でワークが永久停止する
- 加工機と優先合流をつなぐとワークが止まる
- 識別分岐の途中でワークが一時停止する
など。
自分はコードが分からないため、
自分が違和感を見つける
↓
ChatGPTに症状を整理してもらう
↓
Codexに原因調査・修正を依頼
↓
Unityで再確認
という流れで直していきました。
AIにコードを書いてもらっていても、
「何かおかしい」と気付く役割は人間側にあると感じた回です。
第37回｜ゲーム後半のFPS低下を調査
PUZFLOを長く遊んでいると、
ゲーム後半になるほど動作が重くなることにも気付きました。
実際に確認すると、
序盤：約170FPS
最大規模：約30FPS
まで低下。
さらに、同じSeed・同じ設備配置なのに、
結果が変わることまでありました。
そこで、いきなりコードを書き換えるのではなく、
「そもそも何が重いのか？」
をChatGPTと一緒に調べることにしました。
ゲーム制作初心者が初めて、
性能や最適化を意識し始めた回です。
第38回｜Profilerで原因を調べてWindows版も確認
第37回に続いて、今度は実際に
ゲームが重い原因を調査しました。
UnityのProfilerを使って確認すると、
大量に存在するワークの処理など、CPU側の負荷が大きいことが分かってきます。
ただし、いきなり大きな最適化をするのではなく、
まずは安全そうな部分だけを修正。
さらに初めてWindows版としてビルドして確認すると、
Unity Editorでは約30FPSだった大規模工場が、
Windows版ではほぼ60FPSで動きました。
ここで、「Unity Editorで重い＝製品版も重い」ではない
ということも分かりました。
第39回｜ゲーム画面のUIを本格改善
動作面で少し安心できたところで、
次に気になったのがゲーム画面の分かりやすさです。
PUZFLOには設備や情報が増え、
- 上部バー
- 設備パネル
- 設備情報
- 生産操作
- 出荷場ゲージ
など、表示するものもかなり増えていました。
そこで、中央の工場画面をできるだけ広く残す
ことを意識しながら、UI全体を整理。
「ゲームが動く」だけではなく、
初めて遊ぶ人でも状況を理解しやすい画面へ改善していきました。
第40回｜タイトル・ポーズ・設定画面などを整える
メインゲーム画面を改善した次は、
ゲーム中以外の画面もまとめて見直しました。
対象になったのは、
- タイトル画面
- ポーズ画面
- 設定画面
- 操作方法
- How To Play
- セーブ画面
など。
それぞれ別々に作ってきた画面を、
PUZFLOらしい濃紺をベースにした工業系デザインへ統一していきます。
操作方法や説明文も整理しながら、
「開発中のゲーム画面」から「Steamで販売する製品の画面」へ
少しずつ見た目と使いやすさを仕上げていった回です。
第41回｜Steamworksへ開発者登録してみた
これまでUnityでPUZFLOを作ってきましたが、Steamで販売するには、
まずSteamworksへの開発者登録が必要です。
そこで、Steam Directの登録料100ドルを支払い、
銀行口座や税務情報、本人確認などの手続きを進めました。
特に戸惑ったのが、税務情報の入力と本人確認です。
身分証明書の提出だけでなく、身分証を持った自撮り写真も必要になり、
思っていたより本格的な手続きでした。
申請から1週間以上待ち、ようやく届いたのが、
「おめでとうございます。あなたはSteamworksの開発者になりました。」
というメール。
ここまで来て、本当にSteamでゲームを販売するんだという実感が湧いてきました。
第42回｜Steamストアページのゲーム情報を入力
Steamworksへの登録が完了したので、次はPUZFLOのストアページ制作です。
正式タイトルを「PUZFLO: Run the Line」とし、
ゲーム概要や短い説明文、ジャンル、タグ、対応言語などを設定していきました。
ただ、実際に入力してみると、
など、分からないことが次々と出てきます。
そこで今回もChatGPTに相談しながら、一つずつ設定しました。
ゲームを作るだけでなく、初めて見る人にPUZFLOの面白さをどう伝えるかを考え始めた回です。
第43回｜Steam用のカプセル画像とスクリーンショットを作成
ゲーム情報を入力した次は、Steamストアで使う画像の制作です。
Steamでは、表示場所によって必要な画像サイズが異なります。
想像以上に多くの画像が必要でした。
そこでChatGPTと相談しながら、PUZFLOのロゴや設備、コンベアを使ったキービジュアルを制作。
さらに、ゲームの面白さが伝わるように、スクリーンショットも5枚用意しました。
特に意識したのは、画像だけ格好よくするのではなく、
実際のゲーム画面との違和感を減らすことです。
Steamでの見せ方を考えることで、PUZFLOが少しずつ
「販売するゲーム」らしくなってきました。
第44回｜Steam用予告動画の前にゲームを英語対応
Steam用の画像が揃ったので、次は予告編動画を作ろうと考えました。
ところがChatGPTへ相談したところ、
「先にゲーム画面を英語対応した方がいい」という話になりました。
確かに、PUZFLOは設備名や生産能力、エラー表示など、
ゲーム画面に多くの日本語が使われています。
そこでCodexを使って、日本語と英語を切り替えられる仕組みを実装しました。
さらに、英語表示で文字がはみ出さないか、
翻訳が不自然ではないかなどもChatGPTと一緒に確認。
単に日本語を英語に置き換えるだけではなく、
海外のプレイヤーにも分かりやすいゲーム画面を目指しました。
予告編を作るつもりが、ゲーム本体の英語化まで進んだ回です。
第45回｜Steam用の英語版ゲームトレーラーを制作
ゲームの英語対応ができたところで、いよいよSteam用の予告編動画を作成します。
PUZFLOは、設備を配置して終わりではありません。
生産ラインを動かし、問題を見つけて改善することがゲームの中心です。
そこで今回は、単に格好いい場面を並べるのではなく、
設計する → 生産する → 問題が発生する → 改善する
というゲームの流れが伝わる動画を目指しました。
実際のゲームプレイを録画し、英語の説明文や場面の切り替えを調整。
最終的に、約50秒の英語版ゲームトレーラーを完成させました。
静止画だけでは伝わりにくかった、PUZFLOの動きやゲーム性を見せられるようになった回です。
第46回｜Unityで作ったゲームをSteamへアップロード
ストアページの画像や予告編が揃ったので、次はゲーム本体をSteamへアップロードします。
これまでは、Unity上でゲームを動かして確認していました。
しかし、Steamで販売するには、Windows版のゲームを作成し、
Steamworksへ登録する必要があります。
そこで、UnityでWindowsビルドを作成し、
SteamPipeという仕組みを使ってアップロードしました。
さらにSteam側でビルドを設定し、実際にSteamから
ゲームをインストールして動作確認する流れも整理。
ここで重要だったのが、「Unityで正常に動くこと」と
「Steamからインストールして正常に動くこと」は別という点です。
PUZFLOが、自分の開発環境だけでなく、Steamを通して配布できるゲームへ近づいた回です。
第47回｜ついにSteamストアページを公開！
Steamworksへの登録から始まり、ゲーム情報、画像、予告編など、さまざまな準備を進めてきました。
そして今回、ついにSteamストアページの審査へ提出します。
必要な項目を確認し、レビュー準備完了として申請。
土曜日に提出したところ、木曜日には承認メールが届きました。
大きな修正依頼もなく、約4営業日で審査が完了。
その後、PUZFLOのストアページを「近日登場（Coming Soon）」として公開しました。
これによって、発売前からウィッシュリストへ追加してもらえるようになりました。
第1回では「AIでSteamゲームを作ってみたい」と考えていただけでしたが、
ついにSteam上に発売予定のゲームとしてPUZFLOが公開されたのです。
個人的にも、開発を始めてから特に大きな節目になった回でした。
第48回｜2連・3連加工機・クロスコンベア・ロボットアームを追加
Steamの「近日登場」ページまで公開できたので、
販売準備はいったん大きな区切りを迎えました。
ただし、ゲーム本体はまだ完成ではありません。
そこで今回は、以前から追加したいと考えていた設備をまとめて実装します。
追加したのは、
- 2連・3連加工機
- 複数の加工工程を1台にまとめる
- クロスコンベア
- 搬送ラインを交差させる
- ロボットアーム
- コンベアとは違う方法でワークを搬送する
という4種類の設備です。
単純に設備数を増やすのではなく、加工・配置・搬送の3方向で
ライン設計の選択肢を広げることを意識しました。
これによって、今までとは違った生産ラインを作れるようになります。
Steam公開まで進んだところで、もう一度、ゲームそのものを面白くする開発へ戻った回です。
第49回｜FPSによって生産結果が変わる問題を改善！Tick処理を導入
PUZFLOを開発していて、以前から気になっていた問題がありました。
それが、同じ設備配置・同じ供給タイミングなのに、
エラーが発生するときとしないときがあるという現象です。
第37回でChatGPTに相談したときに教えてもらったのが、
「Tick処理」という仕組みでした。
ただ、当時は既存の設備への影響が心配だったこともあり、
一度導入を見送っていました。
しかし、Steamで販売することを考えると、
PCの負荷によってゲームの成功・失敗が変わってしまうのは困ります。
そこで今回は、画面のFPSとは別に、
一定の間隔で生産処理を進めるTick処理を導入することにしました。
ゲームの見た目ではなく、内部の安定性を改善するための大きな挑戦です。
第50回｜Tick処理を17ステップで実装！FPSを変えて再現性を徹底検証
前回導入を決めたTick処理ですが、ゲーム全体の仕組みに関わるため、簡単な変更ではありません。
そこでChatGPTと相談し、17ステップに分けて慎重に実装することにしました。
さらに、実装後には30FPSと20FPSで同じ生産ラインを動かし、結果を比較。
Traceという記録を使って確認したところ、
約130.6秒間、3,767件のイベントがすべて完全一致しました。
これによって、FPSが低下しても生産結果が変わりにくい仕組みを作ることができました。
また、PCが極端に重くなった場合は、
無理に処理を続けず、自動で一時停止する機能も追加。
「動くゲーム」から「同じ条件で安心して試せるゲーム」へ。
PUZFLOにとって、かなり重要な改善になった回です。
第51回｜ゲーム終盤のFPS低下を改善！大規模工場でも60FPSを実現
Tick処理によって生産結果の再現性は改善しましたが、
今度は別の問題が発生しました。
ゲーム終盤の大きな工場で生産を開始すると、
最初は60FPSなのに、約10秒後には40FPS前後まで低下するという現象です。
さらに、ゲームが重くなりすぎて、自動Pauseが発生することもありました。
そこでChatGPTとCodexを使って調査したところ、
原因はワーク同士の間隔を確認するMinimum Spacingの処理にあることが分かりました。
工場内の大量のワークを広く確認していた処理を見直し、
必要な周辺のワークを中心に調べる方式へ改善。
その結果、これまで40FPS前後まで低下していた大規模工場でも、
常時60FPSを維持できるようになりました！
ゲームのルールは変えず、無駄な計算を減らすことで大幅なFPS改善に成功した回です。
第52回｜組立機を実装！複数のワークから1つの製品を作る
ゲームの安定性が大きく改善したところで、
久しぶりに新しい設備の追加へ戻ります。
今回追加するのは、
複数のワークを組み合わせて1つの製品を作る「組立機」です。
これまでのPUZFLOでは、
ワークを加工して出荷する流れが中心でした。
しかし、組立機では必要な数のワークを揃えなければ製品が完成しません。
例えば、3点組立機なら3個のワークが必要です。
そのため、組立機の能力だけでなく、
ワークの供給タイミングや、前後のラインのバランスも重要になります。
今回もChatGPTと仕様を整理し、Codexへ段階的に実装を依頼しました。
単純に設備を増やすのではなく、
「どうすれば効率よく製品を組み立てられるか？」を考える、
新しいパズル要素が加わった回です。
第53回｜2分割・3分割切断機を実装！ワークを増やす新しい設備
前回は、複数のワークを1つにまとめる組立機を追加しました。
そこで今回は、反対に1個のワークを2個・3個に分割する「切断機」を追加します。
一見するとワークを増やすだけのシンプルな設備ですが、
実際には考えることが多くありました。
例えば、切断機で毎秒3個のワークを作っても、
次の加工機が毎秒2個しか処理できなければ、
ワークが溜まってしまいます。
つまり、切断機の追加によって、
後工程の処理能力やコンベアの搬送量がさらに重要になります。
また、前回の組立機と組み合わせれば、
切断 → 加工 → 組立
という新しい生産ラインも考えられます。
「まとめる設備」と「分ける設備」が揃い、
PUZFLOのライン設計の選択肢がさらに広がった回です。
第54回｜ChatGPTとCodexでゲームを6言語に対応！
ゲームの設備が充実してきたところで、
次は海外プレイヤーにも遊んでもらうための多言語対応に取り組みました。
第44回では日本語と英語に対応しましたが、今回はさらに、
簡体字中国語・繁体字中国語・韓国語・ドイツ語
の4言語を追加。
これによって、合計6言語に対応する仕組みを整えました。
ただし、単純に文章を翻訳するだけではありません。
ゲーム内には600項目以上の文章や表示パターンがあり、
フォントの対応や文字のはみ出し、
翻訳漏れなども確認する必要がありました。
そこで今回もChatGPTとCodexを活用し、
翻訳データの管理からゲームへの反映まで進めました。
プログラミングも外国語も得意ではない自分が、
AIを使って6言語対応に挑戦できた。
AIゲーム開発の可能性を改めて感じた回です。
第55回｜Steam向け無料デモ版を制作！製品版と分けて管理する
Steamの「近日登場」ページは公開できましたが、
まだプレイヤーにゲームを体験してもらうことはできません。
そこで今回は、Steam向けの無料デモ版（体験版）を制作することにしました。
デモ版では、出荷場1〜10までプレイ可能とし、
土地は最大12×11マスまでに制限。
さらに、一部の設備をLOCK表示にして、
製品版との違いを作りました。
ただ、ここで一番心配だったのが、
デモ版の制限が製品版にも影響してしまわないか？ということです。
そこでUnityのBuild Profilesを使い分け、
製品版とデモ版を別々にビルドできるようにしました。
さらに、セーブデータの分離やデモ版専用のクリア画面なども実装。
Codexによる自動テストやWindows版の動作確認も行い、
Steamへ提出するためのデモ版を完成させました。
第56回｜Steamworksへデモ版を登録！アップロードと審査申請に挑戦
前回、Unityで無料デモ版を完成させました。
しかし、ゲームを作っただけではSteamで公開できません。
そこで今回は、Steamworksへデモ版を登録し、公開の準備を進めます。
最初に分かったのが、デモ版は製品版に関連付けられた
別のアプリとして管理する必要があるということです。
さらに、ゲームデータをSteamへアップロードし、起動設定や必要な情報を確認。
今回のPUZFLOでは、デモ版専用の独立したストアページは作らず、
製品版のストアページから無料体験版をダウンロードしてもらう方針にしました。
そして、Steamworksのストアプレゼンスと体験版ビルドの審査を申請。
Unityで作ったゲームを、実際にSteamで配布するための準備を進めた回です。
第57回｜ついにSteamデモ版を無料公開！審査からリリースまで
前回、Steamworksへデモ版の審査を申請しました。
しかし、デモ版の承認は思っていたより時間がかかりました。
今回の流れは、
10月21日：審査申請
10月24日：ストアプレゼンス承認
10月29日：体験版ビルド承認
10月30日：デモ版を一般公開！
というものでした。
ストアページが先に承認されても、ゲーム本体の審査が完了するまでは公開できません。
少し長く感じた審査期間でしたが、無事に承認され、
ついにPUZFLO DemoをSteamで無料公開することができました！
さらに、製品版ストアページにデモ版のダウンロードボタンを表示し、Steamからの起動も確認。
日本語・英語で公開のお知らせも投稿しました。
第1回では「AIを使ってSteamゲームを作ってみたい」という興味から始まった挑戦。
それが今回、自分の作ったゲームを誰でも無料で遊べる状態にすることができました。
まだ製品版の発売ではありませんが、PUZFLO開発の中でも特に大きな節目になった回です。
初めて読むなら第1回からがおすすめ
この連載は途中から読んでも内容は分かります。
ただ、ゲームの仕様がどう変わっていったのかまで楽しみたい方は、
第1回から順番に読むのがおすすめです。
特に、「最初はこんな単純なゲームだったのか」
という状態から、少しずつ工場ゲームらしくなっていく過程は、
この連載ならではだと思います。
ゲーム制作初心者。
プログラミングもほぼ分からない。
そんな状態から、ChatGPTとCodexを使ってSteamゲームを作る。
果たして本当に販売までたどり着けるのか。
まだ自分にも分かりません。
引き続き、実際の開発過程をそのまま記録していきます。