MinecraftクライアントにおけるDevTestとは？?

MinecraftにおけるDevTestとは？

DevTestは、クライアントのモジュールリストに時折現れるものの、明確な機能説明がないことがあります。これはKillAuraの派生版や、巧妙に偽装されたエイムボットではありません。クライアント自体を構築する際に、開発者が進行中のコードを試すために使用する、いわば残骸のようなものです。ソフトウェアをリリースする開発者向けに書かれたため、DevTestは一貫した動作をしません。特定のビルドでの動作は、最後に触れた際に開発者がデバッグしていた内容に完全に依存し、バージョン間、あるいは同じバージョンの2つのビルド間でも変化することがあります。

ほとんどの場合、DevTestはモジュールリストにプレースホルダーとして存在し、何も行わないか、誰かがラベルを付けようとしなかった何らかの動作を行います。これは、QAを通過して残ってしまった「TODO: リリース前に削除」というコメントと同じようなものです。

DevTestの仕組み

DevTestは、プレイヤーに直接影響を与える固定された機能を持っていません。なぜなら、それがDevTestの目的ではなかったからです。開発者は、現在取り組んでいるものに合わせてモジュールを接続します。新しいレンダリングパス、パケットハンドラー、移動コード、あるいはクライアントをクラッシュさせずに何かが実行できることを確認するためのスクラッチスペースなどです.

それも、しばしばスレッドばれの状態でリリースされる理由の一つです。設定がない、説明が空欄、あるいは実際のモジュールが説明するべき場所にプレースホルダーテキストが置かれているといった具合です。リリースビルドで有効にしても、何も効果がないこともあります。また、開発者がリリース前に削除し忘れたテストコードを実行してしまう可能性もあります。

クライアント開発者は、このようなモジュールスロットを頼りにします。なぜなら、彼らがテストしているものの多くは、サンドボックスではなく、実際のサーバーに対してのみ正しく動作するからです。実行中のクライアント内部に高速なオン/オフスイッチがある方が、毎回個別のビルドを立ち上げるよりも便利です。クライアントがリリースされる際、スロットがリストに残っているのは、削除するのが手間がかかるから、あるいはチームが次の開発サイクルで再利用する予定だから、という場合もあります。

なぜ存在するのか

ほとんどのクライアント側の作業は、実際のサーバーに対して行われます。新しい移動モジュールやレンダーフックをテストするには、アンチチートチェックや実際のプレイヤーの挙動に対してどのように動作するかを確認する必要があります。単にコードをロードしてうまくいくことを期待するだけでは不十分です。DevTestは、そのための一つのスロットです。開発者は、現在構築中のものに接続し、クライアントを起動して、ライブサーバーに対してテストを行います。

ビルドがリリースされる際、DevTestは削除されるか、次回のテストサイクルのために残されたままになることがあります。削除して、来週再追加し、再設定するよりも、そのままにしておく方が速いためです。

使用しても安全か

ここに単一の答えはありません。DevTest は単一の機能や単一の動作ではなく、プレースホルダーだからです。ビルドで機能しない場合、切り替えても何も起こらず、他の未使用設定よりもリスクは高くありません。パケット操作や未完成の移動チートのようなものをテストするためにコードに接続されている場合、オンにすると、実際のサーバーのアンチチートに対してテストされなかった動作がトリガーされる可能性があります。なぜなら、実際の試合で実行されることを想定していなかったからです。

ラベルのない開発モジュールは予測不可能として扱うべきです。無害なデッドトグルであると仮定したり、秘密の機能であると仮定したりしないでください。それが何を参照しているかを知るまでは、どちらでもありません。

実際のクライアントが代わりにやること

完成したクライアントは、意味のある名前、実際の動作に一致する説明、そしてラベルどおりに動作する設定でモジュールを出荷します。機能が準備できていない場合は、ビルドに含めません。出荷する場合は、開発者がその動作に自信を持ち、文書化する意思があるからです。

よくある質問