研究目的

本研究では Task に分割されたゲームプログラムがシーケンシャルなバージョンと同じ動作である事を確認できるテスト環境の構築を目的とする。
プレイヤーの入力や乱数などの非決定的な要素を固定化し、バグの再現性を -低下させずにテストを行えるようにする。
動作の同一性を確かめるために必要なパラメータの書き出しを行う
高速なテストを行う為、テストに影響しない範囲で実行時間が大きい処理を -排除する。

CppUnit

xUnit と呼ばれる単体テストのためのフレームワークの内の 1 つ
単体テストとは関数やメソッドなどの比較的小さな単位で行うテストで、 - モジュールへの入力と出力を調べることでそのモジュールが要求された仕様を - 満たしているかをテストする手法
CppUnit は 1 つの事象に対して様々なテストケースを同時にテストできる
羅列したテストケースは一括で実行と結果表示が出来る
しかしこうした単体テストではゲームプログラムのバグを見つけるのは難しい

ゲームオブジェクトに対するテスト

- - - - - -

3 つの SceneGraph ノードを持つ
本体を tree の root として左右のパーツがその子供になっている。
オブジェクトの動き(Move)として左右の平行移動をする
簡単なゲームの例題

ゲームオブジェクトに対するテスト

テスト方法

SceneGraph tree の root のアドレスを取得
そこから tree を辿って各オブジェクトの座標を取得
初期値を入力してオブジェクトの初期化が正しいか調べる

テスト結果

全てのオブジェクトの初期値が正しい事がわかった
初期化の段階でバグが発生していないことが保証された

ゲームに対する単体テストの欠点

単体テストは瞬間的な値の正しさは調べられる
常にオブジェクトのパラメータが変化するゲームには有効的ではない
ゲームのバグは他のオブジェクトのパラメータとの関係により発生するものが -多い
一般的な単体テストではゲームのバグの発見は難しい

ゲームプログラムの特徴

- - - - - -

多数のオブジェクトが存在する
オブジェクト同士が相互に干渉する
プレイヤーの入力やゲームの進行によって新たなオブジェクトが生成される
オブジェクトは他のオブジェクトのパラメータを見て、衝突判定や挙動の変化をする

ゲームプログラムの特徴

プレイヤーの入力がゲームに影響する
遷移する状態が膨大
遷移する状態が仕様の範囲内に収まるかをチェックするテストは向かない
実際にプレイヤーがゲームをプレイするのが重要なテスト

プレイヤーの入力の不定性

プレイヤーの入力は常に非決定的(毎回結果が異なる)
同じ人間が同じゲームの同じ場面をプレイしても全く同じ入力をする可能性 - は極めて低い
プレイヤーは制御不能なランダム要素
テストにおけるバグの再現性を低下させている

ゲームにおける乱数の役割

オブジェクトの振る舞いに多様性を持たせる
ランダムな位置配置に使われる
乱数のランダム性はデバッグをする上でバグの再現を困難にする
対処法としては、乱数生成器を無効にするか、定数でシードする

Cell Broadband Engine

SCE と東芝、IBM によって開発されたCPU
2 thread の PPE(PowerPC Processor Element) と 8 個の - SPE(Synergistic Processor Element)を持つ
各 CPU 間は高速リングバスであるEIB(Element Interface Bus)で - 繋がっている

Game Framework Cerium

SceneGraph: オブジェクトのパラメータやポリゴン情報を tree 構造のノードで管理
Rendering Engine: 3 種類の Task によって並列に描画処理を行う
TaskManager: Task を動的に SPE へ割り振るカーネルとして振舞う

Task Manager

Task と呼ばれる分割されたプログラムを管理する
Task の単位はサブルーチンまたは関数とする。
生成された Task を依存関係を考慮しながら SPE に転送したり、実行する

Task 生成時に使用できる API

- - - - - - - -

create_task	Task を生成する
set_inData	Task への入力データのアドレスを追加
set_outData	Task からの出力先アドレスを追加
set_param	Task に 32 bit の情報を追加
set_post	Task が終了した後に PPE 側で実行される関数を登録

- -

