Google AIチャレンジ2011年秋のルール

トーナメントルール





トーナメントスケジュール

プログラムが参加者から受け取られる現在の段階は、2011年12月19日月曜日(モスクワ時間)0時間59分まで続きます。 その後、トーナメントの最後の部分が始まります。 現在、最終パートの期間は定義されていませんが、1週間未満続くことが予想されます。 最後に、勝者が発表され、トーナメントの最終結果が公開されます。



ゲーム「Ants」の仕様。

ストローク構造:

準備:

各ボットは、ゲームの初期情報を受け取ります。これには、カードのサイズ、移動回数の制限、準備と各移動の時間制限が含まれます。 ボットはこのデータを処理した後、システムに準備完了(「準備完了」)を通知する必要があります。 すべての参加者が準備を発表した後、ゲームが開始されます。



動き

すべてのボットが準備を完了し、準備ができたことを報告した後、ゲームエンジン(以降、サーバー)は次のアクションを周期的に実行します。

  1. ゲームの状態を参加者に送信します。
  2. 参加者からチームを受け取る。
  3. コースのフェーズの実行とゲームマップの更新。
  4. ゲームを終了するための条件を確認します。


各カードには、移動回数に制限があります。 主催者は、トーナメント中にこの制限を変更する権利を留保します。

上記のアクションは1つの動きで構成されます。 制限に達するまで移動が繰り返され、その後ゲームが中断されます。



ストローク段階

プレーヤーからすべての注文を受け取った後、サーバーはゲームの状態を更新して次の動きに進みます。 ストロークの実行は5つのフェーズで発生します。



次の場合、プレイヤーは戦闘から除外されます。

エラーまたはタイムアウトが発生すると、参加者のアリは移動せずにマップ上に残りますが、他のアリとの戦いと衝突を続けます。 他のプレーヤーには、プレーヤーのノックアウトが通知されません。

ボットがエラーまたはタイムアウトを引き起こした場合、ボットからの注文はこのターン実行されません。



トーナメントの順位

ゲームの最後に、参加者はこのゲームで獲得したポイントに基づいて整列します。 同じポイント数で、プレイヤーは同じ場所を占有します。 ポイントの差はトーナメントの順位では考慮されません。 場所だけが重要です。



ポイント分布:

ゲームの目的は、蟻塚の攻撃と防御に対して与えられるポイントの最大数を設定することです。

つまり、すべての蟻塚を失い、見知らぬ人を1人も破壊しなかった場合、0ポイントで戦闘を終了します。



プレイヤーが1人残った状態でゲームが終了し、マップに蟻塚が検出されなかった場合、各蟻塚の2つのボーナスポイントが残りの1つに加算され、1つのポイントがこれらの蟻塚の所有者から奪われます。 エラーまたはタイムアウトにより戦闘から脱落したボットは、破壊されたプレイヤーと同等です。



ゲームの早期終了

重要でないゲームやゲームの継続を減らすために、ゲームの早期終了のルールが導入されました。



アリは食物を集めません。

サーバーがボットが食料を収集できないと判断した場合、ゲームは中断されます。 これらは初期または非常に愚かなボットであると考えられています。 食物の90%が150の動きでカードに残っている場合、中断が発生します。



蟻は蟻塚を破壊しません。

中断は、1人のプレイヤーが支配するときに発生しますが、他のプレイヤーを破壊しません。 ボットはおそらくリーダーシップを失うことはないと考えられています。それは、蟻塚を破壊するのに十分な訓練を受けていないということです。 1人のプレイヤーのアリの総数が150の動きの食物の量の90%になると、ゲームは中断されます。



残ったプレイヤーは1人だけです。

ライブボットのみが残っている場合(残りは破壊され、エラーまたはタイムアウトが発生します)、ゲームは中断されます。 残りのポイントはボーナスポイントが付与され、その他のポイントはそれに応じて差し引かれます。



結果は変わりません。

ゲームの結果として自分の場所を変えることができる蟻塚を持つプレイヤーが残っていない場合、ゲームは中断されます。 自分の場所を改善できる蟻塚のない選手がいたとしても、彼らは考慮されません。 蟻塚を持つ残りの各プレイヤーについて、彼が獲得できるポイントの最大数(敵の蟻塚をすべて破壊した場合)が計算され、他のプレイヤーが獲得できる最小値(すべての蟻塚を失った場合)と比較されます。 違いがプレーヤーの位置の変更または引き分けの中断を許可する場合、ゲームは続行します。 この条件に一致するボットがない場合、ゲームは中断されます。

