日記/2006-09-06

なんか一部AI作者同士で情報や感想のやりとりが活発になっていて、うれしい気がする。

安っぽいAIの人が最近のブログでAIごとのGV対応について検証しています。
友瀬自身がGv・Pvにまったく興味がないので、そっちの方向については何もコメントできないしする気もないですが・・・Glenelgの解析に対するコメントが興味深かったので、これについて個人的な意見を。

全体的にローカル変数同士でのデータ受け渡しが多く、関数もやたら細かいため、処理があっち行ったりこっち行ったりしてて解読に骨が折れます

･ﾟ･(ﾉД`)･ﾟ･

ただ、一度仕組みを熟知すればメンテや拡張は簡単そうだと思いました

狙い通りに読まれていただいたようで。
関数とその中のローカル変数多用というのは言ってみれば「処理のブラックボックス化」なので、関数の（関数名や関数前半にあるコメントから読み取れる）お題目さえ理解できていれば、その中を詳しく知らなくても全体の流れが読み取れる、ということになります。
別の言い方をすると、確かにソースを順番に読んでいこうとすると「あっち行きこっち行き」で追いづらいのですが、１つ１つの関数（だけ）の動きを理解する分には楽なはずです。複雑な部分を別の関数にまかせてしまっているので。
例えば敵を探すGetEnemy()は、AttackOrder[]に入っている「索敵順番」どおりに索敵をしている、というシンプルなものです。どの味方の敵を優先索敵するのかはCreateAttackOrder()の中で「索敵順番をAttackOrder[]内にいれてくれる」ことになっていて、また個々の索敵ルールはまた別の関数です。味方優先度をいじるときは、CreateAttackOrder()をいじればいいし、個々の味方ごとの索敵へはまた別の関数を使えばいい。そういう風に分離がなされています。
ある程度大きな規模のプログラムになるとその全貌を暗記することなどできないので、こういうつくりにしないと後がやっかい・・・そう思っています。

また、ソースの分類も意味があります。
ソースファイルの数が少ないことが魅力になっているAIが多いのも事実ですが、分離するならある程度論理的に分けておいたほうが、後からの対処が便利です。
例えば今回のGv関連の話であれば、問題になるのは処理順とタゲ回りだけ。
ならば、おそらくはAImain.lua と actors.lua内だけ解析すれば判断できるはずです。
これ以外のソースにある記載は索敵には一切影響を与えないので、このソース内にない関数はその関数名から「たぶん〜ってことをやってるな」という予想だけして、解析しないですむはず。

ちなみに・・・コメントについては、多分多すぎると思います。
コメントには大きく「書くべきではない」「書かなくても良い」「書くべき」という３つの種類があって、友瀬は「書かなくても良い」レベルの内容も結構書いており、その分ソースが膨れ上がっている（全貌を見づらい）部分はあると思います。

「書かなくても良い」というのは、AIのアルゴリズム（思考論理）に関するところが多いです。
本来は「詳細設計仕様」とかを書いてそっちに記載すべきものなのですが、ソースに直接コメントしてしまっているので。
アルゴリズムはプログラムとは別物なので、本当は別のところに整理すべきなんですが・・・まあ趣味でのプログラムなのでこんなところで。

まあ友瀬はプログラマとしては２流なので、コメントの有無は別にしても、ソース自体が綺麗だとは思ってませんが（笑）