シューティングゲーム SuperDandy

- - - - - -

我々が PlayStation 上でのゲーム開発を行っていた 1998 年に開発
タイトルからゲーム本編中の敵機の登場、ステージクリア、エンディングと - ゲーム的な要素が多い
PlayStation, PlayStation2 Linux, OpenGL と伝統的に移植されてきた

Super Dandy 移植の利点

全 5 ステージという、ある程度のボリュームのあるゲーム
衝突判定やオブジェクト判定、ステージクリアによるシーン切り替えと、基本的なゲームの要素が入っている
動作結果を過去の環境と比較することによる新たな環境のチューニングができる

Super Dandy Cerium version

ゲームプログラムの特徴

最初に Cerium に対応したバージョン
描画処理に Cerium の Rendering Engine を用いており、その箇所のみ - Task で処理される
基本的なゲームの処理は変わらない

Task Dandy(Super Dandy Task version)

- - - - - -

オブジェクトの Move や Collision を Task 化
オブジェクトの描画は SceneGraph tree の形成、Rendering Task の - 生成といった Cerium の描画処理を使用
できるだけ Super Dandy のコードやデータ構造を流用

Task Dandy のデータ構造

player: プレイヤーの操作する機体。xy 座標、残機数、無敵時間、 - コンテニュー回数などを持つ。
CHARACTER: 敵機や敵の弾。xy 座標とその方向の速さ、体力、倒したときのスコア、 - オブジェクトの種類を表すキャラナンバーを持つ。
tama_lv1〜lv3、laser_lv1〜lv3: プレイヤーが撃った弾。xy 座標をもつ。プレイヤーが射撃ボタンを押すと - 弾が配列に格納され、敵に当たるか画面外にいくと消滅する。

データ転送に用いる Property

- - - - - -

必要なパラメータをまとめて Property にコピーして set_inData
複数のデータをまとめることによって Task の inData を簡略化

ステートパターン

- - - - - -

オブジェクトの Move と Collision を行う
オブジェクトが関数ポインタを持ち、そのポインタが示す関数が - Move や Collision の処理を行う
関数ポインタのアドレスを他の関数ポインタのアドレスに書き換え、 - オブジェクトの状態遷移をする
しかし、メモリが独立している SPE 上で状態遷移をする場合、 - ステートパターンで使用した関数ポインタのアドレスは使えない

SPE における状態遷移

- - - - - -

SPE 上では Task の ID を変更
PPE 上で変更された ID を見て次に生成する Task の種類を変更
オブジェクトの状態遷移が成立

目標とするテスト環境

プレイヤーの入力や乱数などの非決定的な要素の固定化
現在動作中の OpenGL バージョンと Cerium バージョン、そして Task Dandy - の動作が同一かどうか確認できるテストログの出力
高速なテスト環境
遷移する状態が膨大
実際にプレイヤーがゲームをプレイするのが重要なテスト
プレイヤーの入力は常に非決定的(毎回結果が異なる)
乱数のランダム性がデバッグをする上でバグの再現を困難にする

Capture モードと Trace モード

プレイヤーからの入力を 1 フレーム毎に記録する
記録した入力をバイナリデータとして書き出す
プレイヤーからの入力を 1 フレーム毎に記録して書き出す
書き出したファイルを読み込むことで過去のプレイヤー入力を再現できる
実行ファイルにオプションとファイル名を付けて起動する
3 つの Super Dandy 全てで使える
旧バージョンの入力を記録し、新バージョンで読み出すことができる
入力が同じでも動作が違えばそこにバグが潜んでいると考えられる

入力を記録するバッファのデータ構造

単方向リスト型のバッファ
Capture モードではバッファが足りなくなると新たなバッファを確保する
Trace モードでは必要なバッファサイズを計算し、あらかじめバッファを確保しておく

- -

- -

SPE における乱数生成

シーケンシャルプログラムでは 1 つの乱数列から順番に乱数を取得
Cell における並列プログラムでは各 SPE 内で独自の乱数列を生成
SPE に送られた Task は SPE 固有の乱数列を使用
SPE 内では依存関係を持たない Task は実行順序が不定
シーケンシャルと並列で異なる結果が出る

