2006/9/17 (日)

掲示板で書き込まれていた、「ホムが状態異常の敵をわざわざ選んで攻撃しているように見える」件。
ちと思うことがあるので、コメントしておきます。

まず前提として、キャラ(敵味方とも）の状態異常は検出できません。つまり、それを見て動きを変えることはできませんので、それを見て攻撃優先度を変えることはできません。
ただ、現状の「睡眠している敵から殴っているように見える」というのも偶然の産物だけではない、と友瀬は思います。
これ、おそらく、ROクライアントでの敵優先度がかかわっています。

どういうことかというと・・・ROクライアントでは、近くに複数のオブジェクトがあると、それに対するカーソルスナップ順がある程度クライアントで決められています：例えばアイテムの上にいるホムがいると、アイテムにカーソルがあってしまってPPしづらい、とかありますよね？

これと同じことが、実は敵同士でも起きています。
複数の敵が（同じセルもしくは隣接しているセルなどにいて）クリックしづらい状態ってありますよね？
あれがまさにそうで・・・マウスカーソルの近くに複数のオブジェクトがある場合、ROクライアントが決まった順（おそらくはID順）で対象を選んでいます。
つまり人間は、意図せずして「ROクライアントが選びやすい」敵から攻撃していることが多いのです。

で、実はこの順、現状の（公式およびGlenelgを含めた多くのユーザー製の）AIでの敵優先度とも合致しているようです。
例えば実際に、複数の敵が1セルに重なっていてそのうちの１体をホムが攻撃しているとき、ケミがその群れに（普通にカーソルを合わせて）白兵戦をしかけてみてください。
まず間違いなく、ホムと同じ敵を殴ることができるはずです。

敵が睡眠しているということは、おそらくはそれをケミが攻撃していたということ。
そして前述の理論どおり、それはおそらく「ケミ==人間がクリックしやすい、ROクライアントが優先しやすい敵」。
それはホムも選びやすい、という推察は的外れではないと思います。

ということで。
実はホムの索敵ルールをちょっといじると、「同じ敵を殴らない」可能性をあげることは不可能ではないと思っています。
今まで索敵して「先に見つかった」ものを対象に選んでいるところ、後続がいるならちょっと後回しにして「後があるならそれを対象に」というようにするだけで、だいぶ変わると思います。

ただし、ここまで読めば判るように、あくまでクリック順を見ているだけで、本来やりたい「状態異常を見分ける」のとはまったく別の話。
理論的にも確実性がなく、労力の割に報われないような気がするので・・・多分対応しません （＾＾；；
あしからず。

2006/9/15 (金)

人は誰でも必ず、自分の中にボーダーラインを持っています。
ですがその位置は、人によってまちまちです。

友瀬は「あるモノをある理由で嫌っていて許す気がない」ので、 自分自身が作るものでその「ある理由」を犯すことはしたくないだけです。
その「ある理由」に抵抗があるかないか、人によって差はあると思いますが。

2006/9/13 (水)

ホムに関するアンケートが新たに実施されているようです。
こちら

まだほとんど宣伝がなされていないようで、投票数も不明。
多重などの対処もなされているようです。

以前のアンケートのときも少し書きました(8/20付)が、こういうアンケートはどうしても偏りが生まれます。
現時点では、「ホムAIスレでの宣伝しかなされていない」様子なので、当然自動的に「AIを触ることに興味がある人」というフィルターがかかっています。
またもし将来あちこちに紹介がなされたとしても、こういう任意形式のアンケートに答えるのはやっぱり「話す気のある人」に限られます。
変な言い方をすると、ですね。
どうしても「声の大きい・主張の強い人」の意見しか集まらないのです。

もちろん「価値がない」とは言いません。
そこに集まるのは間違いなく各人の生の意見ですから。
鵜呑みにしないで判断することが必要になる、と言っているだけです。

---

某所でのGlenelgの評価を見ていて、誤解されているかな、と思ったこと。

Glenelgは、基本的には「状況による『学習』」をAIが勝手にすることはありません。
Glenelgの学習は完全にユーザー操作によるもので、Glenelgが勝手に何かを覚えるということは（少なくとも今のところは）ありません。

本音を言えば、自動学習はさせたいです。
ですが、そのためには行動に対する結果のフィードバックが必要で、しかしそれが非常に限られたものであるため、Glenelgではあきらめています。

自動学習が不可能といっているわけではありません。
ただ、現状取得可能な情報だけで学習すると、どうしてもその学習にはリスクや制約が発生します。
つまり、学習した結果が不利益につながる可能性（例えばスキルを出してくれない、例えば攻撃してくれないなど）があります。
現状のGlenelgでは、それを嫌って避けているというところ。

2006/9/12 (火)

RO以外にもいろいろあるので、ちと放置気味ですが。
とりあえずAI関連、今後の話。拍手的な。への返信でもあります。

今手をつけていること。†

• ソース整理。少々規模が大きくなってきたのと、論理的におかしな点がいくつか見つかっているので。
  別に現状のモノが動いていないというわけではないんですが、論理がおかしいということはデバッグが難しい、ということなので。
• 英語コメント追加。上記のついで。
  「海外の人が見る」ということの想定よりは、単に自分の英語力アップのためです（笑）
  やっぱり使ってないと、性能が落ちる（＾＾；；

• チャットコマンド：地図名指定。
  • 関連して、従来の地図指定（画面上でのIDスクロール的操作）は廃止にしようと考えています。

相談されていることとその状況。†

• 簡単なパーティ登録手段。
  難航中。
  技術的問題ではなく、それ以前に「適切な方法を思いつかない」のが大きな理由。
  「同じ敵を一定時間/回数以上殴っている人」で考えたけど、それだと攻撃しない人（支援プリとか範囲しか打たないWizとか）をいつまでも登録できない。
  かといって、ちょっとした操作を伴うのなら、現状の「その相手をA+S+右」でいいじゃん、と思えて。

• イクラ爆弾との共闘考慮。
  「ボスが攻撃したのがイクラなら、それは無視（ボスと一緒に殴らない）」ような処理をいれようかと検討中。
  ただし、イクラは「ボスが作ったモノ」か「天然モノ」かの区別がホムにはできないので、伊豆での狩をする可能性から標準機能にはせず、カスタマイズ項目かなぁ。
  ともあれ検討中。

2006/9/7 (木)

AIスレで、 「どうやらモーションキャンセルのための多重Attackで、ROクライアントが重くなるケースがあるらしい」という内容の話が進められています。

友瀬的には「そら、見たことか」「何を今頃あわててるんだか」という気持ちなんですが（＾＾；

当時から「理論的に説明できないんだよね」と常々言っていた項目です。 (Glenelg開発メモ：モーションキャンセルに関するメモ参照)
何が起こるかわからないから、Glenelgではカスタマイズ項目にしていたわけで。
やはり自分の感覚を信じてよかった、ということにしておきます（笑）

---

英語のコメントか・・・
どちらかというとマイナーなAI、英語圏から見られるのかというとかなり疑問が・・・
でもまあ、難解といわれるAIだしなぁ（笑）
気が向いたら、ちょこちょことつけますか・・・

---

すまん・・・らるくあんしえる、ふつーに歌を知らない（爆
しょせん中身はオジサンということをご理解ください（＾＾；；

---

万人が「AIをいじることが楽しい」「楽しいとは思わないけどいじることはできる」というわけではなりません。
ただ単にゲームとしてROを遊ぶ場合に、AIをいじれない、いじることが苦痛な人だっているはずです。
そういう人たちに対して、明らかに異常動作が起きる・対処方法がない形のものを提供することは、友瀬は正しいとは思いません。
「保証できないものを、黙って渡す」
「保証できないものを、保証できないよと言って渡す」
「保証できないものを、保証できないから心配ならこうしてといって渡す」
どれが正しいこと・・・相手から望まれることですか。

裏で研究することも、おかしな現象があるから周囲の人と相談するのも、いいことです。友瀬だってやります。
でもそれは「AIを触りたい」人たちの間だから成り立つ話で、「AIを触りたくない」人には無意味です。
そこまで気を使うかどうかは、人それぞれ、ですがね。

2006/9/6 (水)

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

---

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

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

･ﾟ･(ﾉД`)･ﾟ･

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

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

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

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

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

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

2006/9/5 (火)

AIスレのほうにも書いたのでこっちでも。

公開自体はもうだいぶ前になりますが、冬物語の人がブログで「/savechatで保存したログを解析すれば、ケミや周囲の人の発言をAI側に取得できる」という点を利用したライブラリを公開しています。

友瀬もこれにはは興味を持っているのですが、いろいろ事情があって今のところ対応していません。
多くは工数面なのですが〜（笑）

使い方としては・・・その仕組み上ユーザーは「コマンド入力→savechat」という2手を行わなければならないので、リアルタイム性の高い指示類には使いづらいと思います。
逆に画面操作では教えづらい複雑な情報を渡すために使えるかな、と考えています。
今のところ構想として考えているのは、以下のようなもの。

• 地図名入力。
  　/where入力→/savechat で、そこに現れたマップ名をホムで拾う。
  　地図利用しているAI独特（笑）
• リーフ、赤スリムPot本数登録。
  　カートから手持ちに動かすと「赤スリムｎ本取得」系のログが残る。
  　これを元に、ケミが何本Potを持っているか判断。

で・・・友瀬、というかGlenelg固有の話をすると、この機能を搭載するとしても、おそらくは文字チェック動作は「命令待ち状態」でのみ実施することになると思います。
ファイルアクセスはどんなにわずかでも時間を使います。
戦闘中には使いづらそうなものなので、その負荷は減らしたいな、と。

話は微妙に変わりますが、上記の内容にも絡んでいるのでついでに。
拍手的な。で、次のようなコメントをもらいました。
「リーフの赤Potチェックは要らなそう。Potがない状態で使用しても画面に何か出るわけでもないし、SPも減らないし。」
情報ありがとうございました。つまり、Potの有無にかかわらず使ってもあんまり悪影響はなさそう、ということですね。
でもたぶん友瀬は、なんらかの方法でPot有無をチェックすることになると思います： Pot無しなら、例えば「常時緊急回避」をしたっていいわけなので、そういう動きを変えるトリガーとして使うと思います。
まあ、まだ机上の空論の域なので、確定ではないですが（＾＾

2006/9/3 (日)

だ〜、日がかわっちまった・・・

ともあれ、ver0.42リリース。
依頼のあった「オーナー移譲」相当機能を追加。
ただし・・・何度か書いたように具体的な用途がイマイチ見えていない状況での実装です。
役に立たなくてもあしからず。

あと、AIスレで話題になった「強化系スキルのかけなおし条件」についてちょっと追加。
Glenelgの場合「敵ごとの優先度」を指定させているので、これをもとに現状がどれだけ危険かを判断しています。
ただし・・・Glenelgでは敵が「あとどれくらいで死ぬか」が判らないので、微妙に不自由があるかもしれません。
最悪のストーリーは「標準的優先度を持つ最後の1体の敵に、一撃白兵戦を仕掛けた時点でスキル効果切れ」というケース。
この場合、その最後の一体には強化スキル無しで戦ってしまいます。
うまくないと感じたら、カスタマイズでいじってください。優先度合計を1以上にしてやれば、いつでも再使用してくれます。

次は友達登録関連の見直しかな・・・ちとソース全体が大きくなってきたので、また見直しもしたいところ。
いずれにせよ、今週は本業がかなり多忙そう＆来週末は外出予定、しばらくAI更新は滞りそうです。

---

AIスレを見ていて思ったこと。
やっぱりテンプレサイトって大きいんだな、と。

2006/9/1 (金)

もともとバニル専用といっていたGlenelgですが、強化スキル対応したことで多くのホムでもそれなりに使えるようになったかな、と思う今日この頃。
で・・・強化系以外にも存在する「他ホムスキル」についてどう考えているかをコメント。

リーフ・治療の手†

それなりに対応したいと考えています。
そしてそれなりに課題があるので、使いやすさ・確実さのバランスから課題対策方法を検討中。

• 戦闘中の使用アルゴ
  それなりに高価な赤スリムを使う以上、休憩中の使用はまずなく、戦闘中の緊急回復用と考えます。
  PCの食料連打と競合する結果になるので、どう使うか考え中。
  スタンとか凍結とかの状況がわかればそこを狙うのですが・・・できないですし。
  悩んでますが、たぶん単純しきい値になっちゃうと思います。
• 赤スリム有無チェック
  使用後のSP減少・HP増加などからチェックしているAIが多いようですが、リスクがあるので回避。
  初めから「何本持っている」というのを教えるような方法を考えています。
• 緊急回避との競合
  緊急回避は戦闘中の意味が薄いので、「戦闘中はかけなおしをしない」ようにする仕組みを作ります。

アミストル・キャスリング†

興味はあるものの、今のところ対応予定無し。
基本的に「アミストルが身を挺してケミを逃亡させる」用？
逆に「危ないホムを戦闘ケミが身を挺して逃亡させる」とかできる？
前者専用としても使った場合にタゲ移りがどうなるか、まったく判らないのが、大きな問題なのです。
他に比較できるスキルが無いのも、想像できない原因。
まさに「自分で使ってみないと判らない」スキルだと思います。

バニル＆フィーリルの進化奥義†

対応予定無し。
コストの信頼度低下というのが非常に痛いので、AIで勝手に使っていいものとは思えないため。
フレーバー的にも「ホムが勝手に主人を嫌いになりつつ暴れる」ってのはどうも・・・「やりたくないことを主人に強要されたから、嫌いになりつつ暴れる」ならわかるんですが。
フィーリルのSBR44連打はそれなりの戦術として確立されているみたいですが・・・まあやりたければ適当に改造してください。ムーンライトのところのスキルIDを書き替えて、オートスペル発動率を100％にすればいいだけです。

---