この間、関係のあった（といっても顔を出して意見する程度）ゲームの発売がポシャってしまいました。
理由は圧倒的なゲーム品質の悪さ。とある昔のゲームのリマスターでしたが、 10fps 程度のカックカクの動き。全くゲームになりません。
「どうしてそんな事になったのか」の理由については色々あるのですが、開発を断念したキッカケはプログラマーの、この一言でした。
フレームレートってなんですか？
あれ？ unity なら使い慣れてるから絶対大丈夫と社長が自信をもって言ってたのに？
ゲーム作ってる人ならさすがに知らないわけが？
え？ 今までホントに知らなかったの？
その場に居合わせた人は顔を見合わせてしまったわけですが、これ、小さい会社だと結構あるみたいですね……。
他の大手会社さんが頼んだ unity 製コンシューマーゲームもそれで何度も頓挫しており、困っている……などと話しておりました。
アプリで意識したことがなかった
彼らの言い分としては、
ターゲット機がここまでスペック低いとは思わなかった
いままで意識したことがなかった
こんなフワッとした意識でもスマフォアプリはどうにかなっていた。でも、ゲーム機だとそうはいかなかった、ということです。
そもそもアプリは無料（が多いの）だけど、ゲーム機の場合は有料ですからね！ 6000 円はたいて買ったゲームがカクカクでまともに動かないのであれば、クレームで炎上することでしょう。
そのアプリ畑の人が、ソーシャルゲームで稼げなくなったのでコンシューマーゲームを手掛ける……安いお金でもいいから経験を……そういった状況でクライアントから仕事を請け、不幸に直面するケースが多くなっているようです。
動画でフレームレートの差を確認する
ゲームは作りたい、興味ある、スマフォで１つくらい作品をアップしたこともある、でもフレームレートなんて知らない、意外とそういう人は多いのかもしれません。
まず、ヌルヌル動く、というのはどういう事か確認してもらうことにします。
ただのキューブですが、この時点でハッキリと差がわかるはずです。
……わからない人は、それがわかるような目を養うところから始めましょう！
60 fps とは「秒間 60 回画面を書き換える」という処理です。15 fps に比べて４倍も画面を書き換えている計算になります。
秒間 60 回書き換える、という事は当然プログラムも秒間 60 ループする余裕がなければいけないという事です。時間にして 1 / 60 = 0.016666 秒、これを超えてしまった場合ゲームは処理落ちを起こし、どんどんとフレームレートが下がってしまいます。
アニメは 24 fps でも平気なのに、なんでゲームは 60 fps なの？
確かに疑問ですね。なぜゲームだけそれほど要求数値が高いのでしょうか？
答えはゲームが「操作する」ものであり、その細やかさが成功の合否に関わっているからです。
次の絵を見てください。
マウスでグリグリと〇を何周か書いた絵です。
60fps の方は１秒に 60 回マウスの座標を取得しているので、プレイヤーの意図通りのなめらかな曲線です。
たいして 15fps は１秒に 15 回しかマウスの座標を取得できないため、点と点の継ぎ目が線になっています。この誤差の分プレイヤーは「あれっ？ なんか思った通りに動かない」という違和感を感じます。
もし、ダークソウルのような一瞬のスキが死を招くようなゲームの場合、15 fps では全くゲームにならないほど、フレームレートの差は大きな欠点としてのしかかってきます。
反面、アプリのような「基本ボタンポチポチする程度」ですむようなゲームは「ちょっともっさり」くらいで、そこまで差を体感できないかもしれません。
おそらく最初に紹介した会社も、unity でポチポチする程度のアプリはたくさん作った経験があったのでしょう。
コンシューマーはコントローラーから異なりますし、より操作性がダイレクト、シビア（かつ、それが面白さ）になるゲーム設計を行うことが多いです。
インディーズであっても、そういうターゲット機種で発売する場合、品質を意識しておくことは大切です。
品質を保つのに必要なこと
最初からターゲット機で動作確認をする
「なにをそんな当たり前のこと」と笑われそうですが、小さい会社の場合、最後までテストしないケースは全然有り得る話です。
PC で動く unity は開発用 PC のスペックの高さから、無理をしていても結構な速度で動作します。毎フレームファイルアクセスとか、余程おかしな事をしない限り 60 fps を切る事はありません。
が、いざターゲット機に移してみると処理落ちに愕然とすることが多いです。
こうならないためにも、初期の段階からパフォーマンス最大の画面を用意し、それがまともに動くかテストを行いましょう。
最初のテストを無事通過したとしても、以後１か月に１回くらいはターゲット機で確認するような癖をつけましょう。
とにかく後回しにしないこと！
無理はしないよう、ゲームの仕様を見直す
最近は多くの AAA タイトルが発売直後に「処理落ちでまともに遊べない」と低評価をつけられるケースが多くなっています。
AAA タイトルなので当然テストをしていますが、何千を超える PC パーツの組み合わせで、何万人もテストプレイヤーを用意したところで、全てを試せるわけではありません。
それでもギリギリを攻めているため、結果として発売直後は「処理落ちで……」となるケースが多くなっているように感じます。
チャレンジしたゆえの低評価、ちょっと可哀想な気もしています。
インディーズ、または小規模で作るゲームについてはそこまでギリギリを攻めない、というのも大事です。
仕様を変えても面白くなる余地はありませんが、処理落ちだけはどんな仕様でもゲーム体験を損なう悪手です。気を付けましょう。
絵のクオリティにこだわりすぎて処理落ち、ローディングが長いなどの問題を起こす場合も多いです。
とにかくギリギリは攻めず、ターゲット機でちょくちょく確認を行いましょう。
ロード時間は気にしなくていいだろう！ と思っているPやD、多すぎ！
少し処理落ちしても問題のないコードを記述する
たとえどんなに頑張ったとしても、一瞬だけ負荷が通常の200%を超えてしまう……といったどうしようもない状況は起こるものです。
回避できればいいのですが、あまりにレアケースだし、それに合わせて全体のクオリティを下げるのは憚られる……。
こういった「一瞬だけ処理落ちが起こる」ケースは絶対起こるものとして考え、普段からそれを解決できるようなコードを書いておきましょう。
Time.deltaTime を使うのは当然として、コリジョン（接触）判定も無理せず大き目にとっておくことで、処理落ちしてもすり抜けが起こらないようにしたり、色々と気を遣っておけばいざ問題があった時も安心です。
販売されている unity 本、Time.deltaTime は紹介してほしい！
さいごに
いかがでしょうか？ 思い当たるフシがありましたら、是非とも改善していきましょう。
……とは書きましたが、処理落ちを修正するのは困難な作業ですし、開発予算規模によっても可能・不可能がありますので、
とにかく最初から最後までずっと意識しておく。見なかったことにしない
だけでも随分と防げると思います。頑張りましょう！
フレームレートを維持するために必要な unity の知識については別の記事で取り上げました。
合わせてご覧いただけますと幸いです。