- -

- -

SPE 内での予測可能な乱数の使用

@@ -429,77 +104,6 @@

並列処理をすることによって発生するバグ

- - - - -

Task 間のデータの同期による衝突判定のバグ
Task の実行順序の違いによる衝突判定のバグ
Task の実装の違い
主にオブジェクトの衝突判定でバグが発生
衝突時のログを見ることでバグを発見する

出力されるテストログ

-F64: CREATE  [NAME]enemy_greenclab_0  [COORD]x= 120.000000  y= -128.000000
-                                             vx= 0.000000  vy= 4.000000
-F85: DELETE  [NAME]enemy_greenclab_0  [COORD]x= 120.000000  y= -44.000000
-                                             vx= 0.000000  vy= 4.000000
-             [BULLET]tlv1 = 2, tlv2 = 0 llv1 = 0
-

F64, F85: 生成、被弾した時の経過フレーム
CREATE, DELETE: CREATE はオブジェクトの生成、DELETE はオブジェクトの被弾
NAME: オブジェクトの種類と ID

出力されるテストログ

-F64: CREATE  [NAME]enemy_greenclab_0  [COORD]x= 120.000000  y= -128.000000
-                                             vx= 0.000000  vy= 4.000000
-F85: DELETE  [NAME]enemy_greenclab_0  [COORD]x= 120.000000  y= -44.000000
-                                             vx= 0.000000  vy= 4.000000
-             [BULLET]tlv1 = 2, tlv2 = 0 llv1 = 0
-

COORD: オブジェクトの xy 座標と速度
BULLET: その瞬間に画面内に存在した弾丸の数。

Cerium における画面の描画処理

- - - - - -

ビデオモードの選択(SDL, OpenGL)
描画処理を行う画面バッファの領域の確保
ゲーム処理の実行
レンダリング Task による画面バッファへの描画

本研究のテスト環境における描画処理

@@ -517,331 +121,43 @@

描画処理を行わないモード

ビデオモードの選択時に選ぶ
Task を生成する処理をスルーしてゲーム処理を実行

- -

本研究のテスト環境におけるバグの検出方法

OpenGL バージョンを Capture モードでプレイし、入力を記録
Cerium バージョン、Task Dandy を Trace モードで実行
各バージョンで得られたテストログを比較、考察
テストログの違いにより、バグの発生している箇所を特定

- -

OpenGL と Cerium のテストログの比較

- -

- - - -

	大きさ	行数	単語数
OpenGL	349486 byte	3411	37194
Cerium	349471 byte	3411	37195

- -

Cerium バージョンは描画を行わないモードで実行
エンディングまでプレイした入力データを仕様
テストログのデータに unix コマンドの wc(word count) コマンドを実行して検証
各バージョンで得られたテストログを比較、考察

OpenGL と Cerium のテストログの比較

- - - - - -

	大きさ	行数	単語数
OpenGL	349486 byte	3411	37194
Cerium	349471 byte	3411	37195

- -

2 つのログに大きな差は無い
Super Dandy をエンディングまでプレイしたときに得られるテストログの大きさ - は約 350 KB
単語数と大きさに僅かな差

diff によるテストログの比較

-% diff log/demo_log log/dandy_log
-1a2
-> Use Joystick
-3410,3411c3411,3412
-< 83.308451 FPS
-< move: average:49usec, peak:1091usec
----
-> 0.000000 FPS
-> game end
-

表示されているメッセージは OpenGL や Cerium 依存のメッセージ
0.000000 FPS は Cerium 側のメッセージで描画を行わないビデオモードにより - 正しく FPS の計算ができなかったため
wc の単語数はスペース区切りで判別するため、Cerium=6,OpenGL=5
よって両バージョンの動作は同じである

