Top/日記/2007-02-16

日記/2007-02-16

2007-02-16 (金) 19:51:40

件の「ゼロ移動キャンセル」関連。

新しい検証はなにも行えていないが、AIサイクルがずれる話絡みから言って、おそらくクライアント側だけでの論理的解釈は無理だろう。
また、どうもホムの種類やASPDなど、条件になりそうな項目が多すぎ、限られた範囲での情報収集でははっきりした結論にたどりつくのは難しそう。

そこで、逆に「どうすればいいか」を整理して、誰でも困らないように（カスタマイズできるように）しておけばいい。
現状の３つの機能（キャンセルしない/移動/ゼロ移動）について、関連情報ごとに整理するとこうなる。

	キャンセルなし	移動キャンセル	ゼロ移動キャンセル
通信系	○問題なし	×無駄パケット増	×無駄パケット増
攻撃速度	×激遅い	○加速 *1	○加速 *1
戦闘中回復	○回復する	×回復しない	○回復する

表内補足：　*1 ホムの種類などでどちらが良いかは不明

ここから考えて、こう実装しておけば誰の環境でもごまかしが聞くはず。

対応項目１：キャンセルするか否かのスイッチを１つ準備。
「無駄パケット出してもいいから高速化」or「遅くてもお行儀良く」のスイッチ。
対応項目２：回復不要時に移動キャンセルしていいか否か（and/orそのしきい値）。

これの組み合わせで、動作は固定できる。

		キャンセル許可
		する	しない
移動許可	する	ⅲ	ⅰ
	しない	ⅱ

一切キャンセル動作をしない。
遅いがお行儀がいい。
ゼロ移動キャンセルのみ。
消耗していなければ、移動キャンセル。
消耗していればゼロ移動キャンセルのみ。

可能な限りAI1.4hの時点では、モードB（ゼロ移動キャンセル）はモードC（移動キャンセル）よりも遅いという前提で、ホムの種類ごとにどう動くかを決めている。
だから、上記表でいうところのⅱよりはⅲのほうが「より高速になる」という前提で設計されている。
自動判断という視点ではこの方向は正しい：友瀬もそう実装しようと思っていたくらいですし。
だが昨日の調査の時点で、実はゼロ移動キャンセルのほうが速いケースというのが存在することがわかってきた：そしてそれが「どのホムだとどうなる」かがわかっていないところに大きな問題。
現状の友瀬の環境では、99レベル進化原種バニルは上記表内パターンⅲ、33レベル未進化原種リーフはパターンⅱでよさそう。
だが、99レベルの未進化リーフはパターンⅱでいいのか？、というのは友瀬にはわからない。

・・・ということで、Glenelgではこんな感じのカスタマイズ項目でも作ろうかと思います。
現状すでに「移動許可条件」はつけているので、あとは単純に「キャンセル行為を認めるか否か」を追加すればいいか。

自動判定については、当面は考慮なし。
ホムタイプだけに依存すると断言できる状況でもないし、そのための情報が有志で集まるのはかなり大変：亜種・進化をあわせて16種類＊ある程度のホムレベルでのサンプリングとしなければならない。
両方を試してみて平均戦闘時間を計って云々・・・という自動予測は、それこそその「測定」の間に不自由するし、誤判定でもしたら目もあてられないので。

拍手的な。対応。

初期化をiniファイルにしなくても、LUAでエラーチェックで引っかければ？†

できないことはないと思いますが、あまりに余計な労力に感じられるので、あまりやる気はないです。

単純な異常値入力だけなら、問題ありません。一番懸念するのは、全角文字列などを記載されたり、等号記載だけで改行してしまったりと、「そもそもAIとして動作しない」状態になされてしまうケース。
この状態でも「どのソースのどの行でエラーがでたら、どこがおかしい」というようなチェックルーチンを作れば確かに対処可能かもしれませんが、それにしても余計な改行をいれられたりすると厄介です。
完全な比較対象バックアップでも持ってやればできると思いますが、あまりに「ホムのAIとしては本筋外」のところだと思っています。
商用などでがっちりやらなければならないならともかく。

