# HG changeset patch # User koba # Date 1297760332 -32400 # Node ID d711f469cdb7c9439903989c39c97bca82ff484e # Parent f953f01c58bf3cc012fdef73acb6fa5e443f0f33# Parent 059cb90dc73a78860f1919230a17705cf672e2fe merge branches. diff -r f953f01c58bf -r d711f469cdb7 paper/abstract.tex --- a/paper/abstract.tex Mon Feb 07 16:00:55 2011 +0900 +++ b/paper/abstract.tex Tue Feb 15 17:58:52 2011 +0900 @@ -1,5 +1,26 @@ \begin{abstract} +我々はこれまで家庭用ゲーム機におけるゲームプログラミングをサポートする +オープンな開発フレームワークの研究を行ってきた。 +現在は PlayStation3 上での開発を行なっている。 +ゲームプログラムの特徴はオブジェクトのパラメータなどの流動的な値が多く、 +通常の単体テストのようなテスト手法では十分なテストが行えないことが +挙げられる。また、プレイヤー入力や乱数などの非決定的な要素もゲームの +テストを困難なものにしている。 +また並列環境においては、シーケンシャルに動いていたプログラムを分割化して +並列処理を行っても、逐次実行させたときと同じ動作をするとは限らない。 +オブジェクト同士のデータの同期や、処理の実行順序、生成される乱数の不定化 +など、テストを困難にする要因は多い。 +そこで本研究ではシーケンシャルに動作していたゲームプログラムを Task という +単位に分割し、両方のプログラムが同様の動きをすることが確認できるテスト環境の +構築を目指した。上記に挙げられたプレイヤー入力の固定化や SPE における予測 +可能な乱数の使用、テストを高速に行うためのビデオモードの実装、ゲームの動きが +確認できるログの出力などを行う。 + +構築した環境を用いて実際に分割されたゲームプログラムのテストを行い、 +分割バージョンと新バージョンが同じ動きをするかどうか、分割した際に +バグが紛れ込んでいないかどうか、また新たなビデオモードによるテストの +実行時間はどうか調べ、構築したテスト環境が効果的かどうかを調べる。 \end{abstract} diff -r f953f01c58bf -r d711f469cdb7 paper/appendix.tex --- a/paper/appendix.tex Mon Feb 07 16:00:55 2011 +0900 +++ b/paper/appendix.tex Tue Feb 15 17:58:52 2011 +0900 @@ -3,16 +3,7 @@ \begin{comment} \begin{itemize} -\item 河野真治, 渕田良彦, 宮國渡. 継続を基本とする言語 CbC による分散プログラミング, 日本ソフトウェア科学会第２３回大会(2B-1), September 2006. - -\item 宮國渡, 河野真治. Continuation based C 言語による OS システムコールの意味記述. 情報処理学会第１０５回システムソフトウェアとオペレーティング・システム研究会 (16). April 2007. - -\item 宮國渡, 河野真治, 神里晃. Cell 用の Fine-Grain Task Manager の実装. 情報処理学会第１０８回システムソフトウェアとオペレーティング・システム研究会 (13). April 2008. +\item 小林佑亮, 河野真治, 多賀野海人, 金城裕, GameFrameWork Cerium における Sequential な Game Program の分割と動作の検証, March 2011. -\item オープンソースカンファレンス2006 Okinawa. December 2006. -\item オープンソースカンファレンス2007 Okinawa. November 2007. -\item 第31回 沖縄の産業まつり. October 2007. -\item オープンソースカンファレンス2008 Okinawa. November 2008. -\item ITまつり. January 2009. \end{itemize} \end{comment} diff -r f953f01c58bf -r d711f469cdb7 paper/conclusion.tex --- a/paper/conclusion.tex Mon Feb 07 16:00:55 2011 +0900 +++ b/paper/conclusion.tex Tue Feb 15 17:58:52 2011 +0900 @@ -1,6 +1,44 @@ \chapter{結論} \label{chapter:conclusion} - \section{まとめ} +本稿では Game FrameWork Cerium 上で動作するゲームプログラムに対する +テスト手法、およびテスト環境の構築を行った。ゲームプログラムのような、 +常にオブジェクトのパラメータが変化するプログラムでは通常の単体テストの +ような手法は効果的ではない。また、ゲームにはプレイヤーの入力や乱数といった +バグの再現性を低下させる要因もあり、さらに Cerium のような並列実行環境では +テストはさらに複雑化する。 + +そこで第 5 章において Capture モードと Trace モードによるプレイヤー入力の +固定化を行い、SPE における乱数生成に対する手法の提案、オブジェクト生成時、 +衝突時におけるテストログの出力、さらに画面描画をしないテストモードの実装を +行った。ここで構築したテスト環境を用いて、第 6 章では実際に Task 化した +ゲームのデバッグ、シーケンシャルなバージョンとの比較、提案した乱数生成の +検証、ビデオモードの違いによる実行時間の比較を行った。その結果、シーケン +シャルバージョンとの差異によるバグの発見や乱数生成手法の正しさ、描画しない +ビデオモードによる大幅なテスト速度の向上を確認することが出来た。 + +Cerium においてはシーケンシャルプログラムから分割プログラム、さらには並列 +プログラムといった段階的なプログラミングが推奨されているが、本研究で提案 +したテスト手法では、ゲームの移植時に発生するバグを発見するのに効果的に +働くため、Cerium を用いた段階的なゲーム開発と非常に相性が良いと考えられる。 +また、画面描画を行わなくても、プレイヤー入力の記録とテストログにより、 +バグの発生箇所を特定できるため、描画の遅い環境においても効率的なデバッグを +行うことが出来る。 + \section{今後の課題} -\subsection{Task の依存関係のプロット} -\subsection{プロファイラの実装} +\subsection{コードローディングによる Task Dandy の並列化とデバッグ} +本研究は Fifo 環境においてテストを行ったため、未だに Task Dandy のような +ある程度のボリュームを持ったゲームプログラムの並列実行に対して、 +どの程度効果があるのかわからない。コードローディングにより、Task Dandy を +並列化し、実際にデバッグを行ってみる必要がある。 + +\subsection{メモリアロケータの実装} +本研究はメモリアロケートによるバグに対応していない。特に Cerium は SPE の +LS におけるメモリの管理や、DMA 転送によるデータのコピーなど、メモリに関する +バグが特に発生しやすい環境である。メモリアロケータを実装することによって +こうしたバグの特定も行う必要がある。 + +\subsection{テクスチャや画面描画に関するデバッグ} +今回は描画処理に関するバグには注目しなかった。 +しかし、Cerium にはテクスチャの分割など、描画処理にバグが入り込みやすい +仕様となっている。こうしたバグに対する効果的なデバッグ環境を整えることで +画面描画を正しく行うことができる。 diff -r f953f01c58bf -r d711f469cdb7 paper/dandy.tex --- a/paper/dandy.tex Mon Feb 07 16:00:55 2011 +0900 +++ b/paper/dandy.tex Tue Feb 15 17:58:52 2011 +0900 @@ -1,6 +1,6 @@ -\chapter{Super Dandy} +\chapter{テストに用いるゲームプログラム Super Dandy} -\section{Super Dandy}\label{sec:dandy} +\section{テストプログラムに最適なシューティングゲーム}\label{sec:dandy} Super Dandy は我々が PlayStation でのゲーム開発を行っていた 1998 年に 開発されたシューティングゲームである。PlayStation アーキテクチャの スプライト描画機能を用いて宇宙空間を表現しており、タイトルからゲーム本編中の @@ -29,8 +29,25 @@ 本研究を進めるにあたり、Super Dandy を Cerium の Task で書き換えた Task Dandy を作成した。Task Dandy はできるだけ元の Super Dandy のコード やデータ構造を流用し、比較、テストが容易に行えるように設計した。 +その為、Super Dandy で Move や Collision の処理を行う state\_update() や +collision\_detect() において Move Task や Collision Task を生成している。 +また、obj\_draw() はオブジェクトの描画を行う関数であったが、Task Dandy では +SceneGraph の tree を生成している。そしてゲームの処理を抜け、Cerium の処理に +入ると、さきほど生成した SceneGraph の tree から描画処理を行う 3 つの Task +を生成する(\ref{sec:rendering})。この一連の処理を繰り返すことによって +シューティングゲームである Task Dandy が形成される。(図\ref{fig:taskdandy}) -\subsection{データ構造} +\begin{figure}[h] +\begin{center} +\includegraphics[scale=0.5]{images/taskdandy.pdf} +\end{center} +\caption{Super Dandy と Task Dandy の処理} +\label{fig:taskdandy} +\end{figure} + +\newpage + +\subsection{Super Dandy のデータ構造} データ構造は Super Dandy のものを流用している。Super Dandy では主に以下の ようなデータが存在する。 @@ -52,16 +69,7 @@ これらのデータは オブジェクトの情報として管理されるだけでなく、 その他のオブジェクトの移動や衝突判定時にも使用される。 -\subsection{Task Dandy の Task} - -Task Dandy では オブジェクトの動きや衝突判定をそれぞれ Move Task、Collision -Task として並列に処理させることが出来るように分割している。それぞれの Task は -Super Dandy の Move や Collision が実行されるタイミングで生成され、 -その後処理に必要なデータをセットして各 CPU に送られる。処理を終えた Task は -post\_func により、計算結果をメインメモリ内のデータ領域に反映させ、全ての -Task が終了した時点でゲームの 1 フレームが終了する。 - -\subsection{Property}\label{sec:property} +\subsection{データ転送に用いる Property}\label{sec:property} Task Dandy の Task は処理のために、複数のデータを set\_inData する 必要がある。特に Collision Task に使用するデータはオブジェクト自身の情報の 他にプレイヤーの機体、プレイヤーの出した弾など、種類が多く、全てを set\_in @@ -87,6 +95,8 @@ 追加した。以下のようなコードで状態が遷移する条件に入ると Task ID が 書き換えられる。 +\newpage + \begin{verbatim} static int state6(SchedTask *smanager, void *rbuf, void *wbuf) @@ -111,6 +121,8 @@ } \end{verbatim} +\newpage + 書き換えられた ID は次に Task を生成する際に使用され、別の種類の Task を 生成するようになる。 diff -r f953f01c58bf -r d711f469cdb7 paper/game.tex --- a/paper/game.tex Mon Feb 07 16:00:55 2011 +0900 +++ b/paper/game.tex Tue Feb 15 17:58:52 2011 +0900 @@ -19,7 +19,7 @@ のかチェックするようなテストは向かない。ゲームプログラムは実際にプレイヤーが ゲームをプレイすることが重要なテストとなる。 -\section{プレイヤーの入力}\label{sec:player} +\section{プレイヤーの入力の不定性}\label{sec:player} ゲームプログラムではコントローラーなどのインターフェースにより、 プレイヤーから入力が与えられ、それによってゲーム内のパラメータが変化する。 例えばプレイヤーの操作によりキャラクターが移動する、攻撃するといった事が @@ -30,7 +30,7 @@ こうした事からプレイヤーは制御不能なランダム要素であると考えられ、 ゲームプログラムテストにおけるバグの再現性を低下させている。 -\section{乱数}\label{sec:random} +\section{ゲームにおける乱数の役割}\label{sec:random} ゲームにおける乱数は、オブジェクトの振る舞いに多様性を持たせたり、ランダムな 配置を実現する為に使われ、ゲームのボリュームや面白さを広げる役割を担ってきた。 これは例えば以下のようなコードにより実現される。 @@ -57,7 +57,10 @@ こうした乱数の使用法は特に携帯ゲーム機やコンソールゲーム機のような リソースの限られた環境においては複雑で容量の大きいレベルデータを格納する事が -困難であったため、ゲームの深みを演出する上で用いられてきた。しかしこうした -ランダム性は、テストをする上でバグの再現を困難にする。この問題に対して、 -常に同じ乱数列を生成するように、乱数生成器を無効にするか、定数でシードする -といった手法が考えられる。 +困難であったため、ゲームの深みを演出する上で用いられてきた。 + +\section{テスト環境における乱数に対する対処法} +予測不能な乱数はゲームプレイにおいては面白さを牽引する要因となるが、 +テスト環境では、こうした乱数のランダム性はデバッグをする上でバグの再現を +困難にする。この問題に対しては、乱数生成器を無効にするか、 +常に同じ乱数列を生成するように定数でシードするといった手法が考えられる。 diff -r f953f01c58bf -r d711f469cdb7 paper/images/taskdandy.bb --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/paper/images/taskdandy.bb Tue Feb 15 17:58:52 2011 +0900 @@ -0,0 +1,5 @@ +%%Title: ./images/taskdandy.pdf +%%Creator: extractbb 20100328 +%%BoundingBox: 0 0 555 599 +%%CreationDate: Tue Feb 8 01:02:59 2011 + diff -r f953f01c58bf -r d711f469cdb7 paper/images/taskdandy.pdf Binary file paper/images/taskdandy.pdf has changed diff -r f953f01c58bf -r d711f469cdb7 paper/result.tex --- a/paper/result.tex Mon Feb 07 16:00:55 2011 +0900 +++ b/paper/result.tex Tue Feb 15 17:58:52 2011 +0900 @@ -1,22 +1,25 @@ \chapter{バグ検出実験} \label{chapter:result} \ref{chapter:test} 章で説明したテスト環境を用いて実際に Super Dandy -の OpenGL バージョン、Cerium バージョン、そして Task Dandy の動作が同じに -なるようにデバッグを行った。ここでは、ビデオモードによる実行速度の違いや -カバーしたカバレッジ数、実際に検出されたバグを紹介しながら本研究の評価を -述べる。 +の OpenGL バージョン、Cerium バージョン、そして Task Dandy 上において +テストを実行した。ここでは、出力されたテストログの比較や実際にテスト結果を +用いて行ったデバッグ例、\ref{sec:create_random} 節で提案した Task への乱数の +受け渡しの検証、そしてビデオモードによる実行速度の比較をしながら本研究の +評価を述べる。 -\section{検出方法とデバッグ} -まずはじめに OpenGL バージョンの Super Dandy を Capture モードでプレイし、 -プレイヤーの入力を保存する。これは OpenGL バージョンが Cerium バージョンと -Task Dandy の目標とする動作であるからである。 -次に Cerium バージョン、Task Dandy を Trace モードで実行し、入力データを -読み込ませる。そして各バージョンそれぞれから得られたテストログを考察すること -でバグの原因を特定し、デバッグを行っていく。 +\section{開発した環境における検出方法}\label{sec:how2test} +まずはじめに OpenGL バージョンの Super Dandy を Capture モードでプレイする。 +プレイはエンディングまで行い、プレイヤーの入力データを保存する。 +これは OpenGL バージョンが Cerium バージョンと Task Dandy の目標とする +動作であるからである。次に Cerium バージョン、Task Dandy を Trace モードで +実行し、入力データを読み込ませる。そして各バージョンそれぞれから得られた +テストログを比較、考察し、バグの発生していると思われる箇所を特定する。 \subsection{OpenGL バージョンと Cerium バージョンの比較} OpenGL バージョンと Cerium バージョンのテストから生成されたテストログの -比較を行い、違いがあるかどうか検証した。各テストログのデータは unix コマンド -の wc(word count) コマンドで取り、表 \ref{tb:test_log} にまとめた。 +比較を行い、違いがあるかどうか検証した。ゲームはエンディングまでプレイし、 +Cerium バージョンは画面描画を行わないモードで実行し、出力されたテストログの +データは unix コマンドの wc(word count) コマンドを実行して検証した。 +結果を表 \ref{tb:test_log} にまとめる。 \begin{table}[h] \caption{Super Dandy のテストログの比較} @@ -24,18 +27,16 @@ \hline \hline & 大きさ & 行数 & 単語数 \\ \hline \hline -Super Dandy(OpenGL) & 349486 byte & 3411 & 37194\\ \hline -Super Dandy(Cerium) & 349471 byte & 3411 & 37195\\ \hline +OpenGL & 349486 byte & 3411 & 37194\\ \hline +Cerium & 349471 byte & 3411 & 37195\\ \hline \end{tabular} \label{tb:test_log} \end{table} 2 つのテストログに大きな差異は無いことがわかる。また Super Dandy を 1 回 エンディングまでプレイしたときに作られるテストログの大きさは 約 350 KB と -いうことが分かった。また、以下にこの 2 つのテストログに対して diff を取った -結果を示す。 - -\newpage +いうことが分かった。 +また、以下にこの 2 つのテストログに対して diff を取った結果を示す。 \begin{verbatim} % diff log/demo_log log/dandy_log @@ -55,12 +56,12 @@ できなかった為と思われる。この結果より Super Dandy の OpenGL バージョンと Cerium バージョンの動作は同じであると言える。 -\subsection{データの同期問題の検出} -前述の方法でテストを行い、しばらく実行させていると以下のようなテストログが -取れた。 +\subsection{データの同期問題の検出と対処方法} +\ref{sec:how2test}の方法でテストを行い、しばらく実行させていると以下のような +テストログが取れた。 \begin{verbatim} -super dandy >> +super dandy(OpenGL) >> F64: CREATE [NAME]enemy_greenclab_0 [COORD]x= 120.000000 y= -128.000000 ... F85: DELETE [NAME]enemy_greenclab_0 [COORD]x= 120.000000 y= -44.000000 ... [BULLET]tlv1 = 2, tlv2 = 0 llv1 = 0 @@ -102,9 +103,10 @@ Collision Task 間でデータを同期させるには、Collision Task を同じ CPU に送り、 \ref{sec:global} 節にある global\_alloc で予め衝突判定に必要なパラメータの -領域を LS に確保し、その領域のパラメータで衝突判定を行うと良い。 -その後、共用領域のパラメータの変更をメインメモリ側に反映させることで、 -弾丸の描画などの処理も正しく行うことが出来る。 +領域を LS に確保し、その領域のパラメータで衝突判定を行う方法が考えられる。 +その場合、メインメモリ側のパラメータは獲得した得点や弾丸の描画などの処理に +使われるため、SPE 内に確保された共用領域のパラメータの変更を毎フレーム +メインメモリ側に反映させる必要がある。 (図\ref{fig:collision_reflect}) \begin{figure}[h] @@ -115,7 +117,8 @@ \label{fig:collision_reflect} \end{figure} -実際に +以上のことをふまえて Collision Task を書き換え、再び同じプレイヤー入力で +テストログを出力させた。以下にその結果を示す。 \begin{verbatim} super dandy>> @@ -141,9 +144,11 @@ [BULLET]tlv1 = 2, tlv2 = 0 llv1 = 0 \end{verbatim} -\subsection{Task の依存関係によるバグの検出} +この結果よりオブジェクトの処理の結果がフレーム単位で同じであることがわかる。 +よって共用領域を利用した Collision Task のデータ同期が非常に有効に働いている +ことがわかった。 -\section{乱数生成の検証} +\section{Task への乱数受け渡しによるバグの再現性の検証} \ref{sec:create_random} 節で述べた Task への乱数受け渡しの手法が期待通りの 動きをするかどうか、多数の隕石オブジェクトが生成されるステージで全ての隕石 オブジェクトが生成されるのを観察し、検証した。Super Dandy におけるこの @@ -258,26 +263,66 @@ % \end{verbatim} -上記のように、隕石オブジェクトの座標と速度が一致している。 +以上の結果より、生成された隕石オブジェクトの座標と速度が一致しているのが +わかる。 \section{ビデオモードによる実行時間の比較} \ref{sec:video_none} 節で説明した描画を行わないビデオモードと通常の ビデオモードで実行時間を計測し、その差がどの程度あるのかを比較した。 実行時間の計測には Unix 環境で使用できる time コマンドを使用し、計測モデル -として Cerium バージョンの Super Dandy と Task Dandy を使用した。 -以下が計測結果である。 +として OpenGL バージョン と Cerium バージョンの Super Dandy と Task Dandy +を使用した。以下が計測結果である。先頭の OpenGL バージョンは高さと幅を 1 に +設定したため、ほとんど描画処理を行わない。また、下段 3 つは画面のサイズを +1200 x 800 として実行している。 +(表\ref{tb:test_time}) -\begin{table} +\begin{table}[h] \caption{ビデオモードによる実行時間の比較} -\begin{tabular}{c|c|c} +\begin{tabular}{c|c|c|c|c} \hline \hline - & Super Dandy(Cerium) & Task Dandy \\ \hline \hline -SDL video mode & 1 & 3\\ \hline -NO video mode & 2 & 4\\ \hline + & ユーザー時間 & システム時間 & CPU 使用率 & トータル時間 \\ \hline \hline +OpenGL(w=1,h=1) & 39.67 sec & 27.17 sec & 19 \% & 335.06 sec \\ \hline +Cerium(no video) & 42.40 sec & 24.46 sec & 20 \% & 334.21 sec \\ \hline +Task(no video) & 103.25 sec & 28.74 sec & 34 \% & 385.17 sec \\ \hline \hline +OpenGL & 40.56 sec & 27.60 sec & 20 \% & 336.09 sec \\ \hline +Cerium & 4641.32 sec & 416.23 sec & 99 \% & 5066.11 sec \\ \hline +Task & 6242.26 sec & 486.65 sec & 101 \% & 6643.16 sec \\ \hline \end{tabular} -\label{tb:time_table} +\label{tb:test_time} \end{table} -\section{カバレッジ数} +高さ 1、幅 1 の OpenGL バージョンと Cerium バージョンの no video では +ユーザー時間とシステム時間の大小が逆になっているが、トータル時間は +ほとんど差が無くなっている。これは描画処理を除けば 2 つのバージョンの処理に +ほとんど差がないことが理由と考えられる。一方、 Task Dandy ではユーザー時間が +大きく増加し、それに伴ってトータル時間も増加している。これは Cerium 内での +Task の処理が発生したためと思われる。Task の処理で 50 秒ほどの差がうまれた +のは、今回実験した環境が Fifo であるためで、これを Cell を用いた並列環境で +実行すれば、この処理時間は小さくなると考えられる。 + +次に描画処理を行った時の実行時間だが、OpenGL は描画を行わない場合との差が +ほとんど見られない。一方で Cerium バージョンや Task Dandy では非常に多くの +処理時間が発生している。これは \ref{sec:rendering} 節で述べた 3 つの Task +による描画処理が多くの処理時間を要し、さらに Fifo 環境であるため、Task に +分割した時のオーバーヘッドが膨大になっているからだと思われる。 +\section{評価} +今回構築したテスト環境によって実際に Collision 処理でのデータの同期のバグを +見つけるなど、並列処理におけるバグに対しても効果を得ることができた。 +実行環境は Fifo であったが、Task の定義などの基本的な並列処理の +エミュレーションはできており、ある程度の並列処理のバグを発見することができる +と考えられる。 + +また、プレイヤーの入力を記録することにより、画面の描画が行わなくても、 +内部処理のテストログを残すことが可能となった。このテストログだけでは +直接的なデバッグの手助けにはならないが、旧バージョンのテストログの比較を +行うことで、どのあたりでバグが発生しているのか、ある程度の場所を特定すること +ができる。 + +また、描画を行わないことによって大幅にデバッグの時間を短縮することが +できた。この手法は特に描画処理が遅い環境において効果的であり、効率的な +テスト環境を構築できたのではないかと思われる。 +しかし、この方法では描画処理のバグを見つけることや、ゲーム +の詳細な動きを知覚することはできないため、描画モードとの使い分けが重要だと +考えられる。 diff -r f953f01c58bf -r d711f469cdb7 paper/test.tex --- a/paper/test.tex Mon Feb 07 16:00:55 2011 +0900 +++ b/paper/test.tex Tue Feb 15 17:58:52 2011 +0900 @@ -5,7 +5,7 @@ 確認できるテスト環境を構築する。ここではテスト環境のために追加した機能に ついて説明する。 -\section{Capture モードと Trace モード} +\section{Capture モードと Trace モードの実装} ゲームにおいてプレイヤーからの入力は制御不能なランダム要素であり、 バグを再現することを困難にする(\ref{sec:player}節)。 そこでプレイヤーからの入力を1フレーム毎に記録し、バイナリデータとして @@ -43,7 +43,7 @@ 読み込むことも可能である。これにより、両バージョンで異なる動きが見られた 場合、そこにバグが潜んでいると仮定することができる。 -\section{乱数生成}\label{sec:create_random} +\section{SPE における乱数生成の欠点}\label{sec:create_random} 乱数のランダム性はバグの再現性を落とすが、乱数生成器を無効にするか、定数で シードすることによって再現性を下げることなく、テストすることが出来る (\ref{sec:random}節)。 @@ -87,7 +87,7 @@ \label{fig:ppe_random} \end{figure} -\section{テストログとそのタイミング} +\section{テストログに記述する情報とそのタイミング} シーケンシャルなプログラムを Task に分割して並列実行する際に、新たに発生する バグとして、本研究では以下の項目に焦点を当てた。 @@ -98,7 +98,7 @@ \end{itemize} このうち、Task の定義については、定義される内容が非常に小さい為、Task の -inData や outData を調べるといった従来の単体テストでも十分にテストが可能で +inData や outData を調べるといった従来のテスト手法でも十分にテストが可能で ある。その他の 2 つについては、いずれも衝突判定の際に生じるバグである。 (図\ref{fig:test_log}) @@ -161,7 +161,8 @@ そこでテスト用に画面の描画処理を行わないモードを Cerium に実装した。 これは、Cerium 内で画面のバッファを確保する処理をしている箇所と、描画用の Task を生成する処理をしている箇所をスルーすることで描画処理と無駄なメモリ -確保を行わないビデオモードである。\ref{fig:video_none} +確保を行わずにテストを行うことができるビデオモードである。 +(図\ref{fig:video_none}) \begin{figure}[h] \begin{center} diff -r f953f01c58bf -r d711f469cdb7 paper/thanks.tex --- a/paper/thanks.tex Mon Feb 07 16:00:55 2011 +0900 +++ b/paper/thanks.tex Tue Feb 15 17:58:52 2011 +0900 @@ -1,4 +1,2 @@ \chapter*{謝辞} \addcontentsline{toc}{chapter}{謝辞} - - diff -r f953f01c58bf -r d711f469cdb7 paper/unittest.tex --- a/paper/unittest.tex Mon Feb 07 16:00:55 2011 +0900 +++ b/paper/unittest.tex Tue Feb 15 17:58:52 2011 +0900 @@ -84,7 +84,12 @@ \end{verbatim} このテストの結果、全てのオブジェクトの初期位置と状態遷移した値が正しいことが -分かった。しかし、ここで行った単体テストはゲームにおける、ある一瞬の値の正誤 -しか調べることができない。ゲームプログラムは時間の経過と共にオブジェクトの -パラメータが常に変化するため、こうした一般的な単体テストではゲームのバグを -発見するのは難しい。 +分かった。少なくとも初期化の段階でバグが発生していないことだけは保証された。 + +\section{ゲームプログラムに対する単体テストの欠点} +しかし、ここで行った単体テストは、ゲームにおける、ある一瞬の値が正しいか +どうかを調べるには効果的だが、常にオブジェクトのパラメータが時間の経過と +共に変化するゲームプログラムにおいては有効的とは言えない。 +ゲームプログラムにおけるバグは他のオブジェクトのパラメータとの関係に依る +ところが多く、こうした一般的な単体テストではゲームのバグを発見するのは +難しい。