PUZFLOを開発していて、以前から気になっていた問題がありました。
それが、同じ設備配置・同じ供給タイミングなのに、
エラーが起きるときと起きないときがある。という現象です。
同じ条件で動かしているはずなのに、
あるときは正常に流れる。
でも、もう一度実行すると、ワークが詰まる。
こうした現象について第37回でChatGPTへ相談したところ、
初めて教えてもらったのが、「Tick処理」という考え方でした。
当時は、その後にFPS改善を進め、
Windowsビルド版ではほぼ60FPSで安定して動くようになったため、
『 とりあえず今は大丈夫そう。』
と、Tick処理の導入は一度保留にしていました。
しかし、ゲームを完成に近づけていく中で、
本当にこのままで大丈夫なのか？
という疑問が再び出てきました。
今回は、PUZFLOの生産処理をより安定させるため、
いよいよTick処理を導入していきます。
きっかけは「同じ条件なのに結果が変わる」ことだった
この問題に気付いたのは、第37回です。
PUZFLOでは、投入機から一定のタイミングでワークが供給され、
コンベアや加工機、ストッパなどを通って出荷場まで流れていきます。
そのため、
- 同じSeed。
- 同じ設備配置。
- 同じ供給タイミング。
であれば、基本的には同じ結果になってほしいゲームです。
ところが実際に試していると、正常に生産できる場合もあれば、
同じ条件なのに、途中でワークが詰まってエラーになる場合がありました。
最初は、「どこかの設備にバグがあるのかな？」と思っていました。
でも、毎回必ず発生するわけではありません。
ここが厄介でした。
ChatGPTに相談して初めて「Tick処理」を知った
自分では原因が分からなかったので、
いつものようにChatGPTへ相談しました。
そこで出てきたのが、FPSとゲーム内部の処理タイミングという話でした。
PUZFLOでは画面を表示するだけではなく、
といった大量の処理が動いています。
これらの処理方法によっては、FPSが変化したときに、
「処理が実行されるタイミング」も微妙に変化する可能性があります。
そこでChatGPTから教えてもらった考え方が、Tick処理でした。
当時の自分は、「Tickって何？」という状態です。
Tick処理とは？
自分なりにかなり簡単に理解すると、
画面のFPSとは別に、一定の間隔でゲーム内の処理を進める仕組みです。
例えば、画面が60FPSなら、
1秒間に約60回画面が更新されます。
30FPSなら、約30回です。
もし生産処理まで、「画面が更新されるたびに処理する」
という作りに強く依存していると、PCの負荷によってFPSが変化したときに、
内部の判定タイミングにも差が出やすくなります。
一方、Tick処理では、画面表示とは少し切り離して、
決められた間隔で生産シミュレーションを進めるという考え方にします。
イメージとしては、
FPS ＝ 画面をどれくらい滑らかに表示するか
Tick ＝ 工場内部の時間をどのタイミングで進めるか
という感じです。
自分のようにコードが分からなくても、
これならなんとなく意味が分かります。
第38回ではFPS改善を優先した
第37回でTick処理という考え方を知りましたが、
その時点ではすぐに実装しませんでした。
理由は、まずゲーム自体が重かったからです。
大きな工場を動かすと、
Unity Editor上ではFPSが30前後まで低下していました。
そこで第38回では、UnityのProfilerを使って、
何が重いのか？を調査。
ワークなどの処理を中心に確認し、
大きな変更を避けながら負荷を改善していきました。
さらにWindows版としてビルドして確認したところ、
ほぼ60FPSで安定。この結果を見て、
「製品版で60FPS出るなら、Tick処理は今すぐ入れなくてもいいかな」
と判断しました。
そこで、Tick処理は一度保留にしました。
でも「常に60FPS」とは限らない
その後もPUZFLOの開発を続けていく中で、
一つ気になることがありました。
Windowsビルド版では60FPSで安定していても、
PCがPUZFLOだけを動かしているとは限りません。
例えば自分の場合でも、
といったことがあります。
当然、PCへの負荷が増えれば、
一時的にFPSが低下する可能性があります。
Steamで販売したあとなら、
プレイヤーのPC環境はさらにさまざまです。
高性能なPCもあれば、
最低動作環境に近いPCもあります。
つまり、「60FPSで動けば問題ない」だけでは少し不安になってきました。
PUZFLOでは結果が変わることが致命的
普通のゲームなら、一瞬FPSが下がった。画面が少しカクついた。
という程度なら、大きな問題にならないこともあります。
でもPUZFLOでは事情が少し違います。
PUZFLOは、生産ラインを設計して、その結果を確認するゲームです。
例えば…
- 設備能力は十分。
- ワークの供給間隔も同じ。
- ライン配置も同じ。
なのに、PCが重かったときだけ、ワークが詰まって失敗する。
これでは困ります。
プレイヤーからすると、
が分かりません。
PUZFLOでは、設計した結果に納得できることがかなり重要です。
だからこそ、FPSの変化によって結果まで変わる可能性は、
できるだけ減らしたいと思いました。
そこでTick処理について改めて相談
以前は保留にしていたTick処理ですが、
今回あらためてChatGPTへ相談しました。
相談した内容はシンプルです。
Windows版では60FPSで安定している。
でも録画や他アプリの負荷でFPSが落ちる可能性はある。
そのときに生産結果まで変わるのは避けたい。
PUZFLOにTick処理を導入する価値はある？
というものです。
PUZFLOのような生産シミュレーションでは、
描画FPSと生産ロジックをできるだけ分けた方が安定させやすい
という方向になりました。
そして今回は、Tick処理を正式に導入することにしました。
目的はFPSを上げることではない
ここは、自分も最初に少し勘違いしそうになったところです。
Tick処理を導入する目的は、FPSを60から120にすることではありません。
今回の目的は、生産処理を安定させることです。
画面が60FPSでも、50FPSでも、一時的に30FPSになっても、
できるだけ、同じ条件なら同じ生産結果になる状態を目指します。
つまり、描画の安定ではなく、シミュレーションの安定のための変更です。
すべてをTick処理にすればいいわけではない
ここでも、「じゃあ全部Tickで動かせばいいのでは？」
となりそうですが、そう単純でもありません。
例えば、
などは、画面表示と関係が深い処理です。
一方、
などは、PUZFLOのゲーム結果に直接関係します。
そこで、結果に影響する生産処理を中心にTickへ寄せるという考え方で進めます。
Codexには「大改造」ではなく段階的に依頼
実は、第37回でTick処理の存在を知ったとき、
すぐに導入しなかった理由がもう一つあります。
それが、既存のゲームへの影響が心配だったことです。
Tick処理という言葉だけを見ると、
ゲーム全体の仕組みを作り直すような印象があります。
自分も、
「今のゲームを全部壊して作り直すことにならない？」
と少し不安でした。
PUZFLOには、すでに多くの設備が実装されています。
コンベアや加工機だけでなく、ストッパ、分岐・合流など、
それぞれが連携して動いています。
そのため、内部の処理方法を変更すると、
今まで正常に動いていた設備にまで不具合が発生する可能性があります。
第37回の時点では、こうしたリスクも考えて、
まずはFPS改善を優先することにしました。
そして第38回では、Windowsビルド版でほぼ60FPSを維持できたため、
Tick処理の導入は保留にしていました。
しかし、今回は状況が少し違います。
Steamでの販売を考えると、プレイヤーごとにPC環境は異なります。
画面録画や他のアプリの影響でFPSが低下することもあります。
そうした状況でも、同じ条件なら同じ生産結果になるゲームを目指したいと考えました。
そこで今回は、ChatGPTと相談したうえで、Codexに、
「既存のゲーム仕様をできるだけ変えず、段階的にTick処理へ移行する」
という方針で依頼することにしました。
特に確認したいのは、
- 投入タイミング
- ワークの供給間隔が変わらないか
- コンベア搬送
- ワークの速度や間隔が正常か
- 加工機
- 加工時間や処理能力に影響がないか
- ストッパ
- 停止・開放のタイミングが正常か
- 分岐・合流
- ワークの振り分けや優先順位が正常か
- ロボットアーム
- 受け渡しや搬送時間が正常か
- 出荷判定
- 出荷数や成功・失敗の結果が変わらないか
一度にすべて変更するのではなく、影響する部分を確認しながら進めます。
Tick処理を導入すること自体が目的ではありません。
大切なのは、これまで作ってきた設備の動きを維持しながら、
生産シミュレーションの安定性を高めることです。
第37回ではリスクを考えて見送ったTick処理ですが、
今回はゲームの完成度を上げるために、改めて取り組んでいきます。
一番確認したいのは「低FPSでも同じ結果になるか」
Tick処理を導入したあとに重要なのは、動いたかどうかだけではありません。
今回確認したいのは、FPSを変えても結果が変わらないか？
例えば、
などで同じラインを動かして、同じ数のワークが供給され、
同じタイミングで加工され、同じ結果になるかを確認します。
これまでの、「たまたま成功したからOK」ではなく、
再現性を見るという確認が重要になってきます。
AIゲーム開発でも「動く」だけでは終わらない
ゲーム開発を始めたころは、
それだけでかなり嬉しかったです。
でも、Steamで販売するところまで来ると、
要求するものも変わってきました。
今は、動くだけではなく、毎回安定して動くことも必要です。
しかも今回のTick処理は、プレイヤーから見ても、
ほとんど変化が分からない部分です。
派手な新設備でもありません。
画面が豪華になるわけでもありません。
でも、こういう見えない部分が、
ゲームとしての信頼性
につながるのだと思います。
第49回まとめ｜FPSではなく「生産結果」を安定させる
今回、第49回では、以前から保留にしていたTick処理を導入することにしました。
きっかけは第37回で見つかった、
「同じ条件なのにエラーが出るときと出ないときがある」という問題です。
第38回ではFPS改善を行い、
Windowsビルド版でほぼ60FPSを維持できるようになったため、
その時点ではTick処理を保留にしていました。
しかし、
などによって、FPSが低下する可能性を完全になくすことはできません。
PUZFLOでは、同じ設計なら、できるだけ同じ結果になることが重要です。
そこで今回は、画面を描くFPSと、生産ラインを進める処理を分ける
という考え方で、Tick処理を取り入れることにしました。
ゲーム画面としては地味な変更です。
でも、プレイヤーが安心して「自分の設計結果」を評価できるゲームにする
ためには、かなり重要な改善だと思っています。
設備を増やすだけではなく、
こうしたゲーム内部の仕組みも少しずつ整えながら、
PUZFLOをSteamで遊んでもらえるゲームへ仕上げていきます。
コメント