calendar_viewer 日記/2007-01

new<< 2007-1; >>old [日記]
1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16	17	18	19	20	21	22	23	24	25	26	27	28	29	30	31

2007/1/31 (水)

可能な限りAIで以前（11/17ころ）から話題にあがっていて、こちらも興味がありつつも手をつけていなかった件で、先方でちょっと動きがあったようなので。

文字だけだと判りづらいので、こちらも以前から集めていた情報を元にして図示すると、以下のような状況と思われる。
もちろん、パケット追跡だとかプログラム解析をしたわけではない、あくまでクライアント・AIログから見えるレベルでの情報なので、たぶんに予測が入っていることはご理解いただきたく。
この図は、ホムの攻撃周期（Attackモーション＋攻撃後ディレイ）が350msecと固定、2回の実攻撃で敵を倒した、という条件のものなので、そこは誤解なきよう。
画像幅が広いので、端が切れて見える人もいるかも。幅を広げてみてください（＾＾；；

単純に言ってしまえば、

標準AIではAttack()呼び出し回数が少なすぎ
現状の多くのAIでの「高速化」はAttack()回数多すぎ

→だからAttack（）発行を「毎回」よりは間引こうよ。

ということではあるのですが（＾＾；
難しいところは、やはりホムのASPDがAIからは判らないところか。
上記図では「350msec周期」と仮定したが、ここは結局ホムの性能次第なので。
結局その「まびき」具合の加減がどれくらいか、調べるのがポイントになりそう。

また、「複数Attack()による高速化」にはもうひとつ大きな疑問が残っている。
上記の「送りすぎた攻撃」に起因するホム停止部分。
まったく同じ条件（多い攻撃回数）で動かしていても、まったく重くなることなく動作してしまうケースもなぜかある、ということ。

単純にサーバ側の負荷量だ、と言い切ってしまうには情報が不足している。
かといって、これ以上踏み込んだ調査はお行儀が良くないのでやりたくないんだよね・・・

おとといの「CVの対象率」の件。
horoさんの「6.7%」発言は、結局勘違い、ということらしい。
友瀬もそれから追確認はしていないのではっきりしたことはいえないが、とりあえず「根本的におかしい」という話ではなさそう。

・・・やっぱり、人を疑うのは極力避けようと思う（＾＾；
・・・いやまあ、現実問題として「ホムが回復しない」未実装をかれこれ１０ヶ月放置している相手なので、友瀬も勘が鈍ったということにさせてください（＾＾；；；

拍手的な。でも、ときどき似たような指摘・意見をいただいて、同じところにいる人はいるんだな、と思っていることですが。

友瀬は本質的には、完璧な~~横殴り対策~~迷惑をかけない動作というのは無理、だと思っています。
というのは・・・これもだいぶ前の日記に書いたのですが、横殴りという言葉自体が非常にあいまいで、人によって解釈の範囲が異なるもの、だから。
定義があいまいである以上、万人が納得する機能はありえないのです。

例えば、タゲ移りが絡んだ場合。
ホムを攻撃していた敵が、なんらかの理由で第三者にタゲ移りした。
この場合、ホムはどうするのが正しいですか？

あなたが「今までホムに攻撃してたんだから、ホムが取り返すのがあたりまえ」と考えたとしましょう。
ですが相手が「さっきはどうか知らないが、今は俺を殴ってんだから、俺のもの。」と考えたらどうなりますか。
ホムが取り返すために攻撃したら、それは立派な横殴りとなります。

あなたが「さっきはどうか知らないが、今は相手を殴ってんだから相手のもの」と考えたとしましょう。
ですが相手が「今までホムに攻撃してたんだから、ホムが取り返すのがあたりまえ」と考えたらどうなりますか。
ホム（およびその飼い主たるケミ）が無視したら、それは立派ななすりつけとなります。

もちろん「一般的にはこうだろう。」という最低限の方針はあると思います。
だから、それをさまざまに厳密にして「迷惑をかけづらい」方向にAIを作ることは可能ですし、そうすべきでしょう。
が、万人にそれが受け入れられるかはまったく保証の範囲外です。

あ～・・・誤解生みそうだから、あえて書きますと。友瀬が言いたい本質は、
「あやしいケースについて、万人に納得できる定義を作ろう。」じゃないです。
友瀬が言いたいのは
「あやしいケースについては、言葉なりエモなりでネゴればいいじゃん。」です。

タゲが移った。移された。

「ごめん、うつっちゃった。」
「気にすんな、いるならもってけ。」
「いえいえ、ゆずります。」
「そうか、ではごちそうさま。」
「ごめん、うつっちゃった。」
「気にすんな、いるならもってけ。」
「では、取り返しますね。ご迷惑をおかけしました。」
「気にすんな。」

これじゃあダメなんですかね。

まあ問題は、それをできない「会話ができない物体」がたくさん棲んでいるってことなんだけどね。

2007/1/29 (月)

まずは、人間の話をしましょう。

横殴り？そんなの人間が普通にやってたっておきるじゃない。
ミスってやっちゃったらすぐ手を止めて「ごめん」って謝って、
やられたほうも「今後は気をつけろよ～」って受け入れて、
で、やってしまったほうは以後気をつける。それでおしまい。

これで悪い関係になるか、といったらそんなことはないはず。
むしろその後同じマップですれ違ったら、互いにエモとか声かけとか支援類とかしあう、行きずりの共闘者という「気持ちいい」関係にすらなれる可能性もある。

人間は感情の生き物。
気持ちいい対応をしてくれた相手には、気持ちいい対応をしたくなる。
無粋な対応をしてきた相手には、冷たい対応をしたくなる。

