サッカーシミュレーションプログラムの作成

卒業論文
サッカーシミュレーションプログラムの作成
安部ももこ
学籍番号 00251426
2005 年 2 月 10 日
奈良女子大学理学部
情報科学科
サッカーシミュレーションプログラムの作成∗
安部ももこ
学籍番号 00251426
内容梗概
RoboCup は、ロボット工学と人工知能の融合、発展のために自律移動ロボット
によるサッカーを題材として日本の研究者らによって提唱され、毎年世界大会、
並びにジャパンオープンが開催されている。RoboCup は実際のロボットを使って
サッカーゲームを行うリーグの他に、これをコンピュータでシミュレートするシ
ミュレーション部門も行われている。シミュレーション部門ではロボットの実機
を使うことなく、コンピュータ上の仮想フィールドで、それぞれ異なった人工知
能プログラミングされた 11 対 11 のバーチャルロボットが 10 分間のサッカーゲー
ムを行う。
RoboCup シミュレータは、動的かつ不規則に状況変化する中、複数プレイヤー
が強調するマルチエージェント環境において競技することを可能にするシミュレー
ションシステムであり、その中心を担うサッカーサーバーがクライアント（プレ
イヤー）と通信するクライアント・サーバーシステムとして動く。
本研究では、RoboCup のサッカーサーバーのもとサッカーの試合を行うプロ
グラムを作成することを目標として、プレイヤー (クライアントプログラム) の取
るべき戦略や陣形について調べた。ゲームを行うには不確実性を持つセンサ情報
や動的に変化する状況下で、プレイヤーが適宜状況判断を下し、自律かつ協調性
をもって行動するようなプログラムを作成する必要がある。
プレイヤーの状況 (ボールとの関係) とプレイヤーが取るべき動作 (シュート・
パス・ドリブル) をどのように選択すべきか、プログラムを作成し、実際に試合
をさせることによって結果を調べた。
∗
奈良女子大学理学部情報科学科卒業論文, 2005 年 2 月 10 日.
i
目次
第 1 章序論
1
第 2 章 RoboCup
3
2.1
RoboCup のリーグ . . . . . . . . . . . . . . . . . . . . . . . . . .
3
2.2
RoboCup サッカー . . . . . . . . . . . . . . . . . . . . . . . . . .
4
2.3
RoboCup の歴史 . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
第 3 章サッカーサーバー
7
3.1
サーバーとクライアントの関係 . . . . . . . . . . . . . . . . . . .
7
3.2
サーバーからのセンサ情報
. . . . . . . . . . . . . . . . . . . . .
8
3.2.1
視覚情報 : Visual Sensor
. . . . . . . . . . . . . . . . . .
8
3.2.2
聴覚情報 : Audio Sensor . . . . . . . . . . . . . . . . . . .
10
3.2.3
感覚情報 : Body Sensor . . . . . . . . . . . . . . . . . . .
11
3.3
soccermonitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
3.4
主要コマンド . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
3.5
試合全体の流れ . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
3.6
ルール . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
第 4 章 UvA Trilearn 2003
15
4.1
U v A Trilearn 2003 のクラス構成 . . . . . . . . . . . . . . . . .
15
4.2
WorldModel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
4.3
BasicPlayer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
4.4
BasicCoach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
第 5 章サッカープログラム
22
5.1
Keeper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
5.2
Passer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
5.3
Interceptor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
5.4
Receiver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
5.5
Passive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
ii
5.6
5.7
実行結果 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
5.6.1
UvA Trilearn 2003 . . . . . . . . . . . . . . . . . . . . . .
27
5.6.2
パスの追加 . . . . . . . . . . . . . . . . . . . . . . . . . .
29
5.6.3
ドリブルの追加
. . . . . . . . . . . . . . . . . . . . . . .
30
5.6.4
全体として動かした時の結果（パス、ドリブルの追加）
.
31
. . . . . . . . . . . . . . . . . . . . . . . . .
32
実行結果からの考察
第 6 章まとめ
34
謝辞
36
参考文献
37
iii
図目次
2.1
RoboCup のリーグ . . . . . . . . . . . . . . . . . . . . . . . . . .
4
3.1
サーバーとクライアントの関係 . . . . . . . . . . . . . . . . . . .
9
3.2
シミュレーションにおける旗とライン
. . . . . . . . . . . . . . .
11
5.1
キーパーの動作 . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
5.2
プレイの様子をモニターで見たもの . . . . . . . . . . . . . . . . .
27
5.3
UvA Trilearn 2003 同士で対戦した結果 . . . . . . . . . . . . . . .
28
5.4
パスを追加して対戦した結果
. . . . . . . . . . . . . . . . . . . .
29
5.5
ドリブルを追加して対戦した結果 . . . . . . . . . . . . . . . . . .
30
5.6
パス、ドリブルを追加して対戦した結果 . . . . . . . . . . . . . .
31
表目次
4.1
低レベルの動作 . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
4.2
中間レベルの動作 . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
4.3
高レベルの動作 . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
4.4
ユーティリティ . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
5.1
UvA Trilearn 2003 同士で対戦した結果 . . . . . . . . . . . . . . .
28
5.2
パスを追加して対戦した結果
. . . . . . . . . . . . . . . . . . . .
29
5.3
ドリブルを追加して対戦した結果 . . . . . . . . . . . . . . . . . .
30
5.4
パス、ドリブルを追加して対戦した結果 . . . . . . . . . . . . . .
31
iv
第 1 章序論
RoboCup は、ロボット工学と人工知能の研究のため、自律移動ロボットを使っ
たサッカーゲームとして日本の研究者らによって提唱された。現在では、サッカー
だけでなく、大規模災害へのロボット応用に役立てる目的の RoboCup レスキュー
や次世代の技術の担い手を育てる RoboCup ジュニアなどの活動が行われている。
ロボットでサッカーゲームを行うという RoboCup のチャレンジはロボティク
スだけに留まることなく、AI、電子工学、バーチャル環境と分散シミュレーショ
ン等の多くの分野での研究が関わっている。
RoboCup は実際のロボットを使ってサッカーゲームを行うリーグの他に、シ
ミュレーション部門も行われている。シミュレーション部門では実際のロボット
を使わずに、これをコンピュータ上の仮想フィールドで、それぞれ異なった人工
知能プログラミングされた 11 対 11 のバーチャルロボットが 10 分間のサッカー
ゲームを行う。サッカーのシミュレーションでは、出来るだけ現実の物理にそっ
た形でシミュレーションが行われるようになっている。また乱数による不規則性
や、遠くの物体は見えにくい（得られる情報が正確でなくなる）という効果も取
り入れられている。
本研究では RoboCup シミュレータを用いて、サッカーシミュレーションプロ
グラムの作成を行う。RoboCup シミュレータは、動的かつ不規則に状況変化する
中、複数プレイヤーが強調するマルチエージェント環境において競技することを
可能にするシミュレーションシステムであり、その中心を担うサッカーサーバー
がクライアント（プレイヤー）と通信するクライアント・サーバーシステムとし
て動く。各クライアントは、クライアント自身の限定的な視覚情報や聴覚情報、
それにプレイヤー自身の内部状態に関するセンサ情報をサーバーから受け取る。
これをもとに、向きの変換、移動、ボールをキックする等の基本的なコマンドを
1
用いてプレイヤーの動作を記述する事により、ゲームを進めることが可能となる。
本論の構成として、まず第 2 章では RoboCup について詳しく説明する。RoboCup
の成り立ち・考え・組織・目標を述べた後、RoboCup サッカーのリーグ・歴史に
ついて説明する。第 3 章では、シミュレーションシステムで中心となるサッカー
サーバーについて述べる。ここではサーバー・クライアントの関係とセンサ情報
について詳しく説明する。また、主要コマンド、試合の流れ、ルールについても
説明する。第 4 章では、本研究の内容であるサッカーゲームを行うためのプログ
ラム作成について説明する。まず、今回の研究にあたって参考にしたプログラム
のチームが取ることのできる、基本動作を説明する。そして、第 5 章ではそれら
の基本動作を組み合わせ、プレイヤーをボールとの位置関係によって役割を分け
た、プログラムをその役割ごとに詳しく説明する。そして、実際にサッカーゲー
ムのシミュレーションを行い、実行結果を考察する。最後に第 6 章では、まとめ
と今後の課題について述べる。
2
第 2 章 RoboCup
RoboCup は、ロボット工学と人工知能の研究のため、自律移動ロボットを使っ
たサッカーゲームとして日本の研究者らによって提唱された。現在では、サッカー
だけでなく、大規模災害へのロボット応用に役立てる目的の RoboCup レスキュー
や次世代の技術の担い手を育てる RoboCup ジュニアなどの活動が行われてい
る。1997 年に設立された RoboCup 連盟は、ジュネーブに登録された国際的・非
営利組織で、世界中の研究者たちが RoboCup の研究を激励・推進・増強するた
めに活動している。
RoboCup のチャレンジはロボティクスだけに留まることなく、AI、電子工学、
バーチャル環境と分散シミュレーション等の多くの分野へと関わっている。すな
わち、Robocup では広範囲の技術が統合されており、様々な技術分野において研
究を育てようとする試みなのである。
RoboCup の最終的な目標は、
「西暦 2050 年、サッカーの世界チャンピオンチー
ムに勝てる、自律型ロボットのチームを作る」ということであり、人工知能やロ
ボット工学などの研究を推進し、様々な分野の基礎技術として影響を与えること
を目的として、毎年世界大会であらゆる国からの参加者たちによって、競技が行
われている。
2.1 RoboCup のリーグ
サッカーだけでなく、RoboCup レスキューや RoboCup ジュニアも開催されて
いる。また、RoboCup サッカーにおいては実際のロボットを使ってサッカーゲー
ムを行うが、これをソフトウェアでシミュレートするシミレーション部門も行わ
3
れている。
RoboCup のリーグを図式化したものを図 2.1 で表す。
RoboCup