OpenGL バージョンと Task 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
-F96: CREATE  [NAME]enemy_greenclab_1  [COORD]x= 56.000000  y= -128.000000 ...
-F96: CREATE  [NAME]enemy_greenclab_2  [COORD]x= 184.000000  y= -128.000000 ...
-F109: DELETE  [NAME]enemy_greenclab_1  [COORD]x= 56.000000  y= -24.000000 ...
-             [BULLET]tlv1 = 2, tlv2 = 0 llv1 = 0
-F117: DELETE  [NAME]enemy_greenclab_2  [COORD]x= 184.000000  y= 40.000000 ...
-             [BULLET]tlv1 = 2, tlv2 = 0 llv1 = 0
-
-<< task dandy
-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
-F96: CREATE  [NAME]enemy_greenclab_1  [COORD]x= 56.000000  y= -128.000000 ...
-F96: CREATE  [NAME]enemy_greenclab_2  [COORD]x= 184.000000  y= -128.000000 ...
-F109: DELETE  [NAME]enemy_greenclab_1  [COORD]x= 56.000000  y= -24.000000 ...
-             [BULLET]tlv1 = 2, tlv2 = 0 llv1 = 0
-F109: DELETE  [NAME]enemy_greenclab_2  [COORD]x= 184.000000  y= -24.000000 ...
-             [BULLET]tlv1 = 2, tlv2 = 0 llv1 = 0
-

ログからのバグの洗い出し

-super dandy(OpenGL) >>
-F109: DELETE  [NAME]enemy_greenclab_1  [COORD]x= 56.000000  y= -24.000000 ...
-             [BULLET]tlv1 = 2, tlv2 = 0 llv1 = 0
-F117: DELETE  [NAME]enemy_greenclab_2  [COORD]x= 184.000000  y= 40.000000 ...
-             [BULLET]tlv1 = 2, tlv2 = 0 llv1 = 0
-
-<< task dandy
-F109: DELETE  [NAME]enemy_greenclab_1  [COORD]x= 56.000000  y= -24.000000 ...
-             [BULLET]tlv1 = 2, tlv2 = 0 llv1 = 0
-F109: DELETE  [NAME]enemy_greenclab_2  [COORD]x= 184.000000  y= -24.000000 ...
-             [BULLET]tlv1 = 2, tlv2 = 0 llv1 = 0
-

OpenGL では別フレームで死んだ 2 つの敵オブジェクトが Task Dandy では - 同フレームで死亡
この時の弾丸の数が一致
片方が死んだ後、弾丸のオブジェクトの除去がされてない
弾丸データが取れていない、という仮説を立てた

Collision Task 間でのデータの同期

シューティングゲーム SuperDandy

Collision Task を同じ CPU に送る
予め衝突判定に必要なパラメータの領域を確保する
その領域のパラメータで衝突判定を行う
SPE 内で変更されたパラメータをメインメモリ側に反映させる
我々が PlayStation 上でのゲーム開発を行っていた 1998 年に開発
タイトルからゲーム本編中の敵機の登場、ステージクリア、エンディングと + ゲーム的な要素が多い
PlayStation, PlayStation2 Linux, OpenGL と伝統的に移植されてきた

Collision Task の改良後の比較

-super dandy>>
-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
-F96: CREATE  [NAME]enemy_greenclab_1  [COORD]x= 56.000000  y= -128.000000 ...
-F96: CREATE  [NAME]enemy_greenclab_2  [COORD]x= 184.000000  y= -128.000000 ...
-F109: DELETE  [NAME]enemy_greenclab_1  [COORD]x= 56.000000  y= -24.000000 ...
-             [BULLET]tlv1 = 2, tlv2 = 0 llv1 = 0
-F117: DELETE  [NAME]enemy_greenclab_2  [COORD]x= 184.000000  y= 40.000000 ...
-             [BULLET]tlv1 = 2, tlv2 = 0 llv1 = 0
-
-<< task dandy
-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
-F96: CREATE  [NAME]enemy_greenclab_1  [COORD]x= 56.000000  y= -128.000000 ...
-F96: CREATE  [NAME]enemy_greenclab_2  [COORD]x= 184.000000  y= -128.000000 ...
-F109: DELETE  [NAME]enemy_greenclab_1  [COORD]x= 56.000000  y= -24.000000 ...
-             [BULLET]tlv1 = 2, tlv2 = 0 llv1 = 0
-F117: DELETE  [NAME]enemy_greenclab_2  [COORD]x= 184.000000  y= 40.000000 ...
-             [BULLET]tlv1 = 2, tlv2 = 0 llv1 = 0
-