そして、人間はミスを犯す生き物。
もちろんミスしないことが最上だから、やってしまった側はそれを「悪いこと」と自覚するべき。
だがやられた側は、ミスの結果におきたことは可能な限り認めるべきだろう。

だから、問題は「ミスに対して悪びれない」行動にだけある。
「手を止めずに最後まで殴りきる」とか、
「謝罪の言葉一つも言わない」とか、
「以後も気をつけることなく何度も繰り返す」とか。

さて、AIの話。
上記を、あなたの使っているAIに当てはめて考えてみましょう。
あなたのホムAIは、どうですか？

残念ながらGlenelgでは、絶対に「悪びれない行為」をしないとはいえません。
一応横殴り防止はいろいろやってますが、ROの仕組み上絶対とはいえませんし・・・
なにしろ感情がないですから、万一の事態でも、謝れないもの。
だからホムの粗相には、友瀬は自分で謝ってます。

ああ。だから人間は、敵を作るのは簡単です。

相手がミスって横殴り、即手を止めて「ごめん」って言ってきた。
敵を作りたかったらこういえばいいんです。
「なにやってんだ、このグズ、ボケ」

・・・友瀬には到底できません。

別に「横殴りしていい」って言ってるわけじゃないですよ？
相手が認めているミスを、必要以上にねちねちやったっていいことはなにもない、ってだけ。

うれしいことをされたら、喜んだりお礼を言ったりする。
嫌なことをされたら、怒ったり文句を言ったりする。
それが普通の人間だと思う。

だったら、なぜ。
人に文句を言われて怒ることができる人間が、
人から文句をいわれたときに
「自分が相手に対して嫌なことをしてしまったのか？」というような考えに至らないのか。

「やられたから、やりかえす。」
それには正義は存在しない。
最初にやった側にも、やりかえした側にも。
だから、やりかえした側が正義を振りかざすのは間違っている。
だが同時に、その引き金になった行為をした側が正義を語るのもおろかな話。
相手が「やりかえしたくなる」ような行為を仕掛けたのは、どっちが先だい？

もちろん、人の価値観には差がある。
自分なら許せるからと踏み込んだら、相手にとっては許せない、そういうこともあるだろう。
相手が狭量・変人・悪意を持った人など、「相手が普通じゃない」可能性があるのも否定はしない。
なんでもかんでも相手を受け入れろなんて、無茶はいわない。
ただ、こころのどこかで「自分のほうが普通じゃない」可能性も忘れるな。
人のせいにばかりしていたら、自分が見えなくなる。
誰だって、日本人としたって一億分の１以下の存在だ。

この文章を読んで、一笑に付せる人は、友瀬とは価値観があわないのでしょう。
同時に、何を言われても腹を立てない、仏様のようなすばらしい方なのでしょう。
もしくは、すべてのことを否定できる、独裁者のような方なのでしょう。
まあ、こういうタイプの人間はそうそういないと、友瀬は信じています。
つーか、これに引っかかるようだと、普段からいつも誰かに喧嘩売っているとしか思えないのですが。

う～ん・・・
バニルのスキル、カオシックベネディクション。
きちんと実装されているのかな・・・

きっかけは、可能なかぎりAIでのBBSでのやり取り。
LV3カオシックは、周囲に敵がいなければ「ホム５０％、ケミ５０％」の確率で回復が発生するはず。
現状カオシックのバグ？でホムは回復しないので、実質的に「５０％で当たる、ケミ回復スキル」というのが現状動作のはずになります。
なんですが、おおざっぱにいうと、

友瀬曰く、（今までの感覚的に）確かにおおむね５０％で回復している。
- だが後から友瀬が50回試行したところ、21/50でケミ回復。
  確かに５０％よりはちょっと偏ってそう？
horoさん曰く、6.7％くらいしかケミには行かない。

・・・っていう感じ。
友瀬自身、もともと「確率論なので、SPが余るときに回復できればいいや」くらいにしか考えていないので、確率までは検証してなかったのは事実。
多少のばらつきなら確率論なので判りますが、上記２例は５０％からはだいぶかけ離れている。
これだけ差があるとなんかいろいろ怪しい気がする。
(1/30追記。「友瀬とhoroさんとの差」じゃないよ。「友瀬と公式との」「horoさんと公式との」差よ。)

数をこなして確認したいところなんだけど、カオシックの結果はAIにフィードバックされないので、自動集計できないんだよな・・・
使用者の皆さんの様子を聞いてみたいところ。

2007/1/28 (日)

うひゃぁ。
http://silica.seesaa.net/article/32228178.html (冬物語の人のブログ)
褒めすぎです。（＾＾；

まあ確かに、標準AIはかなり無理矢理なつくりで、はっきり言って関数分けしている意味が少ないかな、という感じ。
とはいえ、Glenelgがそこまできちんとできているかというと、まあ、それなりなんですが（＾＾；；；

もちろん、友瀬も一応ある程度意識して書いてはいます：libディレクトリ以下は、ほぼ完全に切り離せるようにしています。
ですが・・・やはり本質的には標準AIをベースにしているので、まだまだGlobalを使っている部分が多いです。
本当はもっときちんと分離したいところですね。

2007/1/27 (土)

あ～。チャットコマンド、判っていた罠にはまってたさ・・・
敵名に半角￥が絡むとおかしなことが起きるんだよね。
つーわけで、現状のv0.46系でのチャットコマンドだと、一部の敵（例えばソヒーなど）を、適切に指定できません。
近いうちに直します。

つーか、ローカルではもう修整済みなんだけどね（＾＾；
SGモードの微調整＆ヘルプ記載するのが面倒で。

プライベートでいろいろあって、ROはのんびりと。
ふとプロンテラを歩いて回っていたら、結構値段が下がってたので、いろいろ購入。
火宝剣と、こんなんを買い雇いました。