RoboCup レスキュー


































RoboCup サッカー



シミュレーションリーグ






小型ロボットリーグ



中型ロボットリーグ





四足ロボットリーグ






ヒューマノイドリーグ
RoboCup ジュニア
図 2.1 RoboCup のリーグ
2.2 RoboCup サッカー
RoboCup サッカーは、人間のサッカーの試合と同じく、自分で考えて動く自律
移動型ロボットを使った競技会形式で行われる。競技会は、最先端の科学・技術
に触れ、また競技そのものを楽しみながら研究者と一般人が接することができる
イベントの場であり、同時に教育の場でもある。
RoboCup サッカーには、次のようなリーグがある。
1. シミュレーションリーグ
実際のロボットを使うことなく、コンピューター上の仮想フィールドで、そ
れぞれ異なった 11 対 11 のバーチャルロボットが 5 分ハーフのサッカーを行
う。ネットワークを介して遠隔地からの参加も可能である。
2. 小型ロボットリーグ
卓球台ほどの大きさのフィールドで、直径 18cm 以内のロボット 5 台 1 チー
ムで試合をするリーグである。フィールド全体を見渡すカメラ、あるいは
ロボット搭載カメラからの視覚情報をベースに競技が行われる。
4
3. 中型ロボットリーグ
直径 50cm 以内のロボット 4 台が、卓球台 9 枚ほどの大きさフィールドで、
オレンジ色のボールを追う競技で、多くのチームが 360 度見渡せるカメラ
を搭載している。また、ロボットはセンサーで自分とボールの位置をすば
やく判断して動くことが出来る。
4. 四足ロボットリーグ
ソニーの AIBO をプラットフォームとして使って、4 台 1 チームのサッカー
リーグである。同じロボットを使用するため、各チームのロボットプログ
ラミングの優劣によって勝敗が左右される。
5. ヒューマノイドリーグ
2002 年大会から正式種目となった自律型２足歩行ロボットによるリーグで、
今後のロボカップの中核を担うことが期待されてる。試合形式のサッカー
はまだ行えないが、
「歩く」、
「ボールを蹴る」といった基本動作を試す競技
や、独自の機能を披露する「フリースタイル」競技が行われる。
2.3 RoboCup の歴史
1992 年発足時から、現在までの RoboCup の歴史をここにまとめる。
1992 年・
・
・ RoboCup の発足
1995 年・
・
・ RoboCup の構想発表
1997 年・
・
・第１回 RoboCup 世界大会（名古屋、10 カ国 40 チーム参加）
1998 年・
・
・ SONY4 脚ロボットリーグが加わる
第 1 回 RoboCup ジャパンオープン開催（東京)
第 2 回 RoboCup 世界大会開催（フランス、20 カ国 63 チーム参加)
1999 年・
・
・第 2 回 RoboCup ジャパンオープン開催（愛知)
第 3 回 RoboCup 世界大会開催（スウェーデン、35 カ国 120 チーム参加）
5
2000 年・
・
・ヒューマノイドリーグの概要が発表
第 3 回 RoboCup ジャパンオープン開催（北海道)
第４回 RoboCup 世界大会開催（オーストラリア、19 カ国 110 チーム参加)
2001 年・
・
・第 4 回 RoboCup ジャパンオープン開催（福岡)
第 5 回 RoboCup 世界大会開催（アメリカ、22 カ国 119 チーム参加)
2002 年・
・
・第 6 回 RoboCup 世界大会（福岡（日本）、釜山（韓国）29 カ国 188
チーム参加）
2003 年・
・
・第 6 回 RoboCup ジャパンオープン開催（新潟）
第 7 回 RoboCup 世界大会開催（イタリア、34 カ国 277 チーム参加)
2004 年・
・
・第７回 RoboCup ジャパンオープン開催（大阪)
第８回 RoboCup 世界大会開催（ポルトガル、37 カ国 346 チーム参加)
2005 年・
・
・第 9 回 RoboCup 世界大会開催 (大阪, ７月 13 日（水）∼19 日（火）)
2006 年・
・
・第 10 回 RoboCup 世界大会ドイツ開催予定
2050 年の夢・
・
・「西暦 2050 年、サッカーの世界チャンピオンチームに勝てる、
自律型ロボットのチームを作る」
6
第 3 章サッカーサーバー
サッカーサーバーは、様々な種類のプログラミング言語で書かれたプログラム
同士が互いにサッカーの試合を行うことを可能にするシステムで、シミュレーショ
ンシステムの中心となる。また、サッカーサーバーの目的の 1 つはマルチエージェ
ントシステムの評価であり、エージェント間のコミュニケーションの効率は基準
の 1 つである。ユーザはこのような限定されたコミュニケーションに従って多数
のクライアントの制御を実現しなくてはならない。
サッカーサーバーは soccerserver と soccermonitor の 2 つのプログラムから構
成されている。soccerserver はボールとプレイヤーの動きをシミュレートして、ク
ライアントと通信し、ゲームがルール通りに行われる様に、制御するサーバープ
ログラムである。
soccermonitor はサーバー内の仮想的なフィールドを X ウィンドウシステムを
用いて表示するプログラムである。複数の soccermonitor プログラムが 1 つの
soccerserver に接続することができる。したがって、複数のフィールドウィンド
ウを複数のディスプレイ上に表示することができる。
3.1 サーバーとクライアントの関係
試合はサーバー・クライアント方式で行われる。サッカーサーバーは仮想的な
フィールドを提供し、ボールとプレイヤーの全ての動きをシミュレートする。各
クライアントはそれぞれのプレイヤーの動きを操る、いわばプレイヤーの頭脳的
な役割をする。サーバーと各クライアントとの通信はコネクションなしの IP プ
ロトコルである、UDP/IP によるソケットを通じて行われる。
7
UDP/IP のインターフェースを持つ言語やシステムであれば簡単にこのサー
バーを利用してサッカーのシミュレーションを行うことができる。
UDP/IP の主な特徴は、以下に示す通りである。
• データが個別のパケットで交換される。
• プロトコルはパケットが送られた順に到着することを保証しない。
• パケットの全てが到着することを保証しない。
このプロトコルを用いることで、クライアントはプレイヤーを制御するコマン
ドを送ったり、プレイヤーのセンサ情報を得ることができる。つまり、クライア
ントが視覚・聴覚情報をサーバーから受け取り、制御コマンドをサーバーに送り
返すということになる。そして、各クライアントは 1 人のプレイヤーだけを制御
することができるため、ユーザはプレイヤーと同数のクライアントプログラムを
実行する必要がある。また、クライアント間の通信はクライアントプログラム同
士が直接行うことは許されず、サーバーを介して、say と hear プロトコルを用い
て行う必要がある。
3.2 サーバーからのセンサ情報
一般的にセンサ情報は、各サイクルごとに全てのプレイヤーに送られるメッセー
ジで, 情報を得るためのサーバー問い合わせは必要ない。返ってきたセンサー情
報は全て Time によって示され, タイムラベルと、データが送られた時のゲームの
サイクルナンバーを保持する。
3.2.1 視覚情報 : Visual Sensor
サーバーから送られてくるセンサ情報の中で、最も重要な情報で、かつ少々複
雑なものである。プレイヤーの視点から見えているオブジェクト情報を返し、そ
の情報量は距離に依存する。遠距離のオブジェクトは情報を得ることが少なく、
正確な位置を把握する事が難しい。これは、プレイヤーとオブジェクトとの距離
の値が曖昧化されるためである。また、コマンドで頻度と精度が変化する。
8
図 3.1 サーバーとクライアントの関係
(see Time ObjInfo... ObjInfo...) でサーバーから視覚情報を伝達する。
Time
サッカーサーバーのシミュレーションサイクル
（現在の時間）
ObjInfo
オブジェクトの情報（背番号、距離、方向、距離
の変化、顔の方向、頭の方向）
＜例＞
( see 0((f c)21.1 34 0 0)((f c b)51.4 6)((f l b) 83.1 43)
((f p l b)62.2 44)((f b 0)56.3 5)((f b r 10)54.1 -6)
((f b r 20)54.1 -16)((f b r 30)56.3 -27)((f b r 40)59/7 -36)
((f b r50)64.1 -44)((f b l 10)59.7 14)((f b l 20)64.1 22)
((f b l 30)70.1 29)(((f b l 40)76.7 35)((f b l 50)84.8 39)
9
((b)22.2 34 0 0)((1 b)49.9 79))
(p : player, b : ball, f : flag , g : goal , Side : right or left)
プレイヤーからオブジェクト（プレイヤーが見えている旗、ラインなど）との距
離、角度、速度などの情報 = Info を用いて、その Info が何であるのかを認識し
て、自分の位置や移動速度を計算することができる。
現在 55 の旗 (ゴールは旗として数える) と 4 つのラインがある。すべての旗と
ラインを図 3.2 に示す。
例えば、以下のようにして自分の位置を認識する。
1. ライン情報を探す。
2. 自分の顔の角度が決まる。
3. 自分から一番近い距離のオブジェクト情報を探す。
4. 自分の位置を 3 から計算する。 ( x,y )
3.2.2 聴覚情報 : Audio Sensor
聴覚情報は、プレイヤーがフィールド上で聞くことのできるメッセージ情報で、
これは審判、オンラインコーチ、他のプレイヤーからのメッセージを返すもので
ある。
聴覚情報は以下の様にクライアントに配送される。
(hear タイム送り手の方向 ’ メッセージ’)
＜例＞
(hear 3000 referee kick off r)
現在の時間＝ 3000 サイクル (=300 秒）で、審判がキックオフのメッセージを出
している。
10
図 3.2 シミュレーションにおける旗とライン
3.2.3 感覚情報 : Body Sensor
感覚情報は、各サイクルのはじめに残スタミナ、プレイヤーの現在の速度など
のプレイヤーの状態全てを返すものである。視覚情報の品質と頻度において重要
な要素である。
3.3 soccermonitor
soccermonitor と soccerserver は UDP/IP のポートを経由して接続される。
サーバーからモニターへの接続は、soccerserver およびに記録されたゲームを
再生する logplayer が、モニターにプレイヤーとボールの状態と位置をサイクル
(100ms) 毎に送っている構造体を soccermonitor に送ることで実行される。また、
モニターからサーバーへの接続は、指定のコマンドをサーバーに送ることで実行
される。
11
3.4 主要コマンド
サッカーコマンドの主要なコマンドには以下の様なものがある。
• 参加する : (init チーム名)
チーム名を init コマンドで返し、サーバーに接続して試合に参加する。
• 走る : (dash 強さ (-100∼100))
＜例＞ (dash 100) で選手は 100 の力で走る。
• 方向転換 : (turn 角度 (-180 °∼180 °))
＜例＞ (turn 20) で 20 °方向に方向転換する。
• 首を回す : (turn neck 角度 (-90 °∼90 °))
＜例＞ (turn neck 20) ) で 20 °方向に首を回す。
• ボールを蹴る : (kick 強さ (∼90)、角度 (-180 °∼180 °))
＜例＞ (kick 90 30) ) 強さ 90 で 30 °方向にボールを蹴る。
3.5 試合全体の流れ
サッカーサーバーによって行われる試合の流れは以下の手順で実行される。
1. サーバーに接続 : init コマンドにより、両チームの各クライアントは接続。
2. 前半戦のスタート（5 分間） : マッチレフリー（サーバーを起動する人物）
はサッカーサーバーウィンドウの kick off のボタンを押してスタート。
3. 前半戦終了：サーバーは試合を中断。
4. half time : 競技者はクライアントプログラムの変更可能。
5. サーバーに再接続： reconnect コマンドにより、各クライアントは再接続。
6. 後半戦のスタート（5 分間）
7. 後半戦終了：サーバーは試合を終了。
12
3.6 ルール
ルールはサーバーと人によってジャッジされる。
1. サーバーによるジャッジ
• キックオフ時
キックオフの直前に全てのプレイヤーは自陣にいなくてはならない。
ゴール後、プレイヤーが自陣へ戻るための時間が５秒間ある。この５
秒間に、クライアントがただちに任意の地点に移動できるように move
コマンドを発行できる。もし、この５秒間の後にプレイヤーが敵陣に
いた場合は、レフリーがプレイヤーを自陣内のランダムな地点へ移動
させる。
• ゴールした時
チームが得点した時、レフリーはゴールを宣言し、スコアを更新させ
る。その後、５秒間中断して、ボールをセンターマークへと移動し、
プレイモードを kick off に変更する。レフリーが試合を中断している
間にクライアントは自陣に戻らなくてはならない。
• ボールがフィールド外に出た時
ボールがフィールド外にあるとき、レフリーはボールを適切な場所（タッ
チライン、コーナー、ゴールエリア）へ戻し、プレイモードを kick in、
corner kick、goal kick に変更する。コーナーキックの場合は、レフリー
は適切なコーナーの内側にボールを置く。
• プレイを再開するための距離
プレイモードが kick off、kick in、corner kick のとき、レフリーはボー
ルを中心とした半径 9.15m の円内にいる守備中の前プレイヤーを排除
する。排除されたプレイヤーは、その円の周囲に配置される。プレイ
モードが offside のとき、半径 9.15m の円内にいる、攻撃中の全プレイ
ヤーは non offside ポジションへ戻される。プレイモードが goal kick
のとけ、攻撃中の全プレイヤーは、ぺナルティエリア外に移動させら
れる。ゴールキックが行われる間、攻撃中のプレイヤーは再びペナル
13
ティエリアに入ることはできない。ボールがペナルティエリア外へ出
た後、プレイモードは直ちに play on に変わる。
• プレイモードの制御
プレイモードが kick off や kick in、corner kick のとき、レフリーは kick
コマンドによって、動き出したらすぐにプレイモードを play on に変
更する。
• ハーフタイムとタイムアップ
レフリーは前半、後半の終了時に試合を中断する。
2. 人間によるジャッジ
『妨害行為』等のファールはサーバーが自動的に判断するのが難しい。な
ぜなら、プレイヤーの意図に関わる問題であるからだ。このような状況を
解決するためにサーバーは人間が介入するためのインターフェイスを提供
する。このように、人間のレフリーが試合を中断し、いずれかのチームに
フリーキックを与えることができる。
• 多量のメッセージによってサーバーを溢れさせる。
クライアントはシミュレーションサイクル毎に 3、4 個以上のコマンド
をサッカーサーバーに送るべきではない。試合後に要求されれば、メッ
セージの乱用がサーバーの遅延させていないかを調べられる。
• 不適当な行為
もし、プレイヤーが不適当な方法で試合に干渉しているのを気づいた
ら、人間のレフリーは試合を中断し、相手チームにフリーキックを与
えることができる。
14
第 4 章 UvA Trilearn 2003
UvA Trilearn 2003 は、イタリアで開催された第７回世界大会である RoboCup
2003 のシミュレーションリーグで優勝した、アムステルダム大学のチームが作成
したサッカーシミュレーションプログラムである。この U vA Trilearn 2003 の基
本動作のソースファイルと振る舞いのサンプルを Web 上で入手することが可能
である。入手先については、参考文献 [1] にのせた通りである。
4.1
U v A Trilearn 2003 のクラス構成
U v A Trilearn 2003 プログラムは C++で書かれており、ソースコードの総行
数は約 32000 行である。主要なクラスの構成は
• ActHandler サッカーサーバーにコマンドを送るためのコマンドキューの
管理
• BasicCoach 基本的なコーチクラス
• BasicPlayer サッカープレイヤーのための基本的な動作
• Connection サーバーとの接続
• Formations サッカーフォーメーションを定義しているクラス
• GenericValues 選手や、旗
• Geometry 円や点、ベクトル等の幾何学図形の定義
• Logger ゲームの詳細をログ
15
• Parse サーバーからのメッセージを解釈するクラス
• Player 実際のゲームを行うためのプレイヤーの動作を定義
• PlayerSettings プレイヤーの各種の情報や状態を定義するクラス
• ServerSettings サーバーの情報や設定を定義するクラス
• WorldModel サーバーからの情報を元に、プレイヤーが構成したピッチや
プレイヤー等の位置や状態を再構築したもの。プレイヤーが動作を行うた
めの元となる。
である。この中で、WorldModel クラスと BasicPlayer クラスが実際に動作するプ
レイヤー（クライアントプログラム）を構築する上で最も重要である。WorldModel
クラスには、サーバーからの各種の情報（センサ情報）を元に自分や味方、敵の
プレイヤーの位置やボールの位置、速度等の情報が保持されている。
BasicPlayer クラスには、サッカープレイヤーの動作を構成する基本となる、キッ
クや移動、ボールを見つけるという動作が定義されている。
Player クラスは実際のゲームを行うプレイヤーの動作を記述するためのクラス
である。公開されているソースプログラムには、この部分の詳細は省かれており、
単純にボールを見つけて、ゴールに向けてキックするという動作を行うようプロ
グラムされたサンプルプログラムが用意されている。
4.2 WorldModel
各プレイヤーは WorldModel オブジェクトを一つ持つ。これは、サーバーから
のセンサ情報を元に、プレイヤーの状態や位置等を構成したものである。これら
の情報を元にして、
• プレイヤーやボールの位置を取り出す
• ボールがキックできるかを判断する
• 指定した位置（自分を中心とする扇型の領域）にいる選手の数
16
• 近くにいる味方のプレイヤー
• 近くにいる敵プレイヤー
等の情報を取り出すためのメソッドが用意されている。
4.3 BasicPlayer
プレイヤーの取ることの出来る動作は、基礎ファイルの中の BasicPlayer.cpp の
中で、サッカーコマンドとして定義されている。サッカーゲームを行うためには、
以下の動作を戦略的に組み合わせて、プレイヤーに動作させる必要がある。プレ
イヤーの取ることの出来る動作を表 4.1 から表 4.4 にまとめた。
4.4 BasicCoach
RoboCup のシミュレーションリーグではコーチの使用が許されている。コー
チは、サーバーを介して選手に指示を送ることが出来る。今回は、コーチの処理
までは考えなかったので詳細な説明は省略する。
17
メソッド
引数
動作
alignNeckWithBody
選手が自身の身体と首を一直線
に整える。
turnBodyToPoint
(位置, サイクル)
選手が与えられたポイントに自
分の首を向ける。
searchBall
選手にボールが見えないとき、
ボールを探させる。
dashToPoint
(位置, サッカーコマンド)
与えられたポイントへとダッシ
ュする。
freezeBall
動いてるボールをその場で静止
させる。
kickBallCloseToBody
(相対視点, キック率)
選手が身体に近いボールを蹴
る。
accelerateBallToVelocity
(ボール速度)
選手がキックによってボールを
加速させる。
catchBall
選手がボールをつかむ事が出来
る。キーパーの場合は単純実行
される。
communicate
(文字列)
選手がフィールド上の他の選手
とコミュニケーションする。
teleportToPos
(位置)
選手を指定された位置まで移動
させる。
listenTo
(オブジェクト)
指定された選手の声を聞ける。
大抵はチームメイト。
tackle
選手はタックルする。
表 4.1 低レベルの動作
18
メソッド
引数
動作
turnBodyToObject
(object)
選手が与えられた object に向け
て身体を向ける。
turnNeckToObject
(object, サッカーコマンド)
選手が与えられた object に向け
て首を向ける。
moveToPos
(位置, 角度, 距離, サイクル)
選手は選手は与えられた位置ま
で移動する。
collideWithball
選手は意図的に、ボールに接触
する。
interceptClose
選手が自分に近づいてくるボー
ルを遮る。
interceptCloseGoalie
キーバーが自分に近づいてくる
ボールを遮る。
kickTo
(位置, 残速度)
選手はある速度に達した時に、
現地点から与えられた点に向
け、ボールを蹴る。
moveToPosAlondLine
(位置, 角度, 距離)
選手は与えられた位置へ、ライ
ンに沿って移動する。
表 4.2 中間レベルの動作
19
メソッド
引数
動作
intercept
(キーバかどうかの判
定)
選手はボールを intercept するのに
dribble
(方向, ドリブルの種
類)
選手はドリブルをする。
directPass
(位置, パスの種類)
選手は指定のチームメイトに direct
最適な位置を計算し、実行する。
pass をする。
leadingPass
(選手, 距離, 方向)
選手は指定のチームメイトに lead-
ing pass をする。
throughPass
(選手, 位置, 最大角度)
選手は指定のチームメイトに高度な
through pass をする。
outplayOpponent
(選手, 位置)
attacker が敵 defender の後ろのオー
プンスペースにパスを出す。
clearBall
(クリアの種類, 指定エ
リア, 角度)
選手はフィールド上の指定のエリア
(選手, 位置, マークの
種類)
選手は指定の敵をマークする。（１
(距離)
選手（主にキーパー）が、ゴールラ
mark
defendGoalLine
へ、ボールをクリアする。
対１）
インを守る。
interceptScoringAttempt
ゴールへ向かってるボールを inter-
cept する。
holdBall
ボールをキープする。
表 4.3 高レベルの動作
20
メソッド
引数
動作
getThroughPassShootingPoint
(選手, 位置, 角度)
チームメイトにスルー
パスしようとした時の
蹴った位置を返す。
getInterceptionPointBall
(サイクル, キーバーか
どうかの判定)
ボールを intercept す
るのに最適なポイント
を計算する。
getActiveInterceptionPointBall
(位置, 角度)
最も可能性の高い位置
でボールを intercept
する。
getShootPositionOnLine
(位置, 角度)
ボールと周囲の敵との
最大角度と、その線分
上のポイントを返す。
getEndSpeedForPass
(選手, 位置)
バスの終速度を返す。
turnNeckToObject
(object, サッカーコマ
ンド)
選手が指定された ob-
getMarkingPosition
(選手、位置)
ject の方向に顔を向け
る。
指定した敵をマークす
べき位置を返す。
表 4.4 ユーティリティ
21
第 5 章サッカープログラム
本研究では、第４章で説明した、サッカーシミュレーションチーム UvA Trilearn
2003 の基本動作のソースファイルと振る舞いのサンプルを Web 上から入手した
ものを使ってプログラム作成に取り組んだ。以下で UvA Trilearn 2003 と記述し
ているものについては、UvA Trilearn 2003 の基本動作のソースファイルと振る
舞いのサンプルを表すものとする。
プレイヤーがサッカーゲームを行う際に動的かつ不規則に状況が変化するもと
で、プレイヤーは不確実なサーバーからの情報から様々なことを推測し、自律し、
チームプレイとしての協調性をもって行動し、より強いプレイヤーになるために
学習するようなプログラムを作成する必要がある。実際には、この全てを考慮に
入れるのは困難なため、本研究では特にプレイヤーの自律的な動作について取り
上げて、サッカーゲームシミュレーションのプログラムの作成を行った。
プレイヤーはキーパーとそれ以外のプレイヤーとに分けられる。
プレイヤー