Collision Task の改良後の比較

-super dandy(OpenGL) >>
-F109: DELETE  [NAME]enemy_greenclab_1  [COORD]x= 56.000000  y= -24.000000 ...
-             [BULLET]tlv1 = 2, tlv2 = 0 llv1 = 0
-F117: DELETE  [NAME]enemy_greenclab_2  [COORD]x= 184.000000  y= 40.000000 ...
-             [BULLET]tlv1 = 2, tlv2 = 0 llv1 = 0
-
-<< task dandy
-F109: DELETE  [NAME]enemy_greenclab_1  [COORD]x= 56.000000  y= -24.000000 ...
-             [BULLET]tlv1 = 2, tlv2 = 0 llv1 = 0
-F117: DELETE  [NAME]enemy_greenclab_2  [COORD]x= 184.000000  y= 40.000000 ...
-             [BULLET]tlv1 = 2, tlv2 = 0 llv1 = 0
-

2 つのバージョンのログがフレーム単位で同じ
Collision Task のデータ同期が有効に働いている

Task への乱数受け渡しの検証

Task への乱数受け渡しと検証結果

多数の隕石オブジェクトが生成されるステージで全ての隕石オブジェクトが生成されるのを観察
隕石オブジェクトの初期配置は乱数によるランダム配置
隕石オブジェクト生成後の座標と速度を出力

隕石オブジェクトの実装

