現在作っているエンジンは、いくつかのテーマを見据えたうえで作っている。
- C++が使える大抵のプラットフォームに乗せられること。ファイルシステムが無かったり、あっても低速なプラットフォームでも使えること。
- ポーティングレイヤへの個別機能追加が容易にできること。
- スクリプト処理系が抽象化され、タスクコアから独立していること。特定のスクリプト処理系に依存せず、複数種の処理系に対応できること。また新たなスクリプト処理系への対応が容易であること。
- 描画系が明確に分離できること。描画系だけを別のものに差し替えたり、逆に描画系だけを他に転用できるようにすること。
- ゲーム処理系の使用するメモリヒープ領域が、プラットフォームの提供する malloc()/free() に依存せず、ゲームが使用して良い領域をあらかじめ割り当てられること(割り当てられる領域がプラットフォームの malloc() で事前に確保されたものであることは構わない)。
…このうち 1. のプラットフォームについては、過去にSFCのような「直接メモリバスにつながるROM」とか、サターンやPS/PS2など「光学ドライブからのロードはできるがまともにOSが載っているとは言い難い」システムも触ってきたので、そうした環境を意識したもの。もっともこれから先の時代、そんなプラットフォームには滅多にお目にかかれないだろうけど。
それはさておき、古いプラットフォームだけではなく現役のシステムは当然対応しており、現在対応の筆頭格はAndroidとiOSということになるが、これらのデバイスは古いシステムにはなかったモバイル用途ならではの機能要件がある。
- アプリの Pause(中断、background化) / Resume(再開、foreground化) がある。
- デバイスの向きにより、Portrait(縦位置)/Landscape(横位置) が切り替わる(禁止もある)
- システムの状態によって描画環境を破棄されることがある。
1.は普通のアプリでもおなじみなのでイメージしやすいが、バックグラウンドに回されたあと突然アプリを破棄されることもあるので、ゲームによっては進行状況をセーブするなどのフックが無ければならない。
2.は画面のサイズがゲーム動作中に変わる、ということ。これも普通のアプリではお馴染みである。モバイルに限らずWindowsやMacのようなPC環境でウィンドウサイズを変更した場合にも起こりうる。画面比率が変わるので、表示上のレイアウトを変更できるフックが用意されていなければならない。
3.はGPUの描画環境が捨てられるタイミングがわりと頻繁にあるということ。通常CPU側のプログラムは描画用のデータをGPUに転送し、それが保持されていることを前提として動いているわけだが、あるタイミングを境としてGPU環境がリセットされてしまったのにCPU側が転送済みのつもりで動いているような情況が起こりうる。画面が表示されなくなってしまうため、これは正しく対処されねばならない。
なお、Android に関しては、画面の縦横が切り替わる際に 2.と 3.が立て続けに起こる。多くのタイトルは画面の縦横比を固定にして切り替わらないような設定でアプリを動かしているが、プレイ中に縦横を切り替えてゲームを続行できるようなものがあっても良いと思うし、そうした可能性を持たせるためにも対応されねばならない。
まあ、1. と 2. はフックとなる virtual method をタスククラスに持たせて必要ならoverrideしてもらい、イベント発生時に全タスクのそれを呼んで回ればいいし、3はGPU資源を握るクラスを生成/破棄のタイミングでリスト登録/削除して、復元が必要な時にリストを辿ってリカバリ用のmethodを呼んで回ればいい。
だいたいこういうのは「instanceをリスト化して特定methodを呼んで回る」で何とかなるというかｗ