さすがに予算が激減したさ（＾＾；
というわけで、レモン貯金を少し吐き出しています。

2007/1/18 (木)

ホムAI機能比較表で、管理人の方がメモっていた内容に、Glenelgもひっかかっているので、補足。

手動での先行非先行切り替えについて。
結構なAIで○が付いているにもかかわらず、Glenelgでは未搭載のこの機能、きちんと理由があって採用していません。

一応ヘルプファイルやだいぶ昔の日記にも書いてあるので詳しくはそちらを見て欲しいです。
とりあえず概要を書きますと、友瀬はこの機能について「わざわざ手動操作しなくても、自動判断できる」と思っているので、手動操作は準備していません。
人間が「アクティブを止めたい！」と思うような状況をAI判断してとめられればいいわけなので。
そう、これは結局「横殴り防止」と同じ線上にある機能なので、きちんと判断ができるのならそんな切り替え操作はいらない、というのが友瀬の想いです。

まあ、火壁問題とか、怪しいのがあるのは否定しないです。
そういうこともあるので、Glenelgでは「先行索敵距離は３」とか「他PCが画面内にいたらパッシブ動作」とかいう、非常におとなしい設定をデフォルトに選択しています。
もちろんカスタマイズでそういうところはよりアグレッシブにすることもできますが、ね。

つーか、火壁だけならそんなに頻度が高くないので、ALT+Tの待機で十分じゃない？

2007/1/17 (水)

・・・ホムAI開発者って、学生が多いんだなぁ・・・
就職して結構たつおじさんとしては、なかなか切ないわ（＾＾

・・・やっぱり、「おじさん」よりは「おじさま」って呼ばれたい（笑）
・・・「おっさん」の戯言なので、聞き流すが吉。

2007/1/16 (火)

ちょうど一年前。
友瀬は、FCASセージ・CathyでのSignクエストを実施していました。
当時の日記がこちら（2006/01/16の日記）
正直かなり大変で、特にサンゴ集めとセリン・DI戦は大苦戦した記憶があります。
実際完全に終わらせたのは3月でしたし。

で。実は先週末の金曜日に上記を思い出しまして。
思い立ってホムケミ・ViceでSignをやってました。
↑はい、重要。「やってました」と過去形です。
厳密にはあと数手：炭鉱の鍛冶屋に預けて時間待ちする部分が残ってるんですが、まあもう山場は終わっている、というわけです。
まあ、ベノメナ狩りは以前にやってて、サンゴは山ほどあったという布石はあったのですが。

なんていいますかね。
・・・FCASセージが如何に趣味キャラか＆ホムが如何に強いか、というのがよくわかりました（笑）
いくらDIがスキルを使わないって言っても、白Pot15本くらいで倒せるって、なんだよ（＾＾；；；

他にも、逃げ回る主人を守ってごつミノをなぎ倒していくGlenelg。
逃げ回る主人から強引にDI/Aマミ連合軍のタゲを奪っていくGlenelg。
セリンの側で現れたLoDのタゲを奪って、画面ぎりぎりまで逃がしてくれるGlenelg。
ニブルでうろうろしてると現れたロリルリｘ２＋ブラッディｘ２をばっさり返り討ちにするGlenelg。
などなど・・・もう、その雄姿たるや（笑）

昨日の日記で書いた、「Damageモーションで横殴り判定」というアイディアなんですが・・・テストしてくださった方が。

Σ('-'っ)っ
そうか、オークがいたか。気がつかなんだ（＾＾；；

まあ、昨日も記載したように、他にも例外はありますし・・・やっぱり人の位置関係もあわせて判定しないとダメっぽい？
複合的に判定精度を上げるような使い道にできるかな？

2007/1/15 (月)

物事、単純化して本質を考えるといいことがいろいろあります。
例えば「可能な限りAI」での「Wizの攻撃魔法の範囲判定」。
言葉どおりの意味で「魔法領域全体の範囲の中心」を探そうとすると多分無理です。
が、発想の転換：「現在ダメージを受けている敵のいるあたりは、確実に魔法の範囲内」というのは事実。
⇒別に魔法全体の範囲がわからなくても、現在わかっている（全体よりは小さい範囲での）中心がわかれば、事実上代用が効く。
もちろん限定した分の差はあるわけですが、ポイントはこういう発想が重要だ、と言うこと。

以上、前ふり。

ホムの横殴り防止判定での課題の１つに「アクティブ敵vs火壁」の話があります。
このケースでは、通常の横殴りチェックでの判断材料であるGetV(V_TARGET)の値が・・・

敵のGetV(V_TARGET)を見ても、敵はまだ魔法使いに接敵していないので、判らない
魔法使いのGetV(V_TARGET)を見ても、魔法使いは直接魔法を敵に打っていないので、判らない。

・・・という形になるので、役に立ちません。
結果、多くのAIでは「敵・ホムケミ・第三者との位置関係（距離and/or方向）」を用いて間接的に回避しているはず。
Glenelgでも、現状は距離以外での防止はしていません。

で、さっきふと気が付いたのですが。
もしかしてもっと単純に「フリーの敵のはずなのに、ダメージモーションが出た敵は、除外」っていう手があるんじゃないか？

もちろんこれは非常に簡略化している話なので、「味方の火壁」とか「ケミ自身の火炎瓶やイクラ類」はどーすんだっていう課題もあるにはあるのですが、なんか考えてみる価値はありそうかな、と。

以上、メモ的に。

2007/1/14 (日)

「適当」と「適切」とは、非常に大きな論理的な意味差があります。

