前回、第37回では、PUZFLOを遊んでいるうちに、
ゲーム後半になると動作がかなり重くなることに気付きました。
実際にFPSを確認すると、
- ステージ1：約170FPS
- 出荷場20：約30FPS
かなり差があります。
さらに気になったのが、同じSeed・同じ設備配置なのに、
NGになるときとならないときがあるという問題です。
PUZFLOは、同じ条件ならできるだけ同じ結果になってほしいゲームです。
そこで今回は、「何が重いのか調べる → 安全そうなところだけ軽くする」
という流れで、ゲームの最適化に挑戦してみます。
ただし、自分はコードが分かりません。
なので今回も、
- 自分が確認する
- ChatGPTに相談する
- Codexに調べてもらう
- Unityで確かめる
という、いつもの方法で進めました。
そもそも「Profiler」って何？
前回ChatGPTから、まずUnity Profilerで、
何が重いのか確認した方がいいと言われました。
ただ、自分としては、Profilerって何？という状態です。
かなり簡単に言うと、
ゲームの中で「何に時間を使っているか」を調べる機能です。
例えば、
ゲームが重い。
↓
CPUが頑張りすぎている？
GPUが頑張りすぎている？
ワークの処理が多い？
画面表示が重い？
ということを調べられます。
イメージとしては、ゲーム用の健康診断みたいな感じでしょうか。
いきなりコードを直すのではなく、
まず、どこが悪そうなのか調べるために使います。
Unity Profilerを開いてみる
ChatGPTに教えてもらいながら、
Unity上部メニューから、
Window → Analysis → Profiler
を開きました。
難しい設定はしません。
まず見るのは、
くらいです。
そして、出荷場20まで進んだ、一番重い状態で生産を開始します。
ここから、Profilerに表示された数字をChatGPTへ見せながら調べていきました。
最初に分かったのは「CPU側がかなり忙しい」
最初に確認したときは、CPUが1フレームの処理に、約40ms使っていました。
ここで、「40msって何？」となります。
自分もよく分かりませんでした。
ChatGPTに聞くと、60FPSで動かすには、
1フレームを約16.7ms以内で処理する必要があるそうです。
つまり、
- 16.7msくらいなら60FPS
- 33.3msくらいなら30FPS
というイメージ。
今回、CPUが約40ms。
なので、CPU側の処理がかなり重そうということが分かりました。
さらに調べると「ワーク」が重かった
Profilerをもう少し詳しく見ていくと、かなり分かりやすい結果が出ました。
特に重かったのが、Workpiece.Update()です。
名前は難しそうですが、意味としては、
それぞれのワークが毎フレーム行っている処理
くらいで考えればよさそうです。
出荷場20まで進んだ状態では、約180個のワークがありました。
つまり、180個のワークが、それぞれ毎フレーム何かを確認している。
これが積み重なって重くなっていました。
180個あると、小さな処理でも大きくなる
例えば、ワーク1個の処理が少し重いだけなら、
大した問題ではありません。
でも、
- 1個
- 10個
- 50個
- 100個
- 180個
と増えていくと、
同じ処理でもどんどん負荷が大きくなります。
これはかなり分かりやすいです。
PUZFLOでは後半ほど、設備だけでなく、
画面上を流れるワークそのものが増えます。
ステージ1では軽いのに、後半になるほど
急激にFPSが落ちていた理由が、少し見えてきました。
ただし、いきなりワークの動きを変えるのは怖い
ここで、じゃあWorkpieceの処理を軽くしよう！となりそうです。
でも、ChatGPTからは、
いきなりそこを触るのは危険
と言われました。
なぜなら、ワークの処理は、
- 移動
- ワーク同士の間隔
- 渋滞
- ストッパ
- 加工機への進入
- 分岐・合流
など、
PUZFLOのゲーム性そのものに関係しているからです。
ここを大きく変えてしまうと、今まで成立していた
ラインが成立しなくなったり、別の不具合が出る可能性があります。
なので今回は、ゲームの動きに影響しにくいところから直すことにしました。
Codexに「安全そうな無駄」を探してもらう
Codexにコードを確認してもらうと、いくつか、
ゲーム結果にはほとんど関係なさそうな無駄が見つかりました。
一つは、投入機で毎フレーム新しいデータの入れ物を作っていたこと。
もう一つは、表示しないログ用の文章まで毎回作っていたことです。
自分にはコードの内容までは分かりません。
ただ、イメージとしては、
毎回新しいメモ用紙を用意する。
とか、誰にも見せない報告書を毎回作る。みたいな感じです。
必要ないなら、減らした方が軽くなります。
まずは、この2つだけ修正
そこでCodexには、
ワークの動きやゲームルールには触れず、
無駄な処理だけ減らしてください
と依頼しました。
修正したのは主に、
- 毎フレーム新しいListを作らない
- ログを表示しないときは文章も作らない
かなり地味です。
でも今回は、「まず安全なところから」が重要です。
Seedや投入タイミングは変わっていないか？
最適化するときに一番怖いのが、ゲーム結果まで変わってしまうことです。
そこでCodex側でも、ランダム投入の順番などを確認。
900回分の投入間隔を比較して、
同じRandom列になっていることを確認してくれました。
少なくとも、今回の修正で、ランダム投入の結果が
変わってしまったという可能性は低そうです。
それでも本命は「大量のワーク」
もちろん、今回直した部分だけで、
ゲームが突然ものすごく軽くなるわけではありません。
Profilerでは、約180個のワーク処理が、
一番大きな負荷になっていました。
なので、本格的に最適化するなら、
最終的にはここを考える必要があります。
例えば、すべてのワークを確認するのではなく、
近くにいるワークだけ確認するようにできないか。
これはかなり効果がありそうです。
ただし、PUZFLOの渋滞やワーク間隔に直結します。
なので、ここは慎重にした方がいい。
ここでChatGPTから意外な提案
さらに最適化を進めようとしていたところ、
ChatGPTから、
その前にWindows版をBuildして、実際のFPSを確認した方がいい
と言われました。
これが今回、かなり重要でした。
自分が今まで見ていたのは、
Unity Editor上のFPSです。
でも実際にSteamで販売した場合、
プレイヤーはUnity Editorでゲームを遊びません。
普通のWindowsゲームとして遊びます。
つまり、Editorで30FPSだから、製品版も30FPSとは限らない。
そこで、一度Windows版を作ってみることにしました。
初めてWindows版PUZFLOを作ってみる
Unityの、File → Build ProfilesからWindows版を作ります。
今回はSteamへ公開するためではありません。
目的は、Unity Editorの外で性能を確認することです。
普通のWindowsゲームとして、
PUZFLO.exe
を作りました。
そして、Unity Editorを閉じた状態で起動します。
一番重い状態でFPSを確認
テスト条件は、これまで一番重かった、
出荷場1～20をすべて動かす状態。
- 大量の設備。
- 大量のワーク。
- 大きくなった工場。
- かなり重い条件です。
Unity Editorでは、約25～30FPSくらいまで落ちていました。
ではWindows版は？
結果は、約60FPS。
ほとんど60FPSで動いています。
たまに、58。59。くらいになる程度。
あれ？普通に軽い
これはかなり意外でした。
自分は、30FPSしか出ないから、
まだかなり最適化しないとダメだと思っていました。
でも実際にBuildしてみると、ほぼ60FPS。
しかも自分のPCは、
- Ryzen 5 3400G
- メモリ32GB
- 専用グラフィックボードなし
内蔵GPUだけで動かしています。
この環境で、PUZFLO最大規模の工場がほぼ60FPS。
これはかなり安心できました。
Unity Editor自体も結構重かった
ここでようやく、Unity Editorでは、
ゲーム本体だけを動かしているわけではないことに気付きました。
開発中は、
なども同時に動いています。
つまり、ゲーム本体＋開発用ツール
を動かしていたわけです。
Windows版では、ゲームだけ。
だから大きな差が出たようです。
「Editorで重い＝製品版も重い」ではなかった
これは今回、かなり大きな発見でした。
もしWindows版を試さずに、
Editorの30FPSだけを見ていたら、
Workpieceの仕組みを大きく変更したり、
かなり複雑な最適化へ進んでいたかもしれません。
でも、Windows版ではすでに約60FPS。
だったら、リスクの高い大改造をする必要性はかなり下がります。
最初に気になっていたNGも出なくなった
もう一つ、かなり気になっていたことがあります。
今回最適化を始めたきっかけは、処理が重くなると、
同じSeedでもNGになることがあるという問題でした。
そこでWindows版を、そのまま3分程度動かしてみました。
結果、エラーなし。
今までEditorでは、定期的にNGが発生していた条件です。
それがWindows版では、3分間問題なし。
これはかなり良い兆候です。
ただし「完全解決」とはまだ言わない
もちろん、一度3分動いたから、完全に直った！とは言えません。
今後、同じSeed。同じ配置。同じ条件。
で、3回。5回。と繰り返して、
- NGが出ないか
- 生産能力は同じか
- 出荷結果は同じか
- クリア結果は同じか
を確認していく必要があります。
ただ、FPSが安定したWindows版ではエラーが出なかった
というのは、かなり重要な情報です。
大規模な最適化はいったん保留
最初は、ワークの判定方法そのものを変えたり、
ゲーム内部の仕組みを大きく作り直したり、
かなり大規模な最適化も考えていました。
でも、Windows版でほぼ60FPS。
さらに3分間エラーなし。
なら、今はそこまでやる必要はなさそうです。
無理に触って、別のバグを作る方が怖い。
なので、必要以上に最適化しないという判断にしました。
今回やったことは意外とシンプルだった
今回の記事では、
- Profiler
- CPU
- GPU
- GC
- Update
など、少し難しい言葉が出てきました。
でも自分が実際にやったことを簡単にまとめると、
かなりシンプルです。
① ゲームが重いことに気付く
↓
② ChatGPTに相談する
↓
③ Profilerで重いところを見る
↓
④ Codexにコードを調べてもらう
↓
⑤ ゲームに影響しにくい無駄だけ減らす
↓
⑥ Windows版を作る
↓
⑦ 実際に遊んでFPSを確認する
これだけです。
自分でプログラムを読めなくても、この流れなら進められました。
AIに任せても「確認するのは自分」
今回も、ChatGPTが、
ここを確認した方がいい
と教えてくれます。
Codexが、
この処理が無駄になっています
とコードを調べてくれます。
でも、最終的に、本当にゲームが軽くなったか確認するのは自分です。
Windows版を作って、実際にゲームを動かす。
FPSを見る。ワークを見る。NGが出ないか確認する。
ここは今までのバグ修正と同じでした。
「ゲーム最適化」もAIと一緒ならなんとかなった
ゲーム制作を始める前なら、最適化と聞いただけで、
自分には絶対無理そうだと思っていました。
コードを高速化する？
CPU？
GPU？
メモリ？
正直、今でも詳しいことは分かりません。
でも、「ゲームが重い」という症状なら分かる。
そこから、ChatGPTに、
「何を確認すればいい？」
と聞く。
Codexに、
「コード側では何が無駄？」
と調べてもらう。
そして自分でゲームを動かす。
この方法なら、コードが分からなくても、
ある程度までは最適化できました。
まとめ：Windows版ではほぼ60FPSまで確認できた
今回の結果です。
- Unity Editor
- 出荷場20の大規模工場で、約25～30FPS。
- Profiler
- 特に、約180個のワーク処理がCPU負荷の
大きな部分になっていることが分かりました。
- 特に、約180個のワーク処理がCPU負荷の
- Codexで修正
- まずは、不要なList生成不要なログ文字列生成など、
ゲーム挙動に影響しにくい部分だけ軽量化。
- まずは、不要なList生成不要なログ文字列生成など、
- Windows Build
- 同じ大規模工場で、ほぼ60FPS。
- さらに、3分間エラーなし。
という結果になりました。
最初は、「PUZFLO、かなり重くなってきたな……」と思っていました。
でも調べてみると、Unity Editor上で見えていた重さと、
実際のゲームの重さは同じではありませんでした。
今回一番勉強になったのは、「重いからすぐ直す」のではなく、
「まず本当にどこが重いのか確認する」ことです。
そして、必要なところだけ直す。
これもゲーム制作ではかなり大事そうです。
PUZFLOも少しずつ、「ゲームが動く」だけではなく、
Steamで普通に遊んでもらえるゲームへ近づいてきました。
次回は「動くゲーム」から「遊びやすいゲーム」へ
性能面では、かなり安心できる状態になってきました。
ただ、ここで改めてゲーム画面を見てみると、次に気になることがあります。
それが、UIです。
- ゲームは動く。
- 設備も増えた。
- ワークも流れる。
- 出荷場も増えた。
でも情報が増えたぶん、
「どこを見ればいいのか」
「今どんな状態なのか」
「次に何をすればいいのか」
が、少しずつ分かりにくくなってきました。
Steamで販売するなら、ただ正常に動くだけではなく、
初めて遊ぶ人でも迷わず操作できる画面にしていく必要があります。
そこで次回、第39回では、
PUZFLOのゲームUIを本格的に見直していきます。
- 上部バー
- 設備パネル
- 設備情報
- 生産開始ボタン
- 出荷場ゲージ
- ポーズ画面
- 設定画面
- How To Play
- セーブ画面
そしてタイトル画面。
ここまで機能を追加しながら継ぎ足してきたUIを、
「開発中の画面」から「Steamで販売するゲームの画面」へ。
次は、PUZFLOを遊びやすく、分かりやすく、製品らしくする作業に進みます。
コメント