日記/2006-12-09

要は友瀬が言いたいことは、
『大多数の人にとっては意味が無く、
　逆にそれが意味を持つ相手にとっては削除対象になってしまう、
　つまりほとんど実際に機能することが無いようなプログラムを作るために、友瀬の貴重な時間リソースを突っ込む気はない』
ということです。

いちおー仕事で、ソフトウェアのセキュリティ関連方面の知識も持っているわけですが。

ホムAIは、しょせんベタテキストのもの。
いくらでも内容を見ることができ、いくらでも自由に編集できます。
それにどんなに不正対策を書き込もうが、強度面ではまったく意味がない代物です。
その不正対策自体を「簡単に不正に削除」できてしまうのですから。

もちろんLUAソースの読み方を知らない人には、そう簡単ではないかもしれません。
ですが、相手はWeb上から不正ツールとその関連情報をかき集めてくる人々です。
その道のプロが操るnProですら骨抜きにされる今、ホムAIで入れる対策にどれほどの価値があるでしょうかね。

事前コンパイルして、ソースを直接見せない形式でAI配布することも可能ではあるようです・・・そこまですれば意味があるかもしれませんが、これもそれこそ「Webから不正ツールをかき集める」人たち。
そのAIに固執する必要がどれだけあるかというと疑問です。

「不正ツールは認めない」
「自分のAIを、悪意ある行為に利用されたくない」
・・・こういう気持ち自体は非常に理解できますし、いろいろ考える熱意と発想には正直感心します。
ですが、残念ながら少々無理があるようです。ホムAIの環境では。

つーか、ね。
自己診断ならともかく、他のプログラムにまでちょっかいだすような代物の、どこが「ホムのAI」なんでしょうね。

AIスレで話題になっていた技術的話。
Glenelgが名指しで話題になっていた件なので、こちらに要約。
将来、開発メモに移すかも。

指摘された課題†

多くのAIでは、設定などを iniファイルにテキスト形式で記録し、起動時に読み込んでいる。
これは遅いから、lua ソースにしたほうがいいんじゃないか？
特にGlenelgでは、地図関連情報で大量のiniファイルがあるが、 luaの配列として書いてしまったほうがいいんじゃないか？

Glenelgでの現状と理由†

同じデータをrequireで取り込むのと、FileI/Oで取り込むのでは、もちろんrequireのほうが速いです。
それはあきらかで、議論の余地はありません。
にもかかわらずGlenelgでiniファイルを採用しているのは、それなりの理由があるからです。

1. 設定をユーザーが直接編集することを想定して。
   luaソースでは、編集ミスをするとAIそのものが起動できなくなる。
   iniファイルなら、エラー処理を読取時に行えるので、起動しないことはない。
2. 自動生成の手軽さ。
   AIがデータを出力する際。
   luaソースにするには、出力されるデータごとにさまざまな記載を行わなければならず、汎用的でない。
   iniでは、1つのデータ取り込み方式を作ってしまえば同じ処理でだいたいできる。

言い換えると、上記に引っかからないもの：つまりは基本的に固定値である情報については、Glenelgでもluaソース化する価値はあると思います。

mapinfoでのもう１つのやっかいな話†

Glenelgでmapifo関連で現状の形式を採用したのには、もう１つ別の理由があります。
問題はデータ量。
友瀬が地図関連を設計した際の考えでは、地図情報をプログラムに組み込むということは、全世界のマップ情報をソースに書かなければならないと思いました。実際、カプラさんなど一部のNPCについては、全マップにある情報がluaソース化されています。
しかし多くの場合、1回のAI起動時に参照するデータは「ホムが現在いるマップに該当する情報」だけです。
具体的な数量をいうと、ROに存在するマップは200近く。1回のAI起動では、そのうちの１つしか使わないのです。
つまり、もし高速のlua形式にしたとしても、その分読むこむデータ量が200倍に膨れ上がるというリスクがあったわけです。
「必要最低限のデータだけをFileI/Oで取り込む」のと「不要なものも含めた全データをrequireで取り込む」のでは、きちんと測定しないと、どちらが速いかわからないですよね？
正直そこまで労力をかける気はなかったですし、また今後も地図が増えていくことを考えると、 どちらにしても「不要とわかっている」データをわざわざ読み込むのは愚劣と思いました。

それが現状の「1マップごとに別ファイルで情報保存」の理由です。

そして友瀬の間抜けな点：あるいは、LUA知識の弱さ。†

ともあれ。
どんな状況であれ、わざわざAIスレで性能を指摘している以上、なんらかのバックグランドとなる知識を持っている人の可能性が高いと判断。
こちらの都合をぶつけてみる価値はあると判断しました。
上記の「大サイズデータ+luaソース」vs「小サイズデータ+FileI/O」、比較検討できるネタ、ない？と。

で、かえってきた答え。
「1マップ単位でluaファイルにして、必要になった時点でrequireすれば？」
要は「小サイズデータ+luaソースにすればいいんじゃね？」ってこと。

Σ('-'つ)つ
・・・Cとかと違って、プログラム実行中に動的にプログラム実体を追加できるんだよね、LUAって。
だから、「全世界のデータを１つのソースに」する必要はまったくなくて、iniファイルと同様に「そのマップの分」だけを 切り出したソースを作れば、初期起動時は必要分だけで起動し、状況がわかってから必要なソースを選んで取り込めると。

よくよく考えれば、CなどでもDLLやプラグインなど、似たようなことをやっているものはあるわけですし。
そういう流儀のない、組み込み屋ゆえの思い込みってところでしょうか（＾＾；；；

というわけで、このあたり、気が向いたら手をいれます（＾＾；；