日記/2007-02-21

敵データをlua化した結果、しかしあんまり劇的な改善には至らなかったこと、
およびini関連以外の根本的なrequire速度問題もあることから、もっと別の対策を検討している。
少し前の日記でも書いた、段階的なAI機能強化処理というか、そういう感じ。

例えば、現状敵ごとの学習データは「すべての敵の情報を１つのファイル」に入れている。
が、これは周囲に敵が存在しなければ意識する必要はない。
また、敵がいたとしても不要な情報は不要：ROに存在する500種以上の敵のうち、一度に視界内に現れるのはせいぜい10種類といったところ。
その10種類のために、使いもしない490種以上の敵の分まで取り込むなんてのは無駄。
だから、「視界内に出現した敵限定で、敵情報ファイルを取り込む」ことができれば、格段に軽量化できる。

また別の例では。
体力が低下した際に、敵から逃げ回るような処理を持っている。
この処理用に逃亡位置を決める関数を準備している・・・が、元気に戦っている限りはこんなモジュールは不要。 だからこれはそういう状況になるまでロードしないようにすれば、軽くできるケースは増える。
そんな風にしていけば、一度にロードするAIソースの量を減らすことはできる。

正直、何度もいうように、AI側でどうこうするのはばかばかしい内容ですが。

正統派・邪道という考え方をするならば、Glenelgの現状の対策は邪道もいいところ。
現状でrequireが重いのがわかっているのだから、正統派としては以下のような手を打つべきだろう。

• 論理・アルゴリズムを検討、洗練化・最適化する。
• デバッグ用にしか使わないコードや、不要な変数を削除。
• 思い切って、あまり有効でない機能を削ってしまう。
  もしくは複数の類似機能を統合してしまう。

どんなものでも、自分が困らないと対応意欲は湧かないものです。
今回のAIロードが遅い件にしても、同じ。
例えばAIのロードを多用しない人には、あまり関係ない話だと思います。
ゲーム開始時やマップ移動したときに、「ちょっと重いな〜」と思う程度のはず。

友瀬はソロプレイヤー==テレポ狩りを多用する傾向があります。
つまり、テレポアウトの際に固まってしまう今回の初期ロード悪化には困ったので、いろいろ対処を考えています。
現状のGlenelgの分割ロード方式も、最善ではないもののテレポ狩りには次善の策だと思って作りこみました。

現状のGlenelgの動作をおおざっぱに言えば、
以前は「全体を一気に読んで1秒間完全に固まっていた」ところ、
今は「ちょっとずつ読んで、0.1秒ずつ20回止まっている」という感じのもの。
トータルでの「AI稼動開始までの時間」は、単純に全体を読むよりは確実に遅くなっていますが、その代わり、AIが稼動開始する前にもユーザー操作はできるようになっています。

テレポ狩りの際に期待されるのは「着地後、すばやく次の手を判断できる」ことだと思っています。
テレポアウト後フリーの敵が1体いたとして、それに攻撃を始めるのが１秒遅れても、多勢に影響はないです：それくらいの時間は、敵に接近するまでに消費してしまいます。
が、勝ち目のないMHに飛び込んでしまったとき、逃げはじめるのが1秒遅れたらそれは致命的です。
だから友瀬は、初期のホム性能は悪くても、即画面表示&ユーザー操作（==再テレポで逃亡）できるように、現状の手を選びました。

他にAIロードを多用するケースとしては、「安息→コールホムを行うことで、ディレイ削除を狙う」人。
この人には、現状のGlenelgはまったく向いていません。

また、今回の場合、PC環境による差があるのがとにかく大きい。
友瀬も、ネットカフェで（読み込み改善未対応の古い）Glenelgを動かしてみて、まったく初期ロードに困らなかったのに驚かされました。
最初に書いた通り、「人は自分が困らないとやる気にならない」ものです。
AI作者の環境で困らなければ対処する気はおきないでしょうし、もしやる気になっても検証はできません。
そういう話。

しつこく初期読み込みまわりの話。
いろいろ状況整理をした結果のメモ。

初回の人のメモから、再考察。†

RO内でのメモリ管理が変わったとみるのが妥当そうに思えてきた。

どういうことかというと・・・先日の初回限定の人の追加情報。
初回の人自身がコメントしている以下の内容：

コンパイル後25ｋb〜45kbあたりにこれ以上削っても早くならないラインがありそう。

これが非常に鋭い気がする。

つまり例えば、AI用に初期状態で準備されているメモリ量が、30KB程度。
これ以上のサイズのものを読み込みしようとすると、内部的にメモリーを再確保するのでその時間が負荷。
・・・なんてことは、非常にありそうな気がする。
もちろん、あくまで推論の域はでませんが。

AIスレでのAI比較記録から、再考察。†

なにかと悪者にされるfile io 系（iniファイル）だが、ことこの測定条件でのGlenelgについては、 io はあまり影響がないように思う。

というのは、この検証が「ダウンロード直後」のAIを使っていることに起因。
こちらの動作環境でのテストでは、Glenelgでのiniファイルのうち最大の負荷となっているのは 敵ごとの学習ファイルであり、そしてそれは初期状態では存在していない。
そして更にいうと、着地・テレポのような高速処理をしている限り、おそらくGlenelgは簡易モードでしか 動いていない：つまりrequireをつぎつぎやっている最中のはず。

敵情報ファイルのlua 化。†

「io.read + AIプログラムでデータ解析」が「require + lua内での単純代入」より遅いのは事実なので、Glenelg でも学習ファイルをlua化してみた。
結果は、確かに多少軽くなった気はする。
が、やはり目に見える負荷は存在する：手動操作でlua読み込みするような指定を作って試してみたところ、 一瞬の表示遅延がある。
参考までに学習ファイルは15KB。