Mercurial > hg > Papers > 2011 > koba-master
view paper/conclusion.tex @ 19:c20d7b72cd4a default tip
finish?
author | koba <koba@cr.ie.u-ryukyu.ac.jp> |
---|---|
date | Fri, 18 Feb 2011 05:39:37 +0900 |
parents | 028ed9741872 |
children |
line wrap: on
line source
\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 にはテクスチャの分割など、描画処理にバグが入り込みやすい 仕様となっている。こうしたバグに対する効果的なデバッグ環境を整えることで 画面描画を正しく行うことができる。