16msという基準値

一般的なアプリやツール、もしくはWeb サービスといったものを作成している方々と我々ゲームを作っている人間では多くの共通点、共通認識や共通スキルなどがありますが、もちろん異なる点もあります。

そのうちの1 つは、フレームを強く意識しているかどうかです。

フレームというのは要するにモニタ上に描画される1 画面のことで、仕組み上はテレビもPC も常に画面を描き換えています。ただ、脳が前の絵を記憶しているため連続しているように見えるというだけです。アニメが実はパラパラマンガの仕組みであることと同じです。その1 描画あたりを1 フレームと呼び、1 フレームあたりにかかる時間が短いほど理論上は滑らかに見えるわけです。そして、現在ゲームにおいて標準となっているのはだいたい1 秒間あたり60 回の描画（60 フレーム）、つまり1 フレームあたり1,000ms/60 ＝16.7ms で画面を描き換えています。

ビジネスやコミュニケーションで使用するようなアプリにおいて、画面に表示されるモノが頻繁に変化することは多くありません。少なくとも、ゲームほどではないです。なので、フレームを意識することはあまりなく、プログラミングする上でもイベントドリブンで問題ありません。「ユーザーがこの動作をしたら、このメソッドを呼ぶ→画面を描き換える（それ以外は何もしない）」というかたちで良いのです。

ありがたいことに私はGoogle Developer Expert のAndroid 担当として、Google による開発者向けイベントやコミュニティの運営をたくさんさせていただいていますが、Android 発表後初期の頃は「Java 歴はそこそこあるんだけどゲーム開発は未経験」といった人が多く、「思うような速度が出なくて困っている」というような質問を受けていました。よくよくプログラムコードを見てみると、「画面上に多数配置され高速に動く（敵の弾など）オブジェクト1 つ1 つをイベントハンドラが取れるかたちでインスタンス化する」といったことをゲームがまさに進行している最中に行っており、これでは遅くなるのは当然なのです。しかし、コードのロジックとしては何ら間違っていない。ジャンルにもよりますが、ゲームに適合したかたちでの実装ではなかったわけです。

レースゲームやRTS などを思い出してもらえるとわかりやすいかもしれませんが、ゲームは一瞬で状況が変化し、そして変化し続けるものが多く、ユーザーがアクションを起こそうが起こすまいがゲーム内は刻々と変化します。それには、1 フレームごとに「次に何を描画するのか」を考え、より滑らかに見えるようにすることによって、遊んでくれる方が楽しんでもらえる一要素足りうるのです。

もちろんそれは、描画に限った話ではなく、プレイヤーに対してフィードバックを行うことは基本的に1 フレームごとに計算し、処理をします。音声の再生であったり、入力判定であったり、あるいはサーバーへの通信であったり。入力判定や描画の遅延はプレイヤーに敏感に伝わってしまうため、センシティブに処理しなければならないです。ゆえに、より迅速に画面に反映させるために、次のフレーム（描画）までにプレイヤーが入力した結果を処理し終えている必要があるので、例えばプレイヤーが行った操作（入力）によって自キャラがどう動き、その結果画面がどうなったか（衝突判定など）を処理した全ての結果を反映した状態で画面を描画する、という処理を毎回、16ms ごとに続けます。

どれだけ重い処理も、ゲームを快適に遊んでもらうために可能な限り早く処理をする、その単位がフレームであり、現状は16ms というわけです。ネットワークを利用するときは1 フレームでは難しいので数フレーム利用することはありますが、あくまで単位はここにあります。

エンジニアとしては世界をフレーム単位で分割し、またゲーム制作者としてはフレームに分割したパーツを組み上げて、遊んでくれる人の心に届く世界を作っています。