Glenelg開発メモ/攻撃高速化 のバックアップソース(No.1)

お名前:
Glenelgの機能についてのメモ。~
自分のための覚書でもあり、利用者のための豆知識でもあり、他AI開発者のための参考情報でもあり。

AIによるホムの攻撃速度については、以前からAIの組み方によって速度差が生まれることが経験的に知られていました。~
また、2006.Feb.06パッチによる「ホム攻撃速度低下」についても、ある方法でそれを改善する方法が、これも経験的に知られています。

これら、経験的に知られている内容について、推論を行った結果をメモとして残します。~
ここにある内容は、あくまで2007.Feb.10時点の友瀬による推論です。~
推論である以上、それが絶対に正しいというものではないことはご理解ください。

----
*前提概念:戦闘速度にかかわる、現実。 [#qf79a76c]

ホムの攻撃速度にかかわるものには、以下の要素がある。

+AIサイクル。~
AIプログラムは、ラグなどの一部例外タイミングを覗けば、ROのクライアントから約150msec前後の周期で定期的に呼び出されている。~
この周期を便宜上「AIサイクル」と呼ぶ。~
AIからホムの動作(移動や攻撃)を行う場合、基本的にこのAI
サイクルが1つの基準となる。
+ホム攻撃周期。~
ROの一般的なキャラクター同様、ホムンクルスの攻撃は内部的に2段階の動きをしている。~
つまり「実際に攻撃を行っている期間」と、「攻撃後、次の攻撃を行えるようになるまでの間(ディレイ)」の2つ。~
別の言い方をすれば、この2つの期間の合計が「ホムの攻撃1回に所要する最低時間」となる。~
これを便宜上「ホムの攻撃周期、攻撃1周期」と呼ぶ。
+攻撃画像。~
ROのクライアントには、キャラクターが攻撃を行った際に画面表示されるアニメーション画像がある。~
これは複数の画像が一連の表示をすることで実現されるもの。~
その一連の表示全体にかかる時間を、便宜上「攻撃画像表示時間」とする。

上記の言葉の関係を、以下の図に示す。~
(図内の「AIサイクルの壁」については後述)
#ref(AttackCycle.gif,nolink,left,攻撃の流れ)
図の前提は以下の通りとする。
-AIサイクルは150msec、ラグなどでの不整脈なないものとする。
-攻撃1周期は350msec。~
-攻撃画像は、700msecで1回りとする。

*状況1.標準AIでの挙動 [#g7ae4748]

上記Step1.で説明した用語・図を用いて、標準AIでの攻撃時の実情を説明する。
なお、この内容は時期によって差がある。
**07.Feb.06以前での動作 [#r72a7400]
|AIサイクル|状況|
|0|Attack()命令実施。&br;ホム、攻撃開始。|
|1|Attack()命令実施。&br;だが、現在は攻撃1周期の進行中。実質なにも起きない。|
|2|Attack()命令実施。&br;だが、現在は攻撃1周期の進行中。実質なにも起きない。|
|3|Attack()命令実施。&br;攻撃画像は表示の途中だが、攻撃周期は終わっている。&br;攻撃画像の表示がキャンセルされ、次の攻撃開始。|

・・・という形になり、実質3AIサイクルごと:450msecに1回の攻撃になる。

**07.Feb.06以前での動作 [#vc9d2e58]
|AIサイクル|状況|
|0|Attack()命令実施。&br;ホム、攻撃開始。|
|1|Attack()命令実施。&br;だが、現在は攻撃1周期の進行中。実質なにも起きない。|
|2|Attack()命令実施。&br;だが、現在は攻撃1周期の進行中。実質なにも起きない。|
|3|Attack()命令実施。&br;攻撃周期は終わっているが、まだ攻撃画像が未完了。&br;実質なにも起きない。|
|4|Attack()命令実施。&br;攻撃周期は終わっているが、まだ攻撃画像が未完了。&br;実質なにも起きない。|
|5|Attack()命令実施。&br;攻撃周期、攻撃画像ともに未完了。&br;次の攻撃開始。|

・・・という形になり、実質5AIサイクルごと:750msecに1回の攻撃になる。

**まとめると。 [#l5d34d05]
2007.Feb.06パッチでの大きな変更は、ホムの攻撃に関して「攻撃周期」と「攻撃画像」の優先度が変更されたと思われる。~
その結果、ユーザーの見た目上、ホムの攻撃画像は完全に表示されるようになり、その代わり攻撃速度は低下した。

*対策1.移動によるモーションキャンセル [#u4189178]
いくつかのAIではすでに、Feb.06パッチに対する「速度改善」という対策が打たれている。~
これを採用すると、ホムは戦闘中に微妙な移動を繰り返すようになる。~
なぜ移動するかというと、戦闘の最中に無理矢理ホムの移動を行っているため。~
そしてそれは何故そうしているか、というと・・・以下のような理由。
これも、AIサイクルごとにどうしているかを記載する。
|AIサイクル|状況|
|0|Attack()命令実施。&br;ホム、攻撃開始。|
|1|Attack()命令実施。同時にMove()実施。&br;攻撃1周期の進行中なのでAttack()もMove()も無意味。実質なにも起きない。|
|2|Attack()命令実施。同時にMove()実施。&br;攻撃1周期の進行中なのでAttack()もMove()も無意味。実質なにも起きない。|
|3|Attack()命令実施。同時にMove()実施。&br;攻撃1周期は終わっているが、攻撃画像未完了なのでAttack()は無効化。&br;だがMove()は有効実施。これにより攻撃画像がキャンセルされる。|
|4|Attack()命令実施。同時にMove()実施。&br;前回のMove()完了してホム移動済み。&br;攻撃周期終了済み、攻撃画像キャンセル済みなので、Attack()処理されホム攻撃実施。&br;ホム攻撃中なのでMove()は無効化。|

・・・という形になり、実質4AIサイクルごと:600msecに1回の攻撃になる。~
つまり、移動しないときよりも攻撃が高速化されることになる。


*対策2.AIサイクルの壁と、多重Attack()によるAttack()予約。 [#t6af6190]
ホムAIは、AIサイクルごとにしか呼び出されないので、普通にAIからAttack()命令を実施している限りはその周期は150msecが1単位になる。~
上記の例では実際に攻撃にかかる時間は350msecなのに、もしROクライアントが悪さをしない最速でも上記AIサイクルの縛りから「450msec」のタイミングでしか攻撃が行えない:つまり100msecの無駄が生まれる。~
上記図の赤線部分がそれ:これを「AIサイクルの壁」と呼ぶことにする。

で・・・実は以前から、このAIサイクルの壁を乗り越える経験的な手段が知られていた:それが以前は「多重Attack()によるモーションキャンセル」と呼ばれていたもの。~
以前は詳しくわからなかったので「モーションキャンセル」と言っていたが、実はこれはAttack()が直接キャンセルを引き起こしていたのではなく、多重Attack()によって「AIサイクルがこなくても、攻撃が開始される」というものといえる。~

これも、Feb.06パッチ前後で状況が微妙に変わっているものと言っていいだろう。~
とりあえず、古い時の状況記載をする。

|AIサイクル|状況|
|0|Attack()命令多重実施。&br;ホム、攻撃開始。|
|1|Attack()命令多重実施。&br;攻撃1周期の進行中なのでAttack()は直接実施されない。&br;だがそれはRO内に「予約」される形になっている。|
|2|Attack()命令多重実施。&br;攻撃1周期の進行中なのでAttack()は直接実施されない。&br;だがそれはRO内に「予約」される形になっている。|
|2.5|AIサイクルの途中で、攻撃1周期が終了。&br;すでにAIサイクル1のタイミングで次のAttack()が予約されているので、それを元にホム攻撃開始。|
|3|Attack()命令多重実施。&br;上記2.5のタイミングで攻撃が始まってしまったので、攻撃1周期の進行中。Attack()は直接実施されない。&br;次の「予約」。|

・・・という形。~
攻撃はAIサイクルとは関係なく、攻撃1周期に準じた速さになる。

*まとめ.2007.Feb.06パッチに対する最速手段は? [#d9967c6e]
対策1の移動キャンセルと、対策2のAttack()予約の両方を実施することが最速になる。~
どちらか一方だけでは、どちらかの壁にぶち当たってしまう。
-移動キャンセルだけでは、AIサイクルの壁を越えられない。
-Attack()予約だけでは、攻撃画像による制限を越えられない。


ただし・・・これら2つの対策手段は、どちらも多少の問題をはらんでいる。

**移動キャンセルの問題点 [#kb86964b]

+あまり深刻でない問題:戦闘中にHP/SPの自然回復ができない。~
ホムのHP/SPの自然回復は、移動をせずにいることが条件。つまり、戦闘中に移動しまくることが前提の移動キャンセルを使用するかぎり、回復は困難。~
ホムの残存HP/SPなどから自生する仕組みが必要になるだろう。
+Move()に対応する通信パケットの爆発的な発生。~
戦闘中、最悪各AIサイクルごとにMove()コマンドが実施され、その分パケットが大量に発行される。~
通信量の増加はサーバ負荷になるため、ラグなどの一因となってしまうリスクがある。

**攻撃予約の問題点 [#zfcb76ee]
+Move()に対応する、通信パケットの爆発的な発生。~
通信量の増加はサーバ負荷になるため、ラグなどの一因となってしまうリスクがある。


**上記をかんがみて・・・ [#p758acf8]
Glenelgでは、両方の対策を内部に仕込んではいますが、どちらもデフォルトではOffになっています。~
ご使用は計画的に。