(たとえば、ゲームには4人のプレイヤーがいます。ボットAがBとCの蟻塚を破壊する場合、ポイントは次のように分配されます:A = 5、B = 0、C = 0、D =1。ボットDがボットAの蟻丘を破壊しても、ポイントはA = 4、D = 3、B = 0、C = 0のように分配されます。したがって、Dが2位を超える方法はなく、ゲームは中断されます。)

(別の例。ゲームには4人のプレイヤーがいます。ボットAがボットBのアリの丘を破壊し、Bがまだアリを持っている場合、ポイントを獲得できます。しかし、ボットAがボットCの丘のアリを破壊すると、ボットBのゲーム内の場所を増やす機会が失われます。ボットBがボットAのアリの丘を破壊したとしても、ポイントは次のように分散されます:A = 4、B = 2、C = 0、D =0。)



移動回数の制限に達しました。

カードごとに、移動の最大数が設定されます。 それは各ボットに伝えられます。 彼が達成すると、ゲームは終了します。 主催者は、すべてのゲームの90%〜95%がこの方法で終了するように、移動の数を調整することを期待しています。



アリの誕生。



採集後、食べ物は蟻塚に入り、そこで新しいアリが生まれます。 食物の各スライスは、1つのアリを発生させます。 蟻は蟻塚でのみ生まれます。 同時に



各蟻塚で生まれるアリは1匹だけです。 食べ物がすべての蟻塚でアリを産むのに十分でない場合、蟻塚が順番に選択されます。

これは、出生直後にアリを削除した場合、アリの出生が蟻塚間で均等に分配されることを意味します。

プレーヤーは、蟻塚にいる蟻をそこに残して、蟻の出現に影響を与えることができます。



食べ物の外観。

すべてのカードは対称です。 これは、各ボットの開始位置が他のボットの開始位置に似ていることを意味します。 食べ物は対称的にカードに表示されます。

たくさんの食料を集める最良の方法は、地図を探索して大きな領土を占領することです。



戦いの結果。



互いに攻撃の距離にあるアリは、お互いを殺します(時々)。

対戦中に他のプレイヤーのアリよりも多くのアリがいる場合、あなたは(通常)生き残ります。

戦闘の結果はローカルで事前に決定されています。

戦いの結果: より正確な戦闘仕様があります。



ボットの入力データ

パラメーターの説明:

ゲームの開始時に、各ボットはゲームに関する初期パラメーターを受け取ります。 それらのリストは、「turn 0」を含む別の行で始まります。 その後、別の行に形式のパラメータがあります

 
      
      





値のタイプは、パラメーター名によって決まります。 現時点では、player_seedを除くすべてのパラメーターは32ビット符号付き整数です。 player_seed 64ビット符号付き整数。 ボットがなじみのないパラメータを受け取った場合、それを文字列と見なし、解析しようとしないでください。

パラメータのセットは将来拡張される可能性がありますが、パラメータがリストにある場合は削除されません。

現在、次のパラメーターがボットに渡されます。

 "loadtime" #   ,   "turntime" #   ,   "rows" #    "cols" #    "turns" #      "viewradius2" #    "attackradius2" #    "spawnradius2" #    "player_seed" #      ,    
      
      





すべてのパラメーターは、数字の文字列表現です。

すべてのパラメーターがボットに渡されると、「準備完了」が別の行で送信されます。その後、準備手順を開始できます。準備手順は、割り当てられた時間(loadtimeパラメーター)に収まるはずです。



進捗情報:

各ターンは、次のいずれかの行で始まります。

 turn turnNo end
      
      





「終了」はゲームの終了を意味します。 ゲームの勝者は、ローカルテストに使用する場合、ゲームの最終状態に関する情報を受け取ります。

ゲームが終了した場合、ボットには2行が送信され、参加者の数とフォームの最終ポイントに関する情報が送信されます。

 players noPlayers score p1Score ... pnScore
      
      