↑

移動キャンセルってバグ利用じゃないの？†

まず「バグとはなんぞや？」という話でいうと、移動キャンセルはバグではありません。
誤解がないようにいうと、移動キャンセルが仕様だともいいません。
本来「仕様」という言葉は

「～～となるように作っています。」
「意図はしていませんでしたが結果的に～～となってます。そしてそれで問題ないです。」

というような開発者の明確な意思表示の元に存在するものです。
そして「バグ」という言葉は、

「仕様は～～。ですから～～は仕様とは異なった動作です。」

というような開発者の明確な意思表示の元に存在するものです。

賢明な諸氏ならご理解いただけると思いますが、移動キャンセルについては「現時点では」開発元からの明確な意見はないので、「現時点では」仕様でもバグでもない、ただそうなっているものです。

とはいえ友瀬は、移動キャンセルは「結果的にできている」たぐいのもので、そしておそらくは「そして問題がある」ものだと思っています。
そういう意味で、友瀬はこの対応については、「限りなくバグ利用に近い行為ではある」と思っています。
だからこそ友瀬は、（Attack多重化も含めて）高速化はデフォルトではOffにしています。
利用する人は意図してお行儀を悪くしている、ということです。

念のために言っておきますが、友瀬は「テスト以外で」これらのオプションを有効にはしていません。
例えばAttack多重化などは、実装当初の1月くらいは使っていましたが、その後はずっとOffです。
移動キャンセルも、実装直後の現時点ではともかく、しばらくしたらたぶんOffにすると思います。

↑

同じバグ利用のSBR44連射対応はしなかったのに、なぜ移動キャンセルは対応するの？†

「同じバグ利用」であるかどうかには大いに疑問がありますが・・・ともあれ、確かにどちらも「できるとは書かれていないが、確かにできる」ものという視点では同じです。
これについては、完全に「友瀬の俺ルール」ではありますが、きちんとした理由があります。
おおざっぱにいうと

SBR44対応は「きちんと青信号が出る信号で、赤信号を渡っている」ようなもの。
移動キャンセルは「赤信号が出っ放しで青になってくれないので、仕方なく渡っている」ようなもの。

・・・という感じでしょうか。
どちらも赤信号を渡っているのですから、お勧めはできません。
ただ、後者は「友瀬が取り締まる立場なら」お目こぼしの余地がある、というだけです。
繰り返しますが、完全に「俺ルール」です。

友瀬はSBR44の外部仕様を見て、以下のように考えました。
「SBR44は、本来ある程度の好感度を消費するものと読める。
　だから好感度消費なしで連射できるのはおかしい。」
この状況で、使い手は「好感度が足りているときのみ（手動で）SBR44を使う」という、適切な操作は可能でした。
だからAIから積極的なSBR44は採用しませんでした。

移動キャンセルは、ASPDの外部仕様を見て、以下のように考えました。
「現状の攻撃速度は、明らかにASPDを（遅くなる方向で）守っていない。」
つまりこの状況は、「ホムが本来できるはずのことができていない」というものになっています。
そこで仕方なく、強引に「高速化」する手法を選べるようにしました。現状ではASPD以上の速度になってしまっている、というのも理解はしています。
が、残念ながらホムから「適切な速度に調節」という方法がないので、妥協しています。

繰り返しますが、あくまで「俺ルール」です。

↑

BOT対策が来た、って判断は早計では？†

ちと今更ですが、2/7の日記へのつっこみでした（＾＾；
一応、2/6に確かにBOT対策はなされていたようです。
でも、現時点でかなり突破されてしまっているようですね・・・残念。

TrackBack(0)

日記/2007-02-16

初期化をiniファイルにしなくても、LUAでエラーチェックで引っかければ？†

移動キャンセルってバグ利用じゃないの？†

同じバグ利用のSBR44連射対応はしなかったのに、なぜ移動キャンセルは対応するの？†

BOT対策が来た、って判断は早計では？†

検索

編集操作

ある名言。†

折りたたみ†

シェアする†

メニュー†

クイックリンク†

最新の20件

管理†