前回、第35回では、PUZFLOを実際に何度もプレイして、
「ちゃんと動くか？」だけではなく「本当に面白いか？」
という視点でゲームを見直しました。
ただ、本気で遊び始めると、もう一つ見つかるものがあります。
不具合やバグです。
しかも最近は、
「加工機が動かない」
「コンベアが動かない」
といった単純なバグよりも、設備単体では正常なのに、
特定の設備同士をつなぐとおかしくなるという不具合が増えてきました。
設備が増えてきた証拠でもあります。
今回は、実際にPUZFLOで発生した、
という3つの不具合を例に、ChatGPTとCodexを使って、
どう修正しているのかをまとめてみます。
バグ修正でも、基本的な流れは変わらない
自分はコードを書けません。
なので不具合が起きても、「この関数がおかしい」とは分かりません。
でも、「この設備とこの設備をつないだら止まった」なら分かります。
そこで、いつもこんな流れで修正しています。
不具合を見つける。
↓
ChatGPTに症状を伝える。
↓
原因候補と確認ポイントを整理してもらう。
↓
Codexへ渡す修正依頼文を作ってもらう。
↓
Codexにコードを確認・修正してもらう。
↓
Unityで再び同じ条件を試す。
↓
結果をChatGPTへ報告する。
この繰り返しです。
不具合① ストッパへ連続して入るとワークが永久停止する
まず見つけたのが、ストッパの不具合です。
ストッパは、ワークを一度止めて、設定した周期で1個ずつ流す設備です。
普通にワークが流れているときは問題ありません。
ところが、ワーク同士の間隔がほとんどない状態でストッパへ連続進入すると問題が起こりました。
ストッパの中でワークが動かなくなる
例えば、ワークがかなり詰まった状態で、次々とストッパへ入ります。
すると、1個目は停止。その後ろへ2個目。
さらに3個目。という状態になります。
本来ならストッパが開くたびに、1個ずつ前へ送り出すはずです。
しかし、ある条件になると、
ストッパ内部のワークが永久に動かなくなるという現象が起きました。
生産を続けても動かない。ストッパ周期を待っても動かない。
完全に詰まっています。
ChatGPTには「起きた状況」をそのまま伝える
自分ではコード側の原因が分かりません。
なので、
「ワークが間隔なくストッパへ入ると、ストッパ内部でワークが永久停止します。
通常の間隔で入る場合は問題ありません。」
というように伝えました。
すると、単純にストッパの開閉だけではなく、
- ストッパ内部で複数ワークが待機した場合の状態
- 先頭ワークを解放したあとの次ワークへの引き継ぎ
- Minimum Spacingとの待機判定
- 「通過可能」へ戻す条件
あたりを確認した方がいい、という話になりました。
ここで重要なのは、「ストッパが動かない」のではなく、
「連続投入したときだけ動かない」という情報です。
これだけで確認する場所がかなり絞られます。
Codexには再現条件ごと渡す
Codexへの依頼も、
単に、ストッパのバグを直してではなく、
再現条件まで書きます。
例えば、
ワーク同士の間隔がほぼない状態で複数ワークをストッパへ進入させる。
その後、ストッパ内部でワークが永久停止することがある。
通常間隔では正常に動作する。
複数ワーク待機時の解放処理と状態遷移を確認して修正してください。
という感じです。
Codex側で関連コードを確認してもらい、複数ワークが連続して待機した場合でも、
先頭から順番に解放されるように処理を見直す方向で修正しました。
修正後は「わざと詰まらせる」
普通に動かして、「直った！」では確認になりません。
わざと投入能力を上げて、ストッパ前へ大量にワークを送ります。
そして、
- 何個並んでも永久停止しないか
- 1個ずつ順番に解放されるか
- リセット後も正常か
を確認します。
こういう、バグが起きやすい状況を意図的に再現することも少しずつ覚えてきました。
不具合② 加工機と優先合流コンベアをつなぐと優先側なのに停止する
次は、設備同士を組み合わせたときの不具合です。
PUZFLOには、優先合流コンベアがあります。
これは2本のラインを1本へまとめる設備ですが、通常の合流とは違い、
優先側にワークがある場合は、優先側を先に流す仕様です。
なので、優先ラインにワークが来ていれば、
基本的にはそのまま通過してほしい。
ところが、加工機の出口を優先合流コンベアへ直接つなぐと、
おかしな動きが発生しました。
優先側なのにワークが止まる
加工機で加工が終了。
↓
ワークが出口へ。
↓
その先は優先合流コンベア。
ここまでは正常です。
しかし、
優先側に接続しているにもかかわらず、
ワークが停止することがありました。
合流側から大量にワークが来ているわけでもありません。
優先側なのだから、本来なら先に流れてほしい。でも止まる。
単体では正常なので分かりにくい
厄介なのが、加工機単体は正常。
優先合流コンベア単体も正常。ということです。
加工機の出口を普通のコンベアへ接続すれば問題ない。
優先合流へ普通のコンベアからワークを送っても問題ない。
でも、加工機 → 優先合流という組み合わせにすると止まる。
こういう不具合が、設備が増えるにつれて出てきました。
ChatGPTには「組み合わせ」を伝える
この場合も、「優先合流コンベアがおかしい」だけではなく、
「加工機出口から優先合流コンベアの優先側へ直接接続した場合だけ、
加工済みワークが停止します。」
と伝えます。
すると確認対象として、
- 加工機から通常搬送へ戻る処理
- 優先合流側の入口判定
- 加工機出口と合流入口の引き継ぎ
- 下流が空いているか確認する待機処理
などが考えられます。
ここでも、設備と設備の境界がポイントになりました。
設備単体ではなく「受け渡し」を直す
Codexには、加工機そのものや優先合流そのものを大きく変更するのではなく、
加工機から優先合流へワークを引き渡す部分を重点的に確認してもらいます。
修正後は、
加工機で処理終了。
↓
優先側へ進入。
↓
合流側にワークがあっても、優先条件に従って先行。
という本来の動作になるか確認します。
不具合③ 識別分岐の後ろにストッパを置くと途中で一時停止する
3つ目は、識別分岐コンベア＋ストッパの組み合わせです。
識別分岐コンベアでは、指定したワークだけを
分岐側へ送り、その他は直進させます。
単体で動かすと問題ありません。
ところが、識別分岐コンベアの直後へストッパを配置すると、妙な動きが発生しました。
分岐コンベアの真ん中でワークが止まる
ワークが識別センサを通過。
↓
直進か分岐かを判定。
↓
分岐コンベアへ進む。
ここで、コンベアの真ん中あたりで一瞬ワークが停止することがあります。
完全停止ではありません。
少し待つと、また動き出します。
なのでゲーム自体は進められます。
ただ、見た目としてかなり不自然です。
「最終的に動くからOK」ではない
以前の自分なら、「止まるけど、最終的には流れるからいいか」
と判断していたかもしれません。
でも第35回からは、
遊んでいて気持ちいいかも見るようになりました。
流れているワークが、理由もなく、カクッと止まる。
これはかなり気になります。
PUZFLOは、スムーズにワークが流れること自体が
気持ちよさにつながるゲームなので、
完全な進行不能バグでなくても直したいところです。
後ろのストッパが前の設備へ影響している？
ChatGPTに、
「識別分岐コンベアの直後にストッパを置くと、
ワークが分岐設備の中央付近で一度停止します。
ストッパなしでは正常です。」
と相談。
この場合も、「ストッパを置いた場合だけ」という条件が重要です。
考えられるのは、識別分岐が次の設備を確認したときに、
ストッパ側の待機状態を早い段階で拾ってしまい、
まだ分岐設備内にいるワークまで待機扱いにしているようなケースです。
これは原因候補の考え方ですが、少なくとも、
「識別分岐が悪い」
「ストッパが悪い」
と単体で見るだけでは分かりません。
「どこから次設備の影響を受けるか」を調整する
Codexには、識別分岐内部を通過中のワークが、
次のストッパの待機状態によって早すぎるタイミングで停止しないかを確認してもらいます。
そして、
分岐設備内部では正常に出口まで搬送。
↓
出口まで到達した段階で、次設備が受け入れ可能か判断。
という流れになるよう修正します。
これで、分岐コンベアの真ん中でカクッと止まる
という違和感をなくしていきます。
最近のバグは「設備同士の境界」で起こることが多い
今回の3つを並べると、ちょっと面白い共通点があります。
- ストッパ
- 加工機
- 優先合流
- 識別分岐
どの設備も、単体ではかなり安定して動いています。
でも、
といった、設備同士が影響し合う場面で不具合が起きています。
これはゲームが少しずつ複雑になってきた証拠でもあります。
「どの設備が悪い？」ではなく「組み合わせ」を見る
この頃から、バグを見つけたときの考え方も少し変わりました。
例えば、識別分岐で止まったから、識別分岐が壊れている。とは限りません。
後ろにストッパを置いたから、初めて起きている可能性があります。
加工機で止まって見えても、本当の原因は次の優先合流かもしれません。
なので最近は、何を置いたときから症状が出た？をかなり意識するようになりました。
これはバグ報告をChatGPTへするときにも役立っています。
ChatGPTへの相談も少し上手くなってきた
最初のころは、「動きません。原因は？」くらいでした。
最近は、
「加工機単体では正常です。」
「通常コンベア接続では問題ありません。」
「優先合流へ直接つないだ場合だけ停止します。」
のように、正常な条件と異常な条件を
一緒に伝えるようになりました。
するとChatGPT側も、原因候補をかなり絞りやすくなります。
これはコードが分からなくてもできます。
AIに全部任せても、バグを見つけるのは自分
AIゲーム開発をしていると、ChatGPTが仕様を考える。
Codexがコードを書く。
では自分は何をするのか？という話になります。
今回改めて感じたのが、「違和感を見つける」のは
自分の重要な仕事ということです。
ストッパの永久停止も、優先側で止まる挙動も、分岐途中の一瞬の停止も、
実際に遊ばなければ分かりません。
特に3つ目なんて、エラーも出ない。ゲームも止まらない。
それでも、「なんか変だな」と感じる。
この感覚はかなり大事だと思います。
「修正しました」だけでは終わらせない
Codexから、
修正しました。
と返ってきても、
そのまま信用して終了にはしません。
同じ条件でもう一度試します。
- 違う向き
- 違うワーク
- 大量投入
- リセット後
- 別設備との組み合わせ
も確認します。
1つ直したことで、別の場所が壊れる可能性もあります。
なので、AIが修正 → 自分がプレイして確認
という役割分担は今後も変わらなそうです。
バグ修正も「試運転→改善」の繰り返し
こうして見ると、PUZFLOの開発そのものも、
ゲーム内容にかなり似ています。
ゲームでは、
ラインを作る。
↓
試運転する。
↓
問題を見つける。
↓
原因を考える。
↓
設備を変更する。
↓
もう一度動かす。
開発では、
機能を作る。
↓
プレイする。
↓
不具合を見つける。
↓
ChatGPTに相談する。
↓
Codexで修正する。
↓
もう一度プレイする。
ほぼ同じです。
コードが分からなくても、バグ修正まで進められた
ゲーム制作を始める前は、バグ修正が一番無理そうだと思っていました。
- エラーコード
- スクリプト
- クラス
- 状態管理
このあたりは、今でも完全には理解していません。
でも、何をしたら、どうおかしくなったかなら説明できます。
自分が症状を見つける。
↓
ChatGPTと原因を整理する。
↓
Codexにコードを確認してもらう。
↓
自分がUnityで再確認する。
という形なら、バグ修正まで進められることが分かりました。
第1回のころを考えると、これもかなり大きな変化です。
不具合が減ったら、また「面白さ」を増やしていく
PUZFLOは、設備が増えてかなり複雑になってきました。
当然、これからも新しい不具合は出てくると思います。
特に今後予定している、
- 2連加工機
- 3連加工機
- 組立機
- ロボットアーム
- クロスコンベア
などが加われば、設備同士の組み合わせはさらに増えます。
でも今回改めて、不具合が出ても修正していける
という感覚はかなり持てるようになりました。
ここからは再び、「正常に動くか？」のその先へ。
PUZFLOをさらに面白くするため、新しい設備が、
新しい悩みや、新しい解き方を生むものになっているか
を意識しながら開発を進めていきます。
次回は「ゲームが重い」をどうするか考える
ここまでPUZFLOでは、設備やワークの種類を増やしながら、
不具合やバグも少しずつ修正してきました。
ただ、ゲームが複雑になってくると、
今度は別の問題が目立ち始めます。
それが、動作の重さです。
ワーク数が増える。
設備が増える。
出荷場も増える。
複数ラインが同時に動く。
こうした状態でプレイしていると、
少しずつFPSが落ちる場面が出てきました。
当然、Steamで販売するなら、
「動く」だけではなく「快適に動く」ことも重要です。
そこで次回、第37回では、PUZFLOの中で
どこに処理負荷がかかっているのかを確認しながら、
AIと一緒にゲームの最適化へ挑戦していきます。
コードが書けない自分でも、
- どこが重いのか
- 何を減らせばいいのか
- どこを改善すればFPSが上がるのか
をChatGPTやCodexと一緒に調べていきます。
次回は、「ゲームを作る」から「快適に動かす」へ。
製品版に近づけるための、また別の課題に進みます。
コメント