「適当」は「それなりに・いいかげんに・なげやりに」。
「適切」は「状況・目的などにぴったり当てはまること」。
特に前者は後者の意味をもって使うこともできるので、まさに「適切に」使い分けないと誤解の元です。

そして何かを「適切に」やっているのか「適当に」やっているのかは、外からは非常に見づらいことです。
たとえどんなに「適切に」やっていたとしても、それを相手が理解できるように見せないと、「適当に」やっていると見えてしまうケースは確実にあります。
それは自分の責任で、相手に文句をいうのはお門違いです。
（ここで「読解力/理解力のない相手の問題」と考えると、自分が成長できないので。）

友瀬の今日の日記の一番最初の「誤判定してもいいんじゃない？」、２つ目の「（ある程度率が低ければ）判断ミスしてもいいや」という書き方についても、これに関連した記載が舌足らずで「適当」なのが、問題ですね。
「適切」に言うならば、「ある程度率が低い」ということも、「判断ミスしてもいいや」というのも、もちろん「適切な」検討があることが前提です。
当たり前ですね。

で、上記に矛盾するようですが、友瀬は「適当な」ことをやっちゃいけないなんて思ってません。
「適当な」ものでもいいんです。
もちろん「まったく動かないようないいかげんな」ものではアレですが、「それなりに作りこんで、細かいところが未完了」のレベルなら。
そしてその上で、単にそれを使う人に「これは適当だよ」と伝わっていればいい、と思っています。
「適当なもの」には、人は適当なレベルのことしか期待しませんから。逆にいうと、問題になるのは「適当なもの」を「適切なもの」だと思って使ってしまうとき。
そういうことです。

・・・まあ、友瀬も１００％できてるとはいいませんが（＾＾；
Glenelgの氷割りモードは、あきらかに「適当な」もので、それを言ったのはリリースしてから数日後ですし（＾＾；；；

いいかげん自分でも見苦しいので、本件はこのあたりで。

以下「ふと気が付いたんですが」に書いたところで、可能な限りの人から突っ込みがあったので、追記。

まず読んでくださる皆さんの誤解がないように：下記「ふと気が付いたんですが」以下の部分は、友瀬が「感じた」ことであって、可能な限りAIが「絶対そういうポリシーで作られている」と言っているわけではないです。
で、つっこみの要点はまさにここの部分で、

実際にバグとも言えるような、誤判定を容認するいい加減な考え方でＡＩを作っているわけではありません
（以上「Glenelgさんに返信」から引用）

というところだと思います。
確かにそうですね。これは完全に友瀬の書き方不良です。
大変失礼しました。

机上ではわからない部分って多いわけで先ずは作ってみる。
それで実用上問題があるなら消せばいい。
（以上「Glenelgさんに返信」から引用）

この考え方で「お試し版」公開されているものが、割と「完成した」って感じで公開しているように見えてました。
だから「誤検知しそうだけどいいや」なんだろうな、って思えてました。

友瀬が言いたかったのは、

100回の試行に対し誤判定が一回なら、ホムＡＩ程度の軽いお遊びソフトなら実用的とも言えるでしょう。
（以上「Glenelgさんに返信」から引用）

という感じの話。
「（ある程度率が低ければ）判断ミスしてもいいや」って結構アリかな、ってまじに思った。

というわけで、以下ちと微妙・アレな内容ですが、削除するのもかえって失礼なので。

ふと気が付いたんですが。

いろいろと野心的な機能を組み込んでいる可能な限りAI。
今までのAIでやっていない機能をさまざまに搭載しているこのAI、感心しながら見ています。
で、ですね。
なんでそんなにいろんなことをできるのかな？
・・・そう考えていて、根底となる方針の差に気が付きました。

一言で言ってしまうと、ですね。
「誤判定した場合、それをどう扱うか」という判断・ポリシーレベルの差、ではないかと。

どういうことかというと。
Glenelgでの方針は、「誤判定は常に問題⇒だからやらない」。
それに対して「可能な限りAI」では「誤判定してもいいケースもあるんじゃない？」。
そういう差があるように感じました。

友瀬は「適切な情報がない（適切な判断ができない）モノは対処しない」という方針で設計しているが故に、他のAIでやっていてもやらない機能も多いです。
が、現実問題として、人間だって操作ミス・判断ミスはするのですから、AIがミスしたっていいじゃないか、という考え方はアリだと思います。
ミスをしたら、手動操作でリカバリーすればいいわけですから。
それによってより便利な機能が作れるのなら、トレードオフする価値は十分あるでしょう。

このあたりは完全にポリシーの差だと思うので、どっちがいい、というような比較をするようなものではありません。
ただまあ、そういう意識を持ってAIは使うべき、でしょうね。

2007/1/13 (土)

氷割りモード、やっぱり需要あるのかな？
微妙につっこみが入ってきています（＾＾；

SG割りについてですが、なんらかの手動操作を入れないと難しい気がします。で、ALT+クリックでホムを動かした後の待機時間中（あるいは別途指定時間）に周囲指定セル内に指定職（WIZ・HiWIZ）をターゲットかつ移動していない敵がいたら攻撃するというモードを作るってのはどうでしょうか？

いろいろ細かい指摘もいただきました：ありがとうございます。
ご指摘いただいた内容は、こちらもおおむね思い当たっている内容なので・・・以下詳細。

確かに、現状の友瀬の判断も「SGモードへ自動的な移行は無理、なんらかの手動操作が必須」という感じです。
すでに日記で記載済みのように「とどめモードor時間稼ぎモード」の区別は自動判断はリスクが高すぎに思ったので、v0.46ですでに手動での起動にしています。
ですが、v0.46の方式ではまだちょっと情報不足だったので、その点を見直し実施。それを埋め込んだ改善版はすでに作成済みです。
ただ、キャラ構成的に友瀬1人では試せなくてはまってます：SG持ちWizと、そのSGで即死しない敵がいるマップで戦えるホムケミがいないと試せないのですが、友瀬はWizとバニルケミが同じアカウントなのです（＾＾；；