キーパー


それ以外のプレイヤー









Def ender








M idf ielder
Attacker
キーパー以外のプレイヤーは一般的には、フォーメーションによってその動作を
振り分ける。守備を受け持つもの、攻撃を受け持つもの、それに守備と攻撃の中
間的な役割を受け持つものに大きく分けることが出来る。
それぞれのプレイヤーに対して、ボールとの位置関係によって動作を振り分け
22
る必要がある。例えば、
M idf ielder


P asser










Receiver








Intercepter









P assive
ボールをキープしている
味方がボールをキープしているとき、
近くのプレイヤー
味方がボールをキープしていないとき、
ボールの近くのプレイヤー
ボールの近くにいないプレイヤー
本論文で作成したプレイヤーの動作を以下の節に示す。
5.1 Keeper
ゴールキーパーはキーパー専用のプログラムを動かす。キックオフ後の動作は
まず、ボールをキャッチ出来る状況かを判断し、出来るのであればキャッチし、出
来なければ次にキックを出来る状況かを判断し、出来るのであればキックをし、
出来なければ次にまた違う動作についての状況判断を行っていく。つまりこれを
簡単に図式化すると、図 5.1 のようになる。
5.2 Passer
ボールをキープしている Passer が取るべき行動を以下の 1 から 4 の場合に分け
て考えた。
1. シュート
プレイヤーがゴールから 20m 以内の位置にいる時に、実行される。プレイ
ヤーの位置からゴールの位置までの円錐形 (cone) を 4 分割して, その円錐
内に敵がいるかどうかを順に調べてゆく。敵が 1 人もいなければ, 中間レベ
ルの動作のメソッドである、 kickTo( 位置, 速度) をサッカーコマンドに返
し、最大限の力 (最速) で敵ゴールに向かってキックする。
2. パス
23
図 5.1 キーパーの動作
1 を不可能と判断した場合、次にパスが可能か判断する。プレイヤーに
(a) 最も近いチームメイト
(b) 2 番目に近いチームメイトの順でそのチームメイトの位置を探す。
次に、パスを受けるチームメイトの半径 3m の円内の敵の数を調べ、敵が
1 人もいない場合、高レベルの動作のメソッドである directPass(位置, パ
スの種類) を使ってパスをする。directPass のパスの種類には Pass Fast、
Pass Normal の 2 種類あり、ここでは Pass Normal を使ってプログラムした。
3. ドリブル
1、2 が不可能と判断した場合、次にドリブルが可能かを判断する。
(a) ドリブルファースト
プレイヤーの前に広がる領域を順に前方、斜め左右前の 2 方向、左右
へと分け、この順でドリブルが可能かを調べていく。それぞれの方向
24
に円錐形 (cone) を当てはめて、その円錐内の敵の数を調べる。ここで、
円錐の長さはプレイヤーの位置から測って、前方・左右が 20.0m、斜
め左右が 14.0m である。敵が 1 人もいない場合、高レベルの動作のメ
ソッドである、 dribble(角度,DRIBBLE FAST) をサッカーコマンドに
返し、敵のいない方向を選んでドリブルする。
(b) ドリブルスロー
(a) を不可能だと判断した場合、次にドリブルスローが可能かを判断
する。(a) と同様に、領域を分けてその円錐内の敵の数を調べる。ここ
で、円錐の長さはプレイヤーの位置から測って、前方・左右が 10.0m、
斜め左右が 4.0m である。敵が 1 人もいない場合、高レベルの動作のメ
ソッドである、 dribble(角度,DRIBBLE SLOW) をサッカーコマンド
に返し、敵のいない方向を選んでドリブルする。
4. 1 から 3 が不可能な場合
プレイヤーは中間レベルの動作のメソッドである、 kickTo( ゴールの中心
の位置, 最大限の力) でゴールに向かって最大限の力 (最速) でキックする。
5.3 Interceptor
味方プレイヤーがボールをキープしていない状況で、ボールに最も近くにいる
プレイヤーである Interceptor が取るべき行動は、ボールを intercept することであ
る。そのプレイヤーのスタミナを調べ、スタミナに応じて以下のように行動する。
• スタミナが高い場合
スタミナが十分にあると判断した場合はボールまで全速力で走り、ボール
の方向に首を向けて intercept することを試みる。
• スタミナが低い場合
そのままボールの方向に首を向けて intercept することを試みる。
25
5.4 Receiver
Passer から送られるパスを受ける。現状は intercept することによってボール
を受けている。
5.5 Passive
1. ボールの位置を知らない場合
周囲を見渡し、ボールを探す。そして、身体と首を一直線に整えるコマン
ドを返す。
2. ボールの位置を知っているが、遠く離れている場合
スタミナが高ければ、プレイヤーは現地点からフォーメーションとボール
の位置によって戦略的に決めた位置まで移動し、ボールに向かって首を回
す。スタミナが低ければ、ボールの方へ身体と首を向けてボールを見守る。
5.6 実行結果
プログラムの実行は 5 種類にフォーメーションを変化させて、行った。
UvA Trilearn 2003 については 10 回、Passer の取りうる動作を以下の 3 パター
ンに変化させて各 5 回、実行結果を観測した。
1. シュートかパス
2. シュートかドリブル
3. シュート、パス、ドリブルのいずれか
ここで、UvA Trilearn 2003 は、プレイヤーはボールをキープしている時には、
ゴールに向かって最大限にキックする、つまりシュートのみを行う動作である。
なお、表にあるフォーメーションの数字は左から Defender、Midfielder、Attacker
の順に人数を表している。また、442(a) と 442(b) の違いは後者が open defensive、
26
つまりプレイヤーが動くことが可能な範囲が広いことにある。図 5.2 はプレイの
様子をモニターで見たものである。
図 5.2 プレイの様子をモニターで見たもの
5.6.1 UvA Trilearn 2003
UvA Trilearn 2003 の実行結果が表 5.1 のようになる。プレイヤーの動作はボー
ルをキープしている時には、ゴールに向かって最大限にキックする、つまりシュー
トのみを行う動作になっている。実行回数は 10 回である。
表 5.1 の合計を分かりやすく棒グラフに直したものが図 5.3 になる。縦軸がフォー
メーション、横軸が点数を表す。
27
433
334
442(a) 442(b)
343
合計
433
15 - 9
17 - 14
2-2
7-6
17 - 6
58 - 37
334
14 - 17
24 - 7
2-3
8 - 11
14 - 11 62 - 49
442(a)
2-2
3-2
5-7
10 - 6
0-4
20 - 21
442(b)
6-7
11 - 3
6 - 10
22 -10
5-7
50 - 37
343
6 - 17
11 - 14
4-0
7-5
15 - 13 41 - 49
表 5.1 UvA Trilearn 2003 同士で対戦した結果
図 5.3 UvA Trilearn 2003 同士で対戦した結果
28
5.6.2 パスの追加
パスを追加後の実行結果が表 5.2 のようになる。実行回数は 5 回である。
433
334
442(a)
442(b)
343
合計
433
6-6
4-7
1-3
4-2
5-2
20 - 21
334
6-4
7-9
2-6
5-3
442(a)
0-3
2-2
4-1
9-3
1-3
16 - 12
442(b)
2-1
6-4
1-4
5-7
1-1
15 - 17
334
4-8
6-9
2-3
2-3
7-6
21 - 29
合計
18 - 22 25 - 31
10 -17
10 - 11 30 - 33
25 - 18 24 - 23 ———
表 5.2 パスを追加して対戦した結果
表 5.2 の合計を分かりやすく棒グラフに直したものが図 5.4 になる。縦軸がフォー
メーション、横軸が点数を表す。
図 5.4 パスを追加して対戦した結果
29
5.6.3 ドリブルの追加
ドリブルを追加後の実行結果が表 5.3 のようになる。実行回数は 5 回である。
433
334
442(a)
442(b)
343
合計
433
0 - 11
0 - 12
1-5
0-4
0 - 12
1 - 45
334
0-8
1-7
3-5
4-7
0 - 16
8 - 43
442(a)
0-3
1-3
4-4
0-7
1-1
6 - 18
442(b)
1-4
2-2
2-3
1 - 10
1-4
7 - 23
343
0-9
0 - 12
1-7
1-6
0 - 11
2 - 45
合計
1 - 35
4 - 36 11 - 24
6 -34
2 - 44 ———
表 5.3 ドリブルを追加して対戦した結果
表 5.3 の合計を分かりやすく棒グラフに直したものが図 5.5 になる。縦軸がフォー
メーション、横軸が点数を表す。
図 5.5 ドリブルを追加して対戦した結果
30
5.6.4 全体として動かした時の結果（パス、ドリブルの追加）
パス、ドリブルを追加後の実行結果が表 5.4 のようになる。実行回数は 5 回で
ある。
433
334
442(a)
442(b)
343
合計
433
0 - 16
4 - 26
5-5
11 - 7
6 - 14
26 - 65
334
3-8
7 - 16
5-6
7 - 10
5-7
27 - 47
442(a)
0-5
2-4
1-5
3 -10
3-2
9 - 26
442(b)
1-6
0 -10
0-6
4-8
3-5
8 - 35
343
2 -15
3 - 20
5-9
9-8
2 - 10
21 - 62
合計
6 - 50 16 - 76 16 - 31 34 - 43 19 - 38 ———
表 5.4 パス、ドリブルを追加して対戦した結果
表 5.4 の合計を分かりやすく棒グラフに直したものが図 5.6 になる。縦軸がフォー
メーション、横軸が点数を表す。
図 5.6 パス、ドリブルを追加して対戦した結果
31
5.7 実行結果からの考察
1. UvA Trilearn 2003
同じプログラムのプレイヤー同士を対戦させているので、点数差はあまり出
ないという推測のもとで実行したが、実際には多少の差が見られた。442(a)
で得点・失点ともに少ないのは、点を取られにくく、また取りにくい、比
較的守備がしっかりとした体制と言えるようだ。
2. パスの追加
結果は UvA Trilearn 2003 同士の対戦結果と比較しても、ほとんど変化は
見られなかった。パスを改善するためには、パスを受ける受け手の動作を
考える必要がある。そのためには、より高度な協調動作を考慮し、コミュ
ニケーションする動作を追加することが必要であると考えられる。
3. ドリブルの追加
ドリブル追加によって、各フォーメーションごとに著しく失点が増加、ま
た得点についても減少していることが分かる。実際のサッカーゲームのプ
レイにはドリブルは有効であると考え、Passer の取りうる動作に加えたの
だが、結果は良いものではなかった。シュートだけではなく、ドリブル出
来るときにはドリブルをするというプレイヤーに選択させる意図でこの動
作を追加した。しかし実行中のプレイヤーの動作を観察してみると、敵の
いない方向を選んでドリブルを始めるが、すぐに敵にボールを奪われてし
まっている様だった。また、ドリブルをすることでボールの動きを遅らす
結果に至り、敵陣にボールがある時間が少ないことに繋がった。ドリブル
を有効的な攻撃手法にするためには、自分の位置、ボールの位置、周囲の
敵の数の情報だけでドリブルさせるのではなく、その他様々な要素を考慮
しなくてはならない。
4. パス、ドリブル追加の結果
Passer の動作にドリブルとパスの両方を追加して動かした結果は得点が減
少、失点が増加した。UvA Trilearn 2003 はシュートのみの単純な動作を実
32
行するものだが、非常に効果的であった。この効果を超えるためには、複
雑な思考をもってパス・ドリブル動作の判断をさせる必要がある。
33
第 6 章まとめ
本研究では、サッカーシミュレーションプログラムの作成を行った。キーパー
以外のプレイヤーについて、その役割をボールとの位置関係によって 4 つに分け
てその動作を記述するプログラムを作成した。ボールをキープしている状態のプ
レイヤーが取りうる動作として、周りの状況から、シュート・パス・ドリブルの三
つの動作から適切な動作を選択する様にした。このように作成したサッカープロ
グラムを使って、実際にシミュレーションを実行した。対戦相手としては、元々
配布されている基本的な動作を行うようプログラムされたものを選んで行った。
このプログラムではキーパー以外の 10 人の役割は特に個別化せず、ボールをキー
プしている状態のプレイヤーは敵ゴールを目指してキックをする、といった単純
な動作を実行するものである。
このようにして実験を行った結果では、パス動作を追加したプログラムではほ
とんど変化は見られず、またドリブル動作を追加したプログラムではもとのプロ
グラムよりも弱いプレイヤーになってしまった。
パスやドリブル動作を行う判断は、近くにいる敵チームのプレイヤーの数と味
方チームのプレイヤーの数によって単純に決めていたが、このようなプログラム
では良い結果が得られない事が分かった。より良いプログラムを作成するには、
パスやドリブルを自分・ボール・味方・敵の位置や、自分の周囲を取り巻く敵の
数で判断し、単純実行するだけではなく、それぞれの状況について細かく考えて
やる必要がある。また特にパスを行うには、パスを受けるプレイヤーとの協調を
取る必要がある。
実際のサッカーゲームで人間が単純に行動している様に思える動作も、実はか
なり複雑な思考回路によって行使されている。
現在のプレイヤーの動きは攻撃をするのみ（攻撃は最大の防御？）なので、実際
34
に試合を行わせるには、プレイヤーの役割に守備を行う動作の追加が必要である。
35
謝辞
本論文の執筆及び研究にあたり、いつも親身に御指導をして頂いた加古富志雄
教授に深く感謝し、厚く御礼を申し上げます。また、助言や励ましの言葉をかけ
て頂いた加古研究室の皆さんに深く感謝の意を表します。
36
参考文献
[1] UvA Trilearn 2003 のホームページ,
http://www.science.uva.nl/ jellekok/robocup/
[2] RoboCup Official Site, http://www.robocup.org/
[3] M.Chen, K.Dorer, E.Foroughi et. al, Users Manual, Robocup Soccer Server
for Soccer Server Version 7.07 and later, Feb. 11, 2003.
[4] Emiel Corten, Klaus Dorer Fredrik Heintz, Kostas Kostiadis, Johan
Kummeneje, Helmut Myritz, Itsuki Noda, Jukka Riekki, Patrick Riley, Peter
Stone, Tralvex Yeap , Soccerserver Manual(日本語版) , Ver.5, Rev. 00 beta.
[5] 吉上敦子, 平成 14 年卒業論文「サッカーシミュレーションプログラムの作成」
[6] サッカーフォーメーション入門, http://metalmoni.s3.xrea.com/x/soccer.html
37

Download Report