Mercurial > hg > Papers > 2011 > koba-master

comparison poster/master-lt.html @ 19:c20d7b72cd4a default tip

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
finish?
author koba <koba@cr.ie.u-ryukyu.ac.jp>
date Fri, 18 Feb 2011 05:39:37 +0900
parents a5fb2dea1c60
children
comparison
equal deleted inserted replaced
18:a5fb2dea1c60 19:c20d7b72cd4a
58 などの非決定的な要素が多いことが挙げられる。</li> 58 などの非決定的な要素が多いことが挙げられる。</li>
59 <br> 59 <br>
60 <li>本研究では Task に分割されたゲームプログラムがシーケンシャルなバージョン 60 <li>本研究では Task に分割されたゲームプログラムがシーケンシャルなバージョン
61 と同じ動作である事を確認できるテスト環境の構築を目的とする。</li> 61 と同じ動作である事を確認できるテスト環境の構築を目的とする。</li>
62 </ul></font> 62 </ul></font>
63 <center>
64 <img src="images/cell.png" width=350 height=150/>
65 </center>
66 </div> 63 </div>
67 64
68 <div class="slide"> 65 <div class="slide">
69 <h1>ゲームプログラムの特徴</h1> 66 <h1>並列処理をすることによって発生するバグ</h1>
70 <ul class="simple"> 67 <table>
71 <li>遷移する状態が膨大</li> 68 <tr>
72 <li>実際にプレイヤーがゲームをプレイするのが重要なテスト</li> 69 <td><ul>
73 <li>プレイヤーの入力は常に非決定的(毎回結果が異なる)</li> 70 <li>Task の実行順序の違いによりバグが発生</li>
74 <li>乱数のランダム性がデバッグをする上でバグの再現を困難にする</li> 71 <li>Task 間のデータの同期による衝突判定のバグ</li>
75 </ul> 72 <li>Task の実装の違い</li>
76 </div> 73 <li>オブジェクトの生成時、衝突時にゲームの状態が遷移する</li>
77 74 <li>オブジェクトの生成時、衝突時のログを見ることでバグを発見する</li>
78 <div class="slide"> 75 </ul></td>
79 <h1>Capture モードと Trace モード</h1> 76 <td>
80 <ul class="simple"> 77 <img src="images/test_log.png" width=350 height=300/>
81 <li>プレイヤーからの入力を 1 フレーム毎に記録して書き出す</li> 78 </td>
82 <li>書き出したファイルを読み込むことで過去のプレイヤー入力を再現できる</li> 79 </tr>
83 <li>旧バージョンの入力を記録し、新バージョンで読み出すことができる</li> 80 </table>
84 <li>入力が同じでも動作が違えばそこにバグが潜んでいると考えられる</li>
85 </ul>
86 </div> 81 </div>
87 82
88 <div class="slide"> 83 <div class="slide">
89 <h1>SPE 内での予測可能な乱数の使用</h1> 84 <h1>SPE 内での予測可能な乱数の使用</h1>
90 <table> 85 <table>
91 <tr> 86 <tr>
92 <td><ul class="simple"> 87 <td><ul class="simple">
93 <li>あらかじめ PPE 内で乱数列を生成しておく</li> 88 <li>シーケンシャルプログラムでは 1 つの乱数列から順番に乱数を取得</li>
94 <li>inData として Task に渡す</li> 89 <li>Cell における並列プログラムでは各 SPE 内で 独自の乱数列を生成</li>
95 <li>Move Task や Collision Task の生成タイミングは Super Dandy の 90 <li>シーケンシャルと並列で異なる結果が出る</li>
96 Move や Collision のタイミングと同じ</li> 91 <li>PPE 内で乱数を生成し、Task に渡して計算させる</li>
97 <li>Super Dandy と同じ乱数が使用できる</li> 92 <li>シーケンシャルと同じ乱数が使用できる</li>
98 </ul></td> 93 </ul></td>
99 <td> 94 <td>
100 <img src="images/ppe_random.png" width=400 height=300/> 95 <img src="images/cell.png" width=300 height=200/>
101 </td> 96 </td>
102 </tr> 97 </tr>
103 </table> 98 </table>
104 </div> 99 </div>
105 100
106 <div class="slide"> 101 <div class="slide">
107 <h1>本研究のテスト環境における描画処理</h1> 102 <h1>Capture モードと Trace モード</h1>
108 <table>
109 <tr>
110 <td><ul class="simple">
111 <li>プレイヤーの入力の自動化により、プログラムを実行するだけでテストが可能</li>
112 <li>描画処理が不要となる</li>
113 <li>描画用 Task の生成を行わない事により、テストの高速化ができる</li>
114 <li>また、画面バッファの確保も不要</li>
115 </ul></td>
116 <td>
117 <img src="images/video2.png" width=300 height=300/>
118 </td>
119 </tr>
120 </table>
121 </div>
122
123 <div class="slide">
124 <h1>シューティングゲーム SuperDandy</h1>
125 <table>
126 <tr>
127 <td><ul class="simple">
128 <li>我々が PlayStation 上でのゲーム開発を行っていた 1998 年に開発</li>
129 <li>タイトルからゲーム本編中の敵機の登場、ステージクリア、エンディングと
130 ゲーム的な要素が多い</li>
131 <li>PlayStation, PlayStation2 Linux, OpenGL と伝統的に移植されてきた</li>
132 </ul></td>
133 <td>
134 <img src="images/dandy.png" width=300 height=250/>
135 </td>
136 </tr>
137 </table>
138 </div>
139
140 <div class="slide">
141 <h1>Task への乱数受け渡しと検証結果</h1>
142 <ul class="simple"> 103 <ul class="simple">
143 <li>多数の隕石オブジェクトが生成されるステージで全ての隕石オブジェクトが 104 <li>プレイヤーからの入力を 1 フレーム毎に記録する</li>
144 生成されるのを観察</li> 105 <li>記録したファイルを読み込むことで過去のプレイヤー入力を再現できる</li>
145 <li>隕石オブジェクトの初期配置は乱数によるランダム配置</li> 106 <li>旧バージョンの入力を記録し、新バージョンで読み出すことができる</li>
146 <li>隕石オブジェクト生成後の座標と速度を出力</li> 107 <li>非決定的なプレイヤー入力を固定することができる</li>
147 <br>
148 <li>生成された隕石オブジェクトのパラメータが両バージョンで一致している</li>
149 <li>Task への乱数受け渡しによるバグの再現性の低下防止は有効である</li>
150 </ul>
151 </div>
152
153 <div class="slide">
154 <h1>実行結果</h1>
155 <table border="1" cellspacing="0">
156 <tr><td></td><th>OpenGL</th><th>Task(no video)</th><th>Task</th></tr>
157 <tr><th>実行時間</th><td>336.09 sec</td><td>385.17 sec</td><td>6643.16 sec</td></tr>
158 </table>
159 <ul class="simple">
160 <li>Task バージョンは劇的に処理時間が増加</li>
161 <li>描画処理の Task の処理時間が非常に大きいと考えられる</li>
162 <li>描画処理の Task に比べればゲームの Task は処理が小さい</li>
163 </ul> 108 </ul>
164 </div> 109 </div>
165 110
166 <div class="slide"> 111 <div class="slide">
167 <h1>結論</h1> 112 <h1>結論</h1>
168 <h2>本研究では並列環境におけるゲームプログラムのテスト手法を提案した</h2> 113 <h2>本研究では並列環境におけるゲームプログラムのテスト手法を提案した</h2>
169 <ul class="simple"> 114 <ul class="simple">
170 <li>衝突判定時のテストログ出力によるデバッグは OpenGL バージョンと Task 115 <li>衝突判定時のテストログ出力によるデバッグは OpenGL と Task Dandy の
171 Dandy の実行結果が同じであることから、効果的であった</li> 116 実行結果が同じであることから、効果的であった</li>
172 <li>Task への乱数受け渡しによるバグの再現性は 同様にして有効であることが 117 <li>Task への乱数受け渡しによって逐次実行、並列実行で使用する乱数を
173 わかった</li> 118 同じものにした</li>
174 <li>描画をしないビデオモードによるテスト時間の高速化は、描画をする場合に 119 <li>入力の自動化により、描画を行わずにテストを行ったところ、
175 比べて 非常に効果があった</li> 120 テスト時間を短縮することが出来た</li>
176 </ul> 121 </ul>
177 </div> 122 </div>
178 123
179 </div> 124 </div>
180 </body> 125 </body>