参考までに具体的な内容を言いますと・・・先日の日記にも書いたように「凍結していない敵はSGの範囲内に引き込む」動作が必要なのですが、その「SGの範囲を自動判断」することができないのが、最大の問題。
そこで、現状試作したものではGlenelgのコマンドシフト機能を使って「２段コマンドシフト＋移動操作した場合、その移動先指定点をSGの中心点とみなす」ような方法にしています。
つまり、味方WizがSGを詠唱開始したら、「左下エリアをALT+SHIFT+右クリック」「左下エリアをALT+SHIFT+右クリック」「SG中心点をALT右クリック」・・・という感じ。

で、これを行うと以後６秒の間・・・

最優先ターゲットとして、「味方と戦闘中でかつSTAND状態」の敵を探す（これはSGの範囲とは関係なく索敵）。
- もしホムがバニルでかつその敵にすでに初撃スキルを使っていたら、それはリセット。
  移動時間が惜しいので、初撃スキルが使える状況なら即スキルで（遠距離から）割るため。
- もし共闘モードかつすでにその敵を攻撃済みだったら、それもリセット。
次善ターゲットとして「SG中心から6セル以内かつ味方と戦闘中」の敵を探す。
どちらもいない場合、SG中心点に向けて移動

・・・というような動作を作っています。

・・・どうしようかな。
テストするのが厳しそうだから、ベータ版で出しちゃおうかな。
・・・ちょっと考えます。

2007/1/11 (木)

拍手的な。でコメントもらった分の返信。

PTメンバー大量登録での「登録結果のフィードバックが判りづらい」事への対応策、というかネタ。誰が登録できたのかもわからないのが問題なら、登録コマンド直後に新規登録されたキャラをホムがタッチして回れば視覚的に分かるのでは？

ええと、せっかくご提案いただいたのですが・・・こういう「ホムの移動によるフィードバック」は今のところ、Glenelgの基本方針として避けているものです。
確かに他のAIでは（友達登録を含めて）さまざまな操作結果をホムの移動で表現しているものが多いです。
が、Glenelgでは、操作に対する結果は「状態表示窓に表示」することを原則。移動によるフィードバックはそのまま攻撃へ直結するケースのみ、としています。

理由としては、大きく２つ。

ホムの自律移動にあんまりさまざまな意味を持たせたくないため。
移動できないような状態でのフィードバックに困る・誤解の余地があるため。

必要なら具体的な例を挙げますが、「移動不可セル」「他PC」「操作前後の各キャラ同士の位置関係」あたりが絡んで望んだとおりの移動は行えない可能性があり、（その動作を見たユーザーの）誤認識の原因となります。
また戦闘中に「直接戦闘とは関係ない機動」をされても困るでしょう。

もちろん、「移動方式はNG、状況表示窓がベスト」なんてことはいいません。
確かに移動不能セルがないような状況では移動方式はスマートですし、現実問題として文字フィードバック方式では今回の範囲登録がうまく表現しづらいのですし。ただ、すでに「文字方式基本」としてしまっているGlenelgでは、更に移動方式までハイブリッド使用するのはちょっとどうかな、という感じです。

まあ・・・もし要望が多ければ、考えます。
いずれにしても、そろそろダンス系のネタを考えようかと思っているところでもあるので。

2007/1/10 (水)

可能な限りAIの人が新しく考えていることに、「マップごとに敵の優先度を記憶する」というものがあるようです。
正直、友瀬&Glenelgは地図関連判定については一家言あるので（笑）コメント。

実は同じようなことは、考えたことがあります。
似たような敵構成だけど微妙に優先度・スキル率を変えたほうがよさそうな「カタコンベ」と「監獄１F」でテストしていたときに、ちょっと悩んだ内容です。
が、結局没にしてしまいました。

理由はいくつかありますが、一番大きかったのは「手動で十分じゃん」というところ。
Glenelgの場合、敵ごと設定はRO画面から数タッチだけなので、気持ち悪かったらその場で修整すれば十分だな、って感じでした。

まあ、うちのホム自体のレベルが上がっていて、そこまで細かい設定もいらないような状況だった、というのも関係があるかもしれません。

Ver0.46で対応した氷割りモードですが、実はかなりやっつけ仕様なのは自覚しています。
たぶん現状動作では、確かに凍結敵を狙って攻撃してはくれますが、その後の動作はあんまり美しくないと思います：本当は攻撃したら「SGの範囲内に引き込む」ような動きをしないとならないんですよね。

まあもともと一切できなかった機能ですから、ちょっとしたおまけと思ってください。
改善案はちょこちょこありますが、手を打つ暇が・・・

氷割り関連で調べた話で、AI作者にとって意外＆困るはずの仕様について補足。

