日記/2007-02-16 のバックアップ(No.1)

お名前:

[[拍手的な。]]対応。

初期化を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対策はなされていたようです。
でも、現時点でかなり突破されてしまっているようですね・・・残念。