ゲームが続行されると、マップに関する情報が提供され、アリには次の形式で表示されます。

 w row col #    f row col #    h row col owner #     a row col owner #      d row col owner #     
      
      





情報の送信の終了は、「go」を含む別の行でマークされます。

あなたは常に番号0のプレイヤーと見なされます。最初に目にする敵はユニットで示され、2番目の敵は2ユニットというように表示されます。 したがって、ゲームの参加者の正確な数はわかりません。



水域に関する情報は、アリが初めてそれを見るときにのみ送信されます(負荷を軽減するため)。



食べ物、アリ、蟻塚に関する情報は、アリの視界に入るたびに送信されます。 食物と蟻塚は動きません。 食べ物が集められたり、蟻塚が視界を超えて破壊された場合、これについては通知されません。 アリがこのフィールドを再び見ると、食物や蟻塚の不在に関する情報を受け取ることはありません。



サンプル入力:



以下は、提示された状態でプレーヤーAが受け取るデータの例です。

 turn 0 loadtime 3000 turntime 1000 rows 20 cols 20 turns 500 viewradius2 55 attackradius2 5 spawnradius2 1 player_seed 42 ready turn 1 f 6 5 w 7 6 a 7 9 1 a 10 8 0 a 10 9 0 h 7 12 1 go end players 2 score 1 0 f 6 5 d 7 8 1 a 9 8 0 a 9 9 0 go
      
      





ここで、プレーヤーBが最初の動きから受け取るデータを提供します。

 turn 1 f 6 5 w 7 6 a 7 9 0 a 10 8 1 a 10 9 1 go end players 2 score 1 0 go
      
      







戦争の霧。

ゲームの開始時に、参加者にはアリが見る距離の2乗が通知されます。 現時点では、パラメーターは55であり、これによりアリの視覚半径は約7.4になります。

毎ターン、あなたの生きているアリが見る地図に関する情報のみがあなたに送信されます。



距離。

距離は、表示、攻撃、および出生半径に使用されます。 これらの値の2乗を使用して、浮動小数点数の使用を避け、整数を使用しました。

距離はユークリッド幾何に従います。つまり、斜辺の平方は脚の平方の合計に等しくなります。 2つのポイントaとbの場合、距離は次のように計算されます。



次の場合、点aと点bの間の距離はrを超えません。



出力データ。

ボットは、初期パラメーターを受信して​​ゲームの準備を完了すると、「go」行を送信してサーバーに準備完了を通知します。

各ボットは、北(「N」)、東(「E」)、南(「S」)、または西(「W」)のいずれかの方向に任意の数のアリを使って移動できます。宛先フィールドに水が含まれていない場合。 各動きは、次の形式で個別の行で送信する必要があります。

 o row col direction #    
      
      





行と列の番号は0から始まり、方向は文字「N」、「E」、「S」、または「W」として送信されます。 各ターンの終わりに、ボットは「go」行を送信して、注文の発行が完了したことをサーバーに通知します。







以下は、図で再生するプレーヤーAからのコマンドの例です。

 go o 10 8 N o 10 9 N go
      
      







図で再生するプレーヤーBからのコマンドの例:

 go o 7 9 W go
      
      







ブロッキング

動きは水によってのみブロックされます。 アリは水を見て攻撃できます。 ボットがアリに水の中に移動するように指示した場合、そのような移動は誤っていると見なされ、無視されます。

食べ物も動きを妨げることがあります。 これは、食物がアリのすぐ前に現れると起こります。 このアリを動かさないでください。次のターンに餌を集めます。



衝突

2匹のアリが同じケージに行く場合。 彼らは死にかけています。 しかし、アリが生まれたばかりの場合、アリは同じケージで敵と一緒にいる可能性があります(アリの丘はすぐに破壊されるようです!)



次に、カードの形式の説明とマップ生成プログラムの説明がありますが、これらはボットの作成に直接関係しないため、省略します。



その他

参加者が他のプレイヤーとの戦闘でボットの実際の動作を確認できるようにするため、参加者からコードを受信する前にボットの動作を実装するコードをプレイヤーが共有しないことをお勧めします。

一方、参加者は、参加者がボットを改善したり、テストやデバッグを簡単にしたりするのに役立つ戦略的なアイデアや一般的な問題について話し合うことを強くお勧めします。



All Articles