\chapter{結論} \label{chapter:conclusion}
\section{まとめ}
本稿では Game FrameWork Cerium 上で動作するゲームプログラムに対する
テスト手法、およびテスト環境の構築を行った。ゲームプログラムのような、
常にオブジェクトのパラメータが変化するプログラムでは通常の単体テストの
ような手法は効果的ではない。また、ゲームにはプレイヤーの入力や乱数といった
バグの再現性を低下させる要因もあり、さらに Cerium のような並列実行環境では
テストはさらに複雑化する。

そこで第 5 章において Capture モードと Trace モードによるプレイヤー入力の
固定化を行い、SPE における乱数生成に対する手法の提案、オブジェクト生成時、
衝突時におけるテストログの出力、さらに画面描画をしないテストモードの実装を
行った。ここで構築したテスト環境を用いて、第 6 章では実際に Task 化した
ゲームのデバッグ、シーケンシャルなバージョンとの比較、提案した乱数生成の
検証、ビデオモードの違いによる実行時間の比較を行った。その結果、シーケン
シャルバージョンとの差異によるバグの発見や乱数生成手法の正しさ、描画しない
ビデオモードによる大幅なテスト速度の向上を確認することが出来た。

Cerium においてはシーケンシャルプログラムから分割プログラム、さらには並列
プログラムといった段階的なプログラミングが推奨されているが、本研究で提案
したテスト手法では、ゲームの移植時に発生するバグを発見するのに効果的に
働くため、Cerium を用いた段階的なゲーム開発と非常に相性が良いと考えられる。
また、画面描画を行わなくても、プレイヤー入力の記録とテストログにより、
バグの発生箇所を特定できるため、描画の遅い環境においても効率的なデバッグを
行うことが出来る。

\section{今後の課題}
\subsection{コードローディングによる Task Dandy の並列化とデバッグ}
本研究は Fifo 環境においてテストを行ったため、未だに Task Dandy のような
ある程度のボリュームを持ったゲームプログラムの並列実行に対して、
どの程度効果があるのかわからない。コードローディングにより、Task Dandy を
並列化し、実際にデバッグを行ってみる必要がある。

\subsection{メモリアロケータの実装}
本研究はメモリアロケートによるバグに対応していない。特に Cerium は SPE の
LS におけるメモリの管理や、DMA 転送によるデータのコピーなど、メモリに関する
バグが特に発生しやすい環境である。メモリアロケータを実装することによって
こうしたバグの特定も行う必要がある。

\subsection{テクスチャや画面描画に関するデバッグ}
今回は描画処理に関するバグには注目しなかった。
しかし、Cerium にはテクスチャの分割など、描画処理にバグが入り込みやすい
仕様となっている。こうしたバグに対する効果的なデバッグ環境を整えることで
画面描画を正しく行うことができる。