-  int sf;
-
-  sf = random() % 4;
-  if((sf == 0) || (sf == 1))
-    {
-      p->x = -35;
-      p->y = random() % (120 - 35);
-      p->vx = (random() % 4 + 1);
-      p->vy = random() % 3 + 1;
-      p->state = chara_state23;
-    }
-  if((sf == 2))
-    {
-      p->x = random() % 290;
-      p->y = -30;
-      p->vx = random() % 3 - 1;
-      p->vy = (random() % 4 + 1);
-      p->state = chara_state23;
-    }
-  if(sf == 3)
-    {
-      .....
-

Task Dandy 側の実装

-    int rand1 = (int)smanager->get_param(0);
-    int rand2 = (int)smanager->get_param(1);
-    int rand3 = (int)smanager->get_param(2);
-    int rand4 = (int)smanager->get_param(3);
-
-    CHARACTER *p = (CHARACTER*)smanager->get_input(rbuf, 0);
-
-      int sf = rand1 % 4;
-      if((sf == 0) || (sf == 1))
-      {
-         p->x = -35;
-	  p->y = rand2 % (120 - 35);
-	  p->vx = (rand3 % 4 + 1);
-	  p->vy = rand4 % 3 + 1;
-      }
-      if((sf == 2))
-      {
-	  p->x = rand2 % 290;
-	  p->y = -30;
-	  p->vx = rand3 % 3 - 1;
-	  p->vy = (rand4 % 4 + 1);
-          .....
-

実行結果

-demolog >>
-[COORD]x= 320.000000  y= 66.000000  vx= -2.000000  vy= 0.000000
-[COORD]x= -35.000000  y= 20.000000  vx= 3.000000  vy= 1.000000
-[COORD]x= -35.000000  y= 36.000000  vx= 3.000000  vy= 2.000000
-[COORD]x= 89.000000  y= -30.000000  vx= 1.000000  vy= 3.000000
-[COORD]x= -35.000000  y= 81.000000  vx= 1.000000  vy= 2.000000
-[COORD]x= 320.000000  y= 8.000000  vx= -4.000000  vy= -1.000000
-[COORD]x= 220.000000  y= -30.000000  vx= 1.000000  vy= 4.000000
-....
-
-<< tdandylog
-[COORD]x= 320.000000  y= 66.000000  vx= -2.000000  vy= 0.000000
-[COORD]x= -35.000000  y= 20.000000  vx= 3.000000  vy= 1.000000
-[COORD]x= -35.000000  y= 36.000000  vx= 3.000000  vy= 2.000000
-[COORD]x= 89.000000  y= -30.000000  vx= 1.000000  vy= 3.000000
-[COORD]x= -35.000000  y= 81.000000  vx= 1.000000  vy= 2.000000
-[COORD]x= 320.000000  y= 8.000000  vx= -4.000000  vy= -1.000000
-[COORD]x= 220.000000  y= -30.000000  vx= 1.000000  vy= 4.000000
-....
-
-% diff demolog tdandylog
-%
-

乱数受け渡しによる実行結果の検証

生成された隕石オブジェクトのパラメータが両バージョンで一致している
Task への乱数受け渡しによるバグの再現性の低下防止は有効である

ビデオモードによる実行時間の比較

実行時間の計測には unix の time コマンドを使用
3 バージョンの描画無しモードを使用(OpenGL は 1x1)
描画ありバージョンは 1200x800 で統一して計測

実行結果

- - + +

	OpenGL(w=1,h=1)	Cerium(no video)	Task(no video)	OpenGL	Cerium	Task
実行時間	335.06 sec	334.21 sec	385.17 sec	336.09 sec	5066.11 sec	6643.16 sec
	OpenGL	Task(no video)	Task
実行時間	336.09 sec	385.17 sec	6643.16 sec

OpenGL バージョンと Cerium バージョンではほとんど差がない
描画処理を除けば 2 つのバージョンには殆ど差がない為と考えられる
TaskDandy では Cerium における Task の処理が発生したため、実行時間が大きく増加したと考えられる

実行結果

- - - -

	OpenGL(w=1,h=1)	Cerium(no video)	Task(no video)	OpenGL	Cerium	Task
実行時間	335.06 sec	334.21 sec	385.17 sec	336.09 sec	5066.11 sec	6643.16 sec

OpenGL では描画無しバージョンとの差がほとんど無い
Cerium バージョンや Task バージョンは劇的に処理時間が増加
Task バージョンは劇的に処理時間が増加
描画処理の Task の処理時間が非常に大きいと考えられる
描画処理の Task に比べればゲームの Task は処理が小さい

@@ -860,14 +176,6 @@

[date:11/02/09]

[date:11/02/18]

Game Framework Cerium を用いたゲームプログラミングにおけるテスト手法の提案

発表内容

研究背景

研究背景・目的

研究目的

CppUnit

ゲームオブジェクトに対するテスト

ゲームオブジェクトに対するテスト

テスト方法

テスト結果

ゲームに対する単体テストの欠点

ゲームプログラムの特徴

ゲームプログラムの特徴

プレイヤーの入力の不定性

ゲームにおける乱数の役割

Cell Broadband Engine

Game Framework Cerium

Task Manager

Task 生成時に使用できる API

シューティングゲーム SuperDandy

Super Dandy 移植の利点

Super Dandy Cerium version

ゲームプログラムの特徴

Task Dandy(Super Dandy Task version)

Task Dandy のデータ構造

データ転送に用いる Property

ステートパターン

SPE における状態遷移

目標とするテスト環境

Capture モードと Trace モード

入力を記録するバッファのデータ構造

SPE における乱数生成

SPE 内での予測可能な乱数の使用

並列処理をすることによって発生するバグ

出力されるテストログ

出力されるテストログ

Cerium における画面の描画処理

本研究のテスト環境における描画処理

描画処理を行わないモード

本研究のテスト環境におけるバグの検出方法

OpenGL と Cerium のテストログの比較

OpenGL と Cerium のテストログの比較

diff によるテストログの比較

OpenGL バージョンと Task Dandy の比較

ログからのバグの洗い出し

Collision Task 間でのデータの同期

シューティングゲーム SuperDandy

Collision Task の改良後の比較

Collision Task の改良後の比較

Task への乱数受け渡しの検証

Task への乱数受け渡しと検証結果

隕石オブジェクトの実装

Task Dandy 側の実装

実行結果

乱数受け渡しによる実行結果の検証

ビデオモードによる実行時間の比較

実行結果

実行結果

今後の課題