ある敵が誰を攻撃しているのかを取得する手法として当たり前に使われている「GetV(V_TARGET, <敵ID>」というもの。
これ、凍結前後でどうなっているかというのを調べると、ある意味妥当な、ある意味困った状況になっています。
実際に観測した際の情報を列挙すると、こうなってます。

実施した手順: ウィズがノンアクティブの敵（アンバーナイト）を一発殴ってタゲを取ったあと、SGでそれを巻き込み凍結。
その後放置でそれが自然解凍。

このようにしたときのGetVの状況を見ると、以下のようになっていました。

step	行動	GetV(V_TARGET,<敵ID>
step 0	初期状態	0
step 1	Wiz、殴ってタゲ取り	(この時点ではまだ）0
step 2	敵、Wizに反撃攻撃開始	WizのID
step 3	SG詠唱・発動→敵凍結中	WizのID
step 4	放置→自然解凍敵は非アクティブに。	WizのID

ここで気をつけて欲しいことは、step 4のGetV値とその時点でのタゲ状況。
自然解凍するとその敵は（もともと非アクティブの敵なので）PCたちへの攻撃を「行いません」。
にもかかわらず、その敵はホムからみると「Wizを狙っている」ように見えます。

厄介なのは、ここでの敵が例えばライドワードのようなアクティブ＆比較的すぐ自然解凍してしまう敵だった場合。
そういう敵は自然解凍すると即PCに向かって移動＆攻撃を開始しますが、その際に向かう敵は「GetVで取得した値と同じになる保証がありません」。
別の言い方で・・・実際に起こりうる例を挙げると。
自然解凍したライドワードが、たまたま近くにいた別パーティの騎士に向かって移動開始。
でも、GetVで見た場合そのライドワードは「こちらのパーティの誰か」を狙っているので、ホムは何の疑いも無くそれを攻撃する可能性があります・・・そうですね、タゲを強引に奪うように見えてしまいます。
まあ、SG凍結は相手も見ているでしょうから、普通の人なら「きにすんな～」ってとこでしょうが・・・ね。

なかなか面倒ですね。

2007/1/5 (金)

とりあえず、だ。

なにごとも「100かゼロか」でしか見れない、っていうのは、よくない。

「APPを禁止する権限が、AI作者にあるか？」

友瀬的な答えは、こうです。
「もしあるAIの作者が、自分のAIを改造してAPPを使われたくないと思うならば、
その旨の宣言や、それに付随したさまざまな手法を取る権利はある。」

創作をしたことのある人ならおそらくは誰でも、自分の創作物を勝手に変にされたくないと思うはず。
AIだって、それを主張する権利は、まちがいなく存在します。

もちろん、これはあくまで権利でしかありません。
これを認める以上、友瀬は以下のことも否定はしません。

AIによるAPPが公式に禁止されていない限り、 AI利用者が「個人利用の範疇で」上記「APP加工禁止宣言AI」を加工して使用する権利は、あると思います。
APP禁止AIおよびその作者が、他のAPPを認めているAIの使用を完全に禁止する権利は、ないと思います。

友瀬は「ゲームの常識的に」APPの使用は不適切と判断しており、 Glenelgでもそのポリシーに従って対応していません。
そしてあえて言うなら、Glenelgに対するそういう改造もしないでほしいと思っています。
ですが、ベタテキストで容易に改造可能なホムAIにそんなことを言っても仕方が無いので、「常識的な範疇はわかっているよね？」ということで何も言っていなかっただけです。

というわけで、0.46、正式リリースです。

駆け込みで、SG氷割り相当動作を「手動指定→一定時間で自動解除」のかたちでサポートしました。

これでこの冬の活動は一段落。

Glenelgの特徴である「命令操作」。
これのおかげでGlenelgには非常に多彩な機能・操作を追加できているのですが、反面、使いづらいのは否定しません。
特に、メニューが複数枚あるのが結構いやらしいところで、どこをどう操作したら何がおきるのか、それを記憶するのはかなり大変だと思います。

で、友瀬的にはこれは（あちこちのAIでもやっていますが）格闘ゲームコマンド的に覚えるといいと思ってます。
例えば、ver0.46からサポートした「SG氷割り」モードは、コマンド「５・７」（ケミの近く→ケミの左上方向という2回操作）、
範囲友達登録は「５・４・９、一拍置いて９・５」・・・という感じ。

まあ暗記しなくても、こういう早見表でも作るといいのかな、とは考えているところ。

2007/1/4 (木)

あ～・・・拍手的な。経由で気にしていた突込みがきたので、一応補足。
下記チャットコマンドでの設定の話。

＞少しだけ心配なのは、エミュ鯖コマンドと間違えられて晒されたりする人が居ないかと言うこと。

そうですね、これは実は結構な懸念です。
チャットコマンドの特性上、他の人にも見えちゃうんですよね。
一応、ギルドチャットやパーティチャットを使えばややローカルにはできますが、それだって他の人には見えるってことで。

で、どうせ見られるんなら、誤解がないように「普通のCUIコマンドでは使わない」ような書式にしちゃおう、と思いまして。
このあたりは指摘された方もおっしゃっていましたが、そういう理由で意識してコマンド類は全て全角文字にしたり、「！」を接頭文字にしたりしてます。
これをして、むしろ周囲には隠さず使用して、Glenelgの名前出しちゃってこのAIの機能なんだ～、と断言してもらったほうがいいかな、とか思ってます。

・・・思い切って、完全な自然言語にしちゃおうかな（笑）
「ホム！ポリンの優先度を5に！」みたいな。
判定処理を作るのがすご～く面倒そうなので、たぶんやらないですが（笑）

そろそろ休日も終わりなので、〆に入っていたりします。

優先度回り、実は現状だと「草狩りにホムが協力」する動作がちょっと不安定です。
見直しが必要ではあるのですが、比較的優先度は低そうなので後回し (もちろん次のリリースまでには手を打ちますが)。

とりあえず、この休み中にもう一点：チャットコマンド回りの機能強化をする予定です。
具体的には・・・

！優先度 ゾンビプリズナー 4
/savechat
！優先度 リビオ 7
/savechat
！同時攻撃 リビオ on
/savechat

・・・みたいなことをやろうと思ってます。

Glenelgの特徴のひとつの「敵種類ごとの学習は、ある敵を攻撃後に操作」というものは、判りやすくはあるのですが、反面「乱戦中には教えるのが難しい」という弱点があります。
ある意味リアルではあるのですが、多少使いづらいのも事実なので・・・こういうCUI入力をサポートしよう、というものです。

＃そこまでして設定ツールを作りたくないのか？という声が聞こえてきそうですが、RO上で全てをやっているところが重要なので（笑）

2007/1/3 (水)

というわけで、Glenelg Ver0.46beta をリリースします。

索敵関連の機能追加というか内部設計変更が大きいため、こちらとしても評価が完全に終わっていません。
また機能追加部分については、友瀬がもともとあまり必要と思っていなかったものであるため、使い勝手面でも怪しいのではないかと思います。

そういう面もひっくるめて、テスト用のベータ版としての公開です。
念のため、インストール前に前バージョンのファイル群をフォルダごとバックアップしておくことをお勧めします。
当然ヘルプファイルも未完成なので、Readmeファイルを参照してください。
おかしな点などあれば、指摘くださると助かります。

あ～。「敵の状態異常の判断基準としてSTAND状態採用」の件。
少し試してみたのですが、やはり強引な判定ではあるわけで、微妙に危険な要素がありました。

最大の懸念が、攻撃モーションが遅い敵。
これらの敵の場合、通常戦闘中でも普通にSTANDモーションを取っているタイミングがあるようです。
そのため、無条件に判定にいれたら「囲まれたらしょっちゅうタゲ変更」というような動作になってしまいました。
＃GDで動作確認してたら、なんか攻撃対象をがんがん変えてて、変だったさ（笑）

まあ、そういう遅い敵は低レベルなケースが多いと思うので、高レベル限定で考えるならそれでもいいのかもしれませんが・・・
少なくとも、キーピング対策で入れるっていうのはもう一工夫いりそうです。時間を計るか、なにか。

メモ兼用。

敵を追って画面外に行くことあり（Lさん）
- 現象は未確認。
  とりあえず、CHASE中でもボスケミとの距離チェックして、限界距離を飛び出さないような対応を追加。テスト済み。
ホムがケミの足元うろうろ（あろえさん）
- スタック避け処理にリミット追加。1回挑戦して回避できなかったらあきらめるように。テスト済み。
ホムスタック回避ネタ（ソフルさん）
- 一定時間戦闘後、まだ敵がいるようなら強制的にAWAY運動する動作実施。
  とりあえず広い場所ではうまく動作しているが、移動先がない狭い場所では苦しい。地図情報を使っていないとかなり無理がありそう。
  というわけで、標準では未使用・オプションで設定に。
優先度ゼロ＋ボス共闘（セッジさん）
- 一応組み込み済み。
  ただし、優先度関連を大きく練り直したので、全般的なテストに時間かかりそう。
PTメンバー大量登録（風鏡さん）
- 検討中。まだやるべきか悩んでます。
  何度も書きますが、最大の課題は「登録結果のフィードバックが判りづらい」ことです。
  誰が登録できたのかもわからないのが、果たして使いやすいかどうか。
  とりあえず、それを無視した実装をしてみます。

年末に話題にしていた、氷割り関連。
『もしかして単純に「戦闘中で、今まで明らかにこちらと戦闘していた敵がSTAND状態になったら」、それは無条件に攻撃していいんじゃないか？』
・・・なんて考えてたのですが、よくよく考えるとそれじゃあまずいことに思い当たった。
これもちょっと前に掲示板に記載のあった「睡眠中の敵を狙って起こすのは止めて」系。
睡眠したのも「STAND状態」になるはずなので、狙って起こしてしまうので、だめじゃん。

さすがにWiz呪文で睡眠にさせる手はないので、ホムに自動的にSG氷割り動作させようとするなら、やっぱり「Wizが呪文を使った」監視をしないとだめっぽい。
・・・どっちにしても「殲滅SG」と「時間稼ぎSG」の判断をホムにさせるのはやっかいそうだし、うちは対応するとしても「SGモード開始は手動入力」にしようかな。
誤検知するよりはマシなような気がする。

繰り返しになりますが、あくまで「ホムが得られる情報が限られている」というのが決定的な問題点。
「敵がSTANDになった」で判定している以上、例えば「WizがHD、他の前列が睡眠マグナム」なんて状況になれば、ホムは「睡眠した敵を氷結したと勘違い」してしまう。
「敵が氷結」「敵が睡眠」といった情報がとれれば、こんな余計な頭は使わないですむわけで。
状態くらい、取得したいねぇ。

2007/1/2 (火)

整理続行。リクエストのあったのは、全部で以下のものかな。

敵を追って画面外に行くことあり（Lさん）
ホムがケミの足元うろうろ（あろえさん）
ホムスタック回避ネタ（ソフルさん）
優先度ゼロ＋ボス共闘（セッジさん）
PTメンバー大量登録（風鏡さん）

酔っ払い頭を回しつつ、ちまちま手を打ち始めました。
とりあえず、優先度ゼロと画面外への追跡についてはテスト中。

のこりはまだ設計中。

ええと、では整理しよう。
自律索敵における、優先度にかかわる要素。

「より多くの敵に囲まれている」味方を助ける。
ユーザーが指定してした「敵種別ごと優先度」の高いものから。
「ボスと同時攻撃」指定されている敵で、ボスが殴っている敵は、更に高い優先度。
この場合、無視指定してても攻撃。

あ～・・・ってことはこんな順番かな？

ボスと同時攻撃指定＆ボスが攻撃している。
種別優先度7以上で、味方を攻撃している敵。
1. 複数いる場合、より近くにいる敵。
より多くの敵に囲まれている味方の救助的攻撃。
1. 複数いる場合、より種別優先度の高い敵。
2. 複数いる場合、より近くにいる敵。
味方が攻撃を受けていない場合、アクティブ索敵。フリーの敵。
1. ボスが攻撃している敵。
2. 複数いる場合、より種別優先度の高い敵。
3. 複数いる場合、より近くにいる敵。

で、「手加減モード」は、上記のいずれにも反映される。
つまり、手加減モードではどんな自律索敵対象でも、一定時間攻撃したら無視する。

優先度ゼロは、自律索敵においてはその敵を完全に無視。
例外は「ボスと同時攻撃指定」の場合のみ。

上記4-ⅰは「ボスと同時攻撃」で解消すべきに見えるが、そうではない：これは草などを狩るときを考えるとあるべき内容。
普通の敵はボスが殴る→反撃開始→2や3のグループで処理になるが、草は反撃してこない。かといって「ボスと同時攻撃」指定してしまうと、戦闘中に間違って草を叩いた場合に痛い目にあう。

<<2007-022006-12>>

▼過去ログ

2023	Log:2023-12	Log:2023-11	Log:2023-10	Log:2023-09	Log:2023-08	Log:2023-07
2023	Log:2023-06	Log:2023-05	Log:2023-04	Log:2023-03	Log:2023-02	Log:2023-01
2022	Log:2022-12	Log:2022-11	Log:2022-10	Log:2022-09	Log:2022-08	Log:2022-07
2022	Log:2022-06	Log:2022-05	Log:2022-04	Log:2022-03	Log:2022-02	Log:2022-01
2021	Log:2021-12	Log:2021-11	Log:2021-10	Log:2021-09	Log:2021-08	Log:2021-07
2021	Log:2021-06	Log:2021-05	Log:2021-04	Log:2021-03	Log:2021-02	Log:2021-01
2020	Log:2020-12	Log:2020-11	Log:2020-10	Log:2020-09	Log:2020-08	Log:2020-07
2020	Log:2020-06	Log:2020-05	Log:2020-04	Log:2020-03	Log:2020-02	Log:2020-01
2019	Log:2019-12	Log:2019-11	Log:2019-10	Log:2019-09	Log:2019-08	Log:2019-07
2019	Log:2019-06	Log:2019-05	Log:2019-04	Log:2019-03	Log:2019-02	Log:2019-01
2018	Log:2018-12	Log:2018-11	Log:2018-10	Log:2018-09	Log:2018-08	Log:2018-07
2018	Log:2018-06	Log:2018-05	Log:2018-04	Log:2018-03	Log:2018-02	Log:2018-01
2017	Log:2017-12	Log:2017-11	Log:2017-10	Log:2017-09	Log:2017-08	Log:2017-07
2017	Log:2017-06	Log:2017-05	Log:2017-04	Log:2017-03	Log:2017-02	Log:2017-01
2016	Log:2016-12	Log:2016-11	Log:2016-10	Log:2016-09	Log:2016-08	Log:2016-07
2016	Log:2016-06	Log:2016-05	Log:2016-04	Log:2016-03	Log:2016-02	Log:2016-01
2015	Log:2015-12	Log:2015-11	Log:2015-10	Log:2015-09	Log:2015-08	Log:2015-07
2015	Log:2015-06	Log:2015-05	Log:2015-04	Log:2015-03	Log:2015-02	Log:2015-01
2014	Log:2014-12	Log:2014-11	Log:2014-10	Log:2014-09	Log:2014-08	Log:2014-07
2014	Log:2014-06	Log:2014-05	Log:2014-04	Log:2014-03	Log:2014-02	Log:2014-01
2013	Log:2013-12	Log:2013-11	Log:2013-10	Log:2013-09	Log:2013-08	Log:2013-07
2013	Log:2013-06	Log:2013-05	Log:2013-04	Log:2013-03	Log:2013-02	Log:2013-01
2012	Log:2012-12	Log:2012-11	Log:2012-10	Log:2012-09	Log:2012-08	Log:2012-07
2012	Log:2012-06	Log:2012-05	Log:2012-04	Log:2012-03	Log:2012-02	Log:2012-01
2011	Log:2011-12	Log:2011-11	Log:2011-10	Log:2011-09	Log:2011-08	Log:2011-07
2011	Log:2011-06	Log:2011-05	Log:2011-04	Log:2011-03	Log:2011-02	Log:2011-01
2010	Log:2010-12	Log:2010-11	Log:2010-10	Log:2010-09	Log:2010-08	Log:2010-07
2010	Log:2010-06	Log:2010-05	Log:2010-04	Log:2010-03	Log:2010-02	Log:2010-01
2009	Log:2009-12	Log:2009-11	Log:2009-10	Log:2009-09	Log:2009-08	Log:2009-07
2009	Log:2009-06	Log:2009-05	Log:2009-04	Log:2009-03	Log:2009-02	Log:2009-01
2008	Log:2008-12	Log:2008-11	Log:2008-10	Log:2008-09	Log:2008-08	Log:2008-07
2008	Log:2008-06	Log:2008-05	Log:2008-04	Log:2008-03	Log:2008-02	Log:2008-01
2007	Log:2007-12	Log:2007-11	Log:2007-10	Log:2007-09	Log:2007-08	Log:2007-07
2007	Log:2007-06	Log:2007-05	Log:2007-04	Log:2007-03	Log:2007-02	Log:2007-01
2006	Log:2006-12	Log:2006-11	Log:2006-10	Log:2006-09	Log:2006-08	Log:2006-07
2006	Log:2006-06	Log:2006-05	Log:2006-04	Log:2006-03	Log:2006-02	Log:2006-01
2005	Log:2005-12	Log:2005-11	Log:2005-10	Log:2005-09	Log:2005-08	Log:2005-07
2005	Log:2005-06	Log:2005-05	Log:2005-04	Log:2005-03	Log:2005-02	Log:2005-01