MM2 of The Locust は、2026 年 8 月 27 日時点で公式 Roblox ページに PRE-ALPHA と表示されています。制作者はバグへの注意を出し、次回アップデートでゲーム改善、今後のマップ、新しい装備パワーを予定しています。番号、公開時刻、アイテム一覧、マップ名、詳細なパッチノートは示されていないため、ここでは公式の予告とライブ検証が必要な変化を分けます。
最新の確認済み状況
2026-08-27 - 公式説明と PRE-ALPHA を確認
種類: Official status
公式リストは MM2 of The Locust を PRE-ALPHA とし、バグへの注意、次回のゲーム改善、今後のマップ、新しい装備パワーを示します。公開日時や完全な変更一覧はありません。
- 確認日は PRE-ALPHA のままです。
- 今後のマップは予告されていますが、名前と最終数は不明です。
- 新しい装備パワーは予告されていますが、名前、値、操作は不明です。
- 一般的な改善は予告されていますが、バージョン番号と変更表はありません。
情報源: Roblox の公式 MM2 of The Locust
公式の予告が意味すること
「ゲーム改善」は広い表現です。安定性、UI、マッチング、ラウンド進行、マップ、操作、バランスの可能性はありますが、ライブクライアントや制作者の告知が確認するまでは個別の変更と書きません。1 サーバーでバグが消えても、別の現行サーバーで再現を確認します。
「今後のマップ」は現在の選択が完成形でないことを示します。追加数、既存マップの置換、投票の変更は分かりません。新しい投票パネルは手掛かりであり、候補が読み込まれてからプレイ可能なマップとして確認します。
「新しい装備パワー」は装備に関わる変更の予定を示しますが、実装は不明です。新アイテム、既存アイテムの行動、役割専用パワー、UI の改訂かもしれません。ラベル、カード、クールダウン、効果、使用者を現在の画面で確認してください。
サーバーが変わったときの確認
ロビーで公式ページの更新時刻を記録し、新しい公開サーバーに入り、UI が完全に読み込まれるまで待ちます。マップ投票、役割表示、装備パネル、設定、告知バナーを確認します。ボタンが現れたらラベルを読み、結果を記録します。
サバイバーラウンドでは目標プロンプト、鍵のラベル、アイテム位置、操作距離、脱落後の選択、脱出トリガーを比較します。Locust ラウンドでは通常攻撃、特殊行動、ボタン、対象反応、回復を比較します。アニメーションやキーだけの変更が効果の変更とは限りません。
変更前後の記録
executor、ESP、改造移動、テレポート、隠しプロパティを使って更新を証明しないでください。通常プレイヤーが再現できない状態になります。
PRE-ALPHA のバグか意図的変更か
意図的変更なら、新しいサーバー、通常操作のプレイヤーで繰り返し発生し、制作者の声明または一貫した新 UI と合います。1 人だけに見える、UI の一部が消える、ラグ後に止まる、再参加で消える場合はバグの可能性が高くなります。
繰り返せた行動は、制作者が意図を確認するまで Community observed と記録します。信頼できる観察を使いつつ、予告なく直る可能性を残せます。
マップ、装備、コードを再確認する
変更後はロビーの候補と実際に読み込まれた環境を比較します。公式名が表示されるまでは目印で仮の身元を付けます。鍵の場所、隠れ場所、秘密部屋の古いメモをそのまま固定しないでください。
装備では入手者、プロンプト、装備方法、行動、効果の表示を確認します。Locust の能力では通常行動と特殊行動を分け、モンスター操作で機種ごとに確認します。公式リストは有効な報酬コードや交換 UI を告知していません。追加された場合は コードでこの Place のボタン、文字列、結果、報酬を確認します。
エビデンスのラベル
Official は対象体験ページまたは明確に関連する制作者チャンネルの情報です。Community observed は公式説明にないものの現行プレイヤーが再現した行動です。Needs in-game testing は証拠不足、バージョン依存、機種依存、または安定したルールにするには狭すぎるものです。
新しいパッチノートを信じる前に Place ID、出典、Roblox の更新活動、再現可能な結果を確認します。通常のプレイは攻略から始め、サバイバルを使い、環境変更後はマップからルートを作り直します。
更新を確認する順番
最初に公式 Roblox ページで体験名、Place ID、PRE-ALPHA の注意、更新に関する説明を確認します。次に、ゲーム内のロビー、ラウンド画面、マップ、役割 HUD の変化を、変更前の記録と比べます。動画や投稿は補助的な証拠として読み、現在の画面で再現できない内容を新しい仕様だと断定しません。
更新を確認するときは、変更されたように見える項目を一つに絞ります。鍵の表示、マップの接続、モンスターの操作、Taser、復活、投票、コード入力の有無を同時に試すと、どの変更が原因か分からなくなります。端末、役割、マップ、ラウンド状態、確認時刻、表示された文言を残してください。
古い情報を扱う方法
古い手順を削除する前に、どのビルドで確認できなくなったかを書きます。以前の鍵の位置が変わった場合、固定座標を残して現在も有効に見せず、目印と検証日を更新します。操作ボタンが変わった場合は、別の端末の入力を補って書かず、自分の画面で見えた表示だけを採用します。
更新後のラウンド記録
更新後の最初のラウンドでは、勝利よりも観察を優先する検証手順を決めます。開始地点、最初の分岐、鍵の表示、視線を切れる場所、装備の反応、モンスターの移動、ラウンド終了時の画面を順番に記録します。変化が見つからなくても、確認できなかった項目を残すことで、次の更新時に比較できます。
確度の使い分け
公式ページや制作者の明確な告知は Official、現行プレイヤーが再現した行動は Community reported、証拠が不足しているものや端末依存のものは Needs in-game testing として分けます。確認日を添え、更新があるたびにこの区別を維持してください。
更新後に確認する項目
最初に公式 Roblox ページで体験名、Place ID、PRE-ALPHA の説明、更新に関する記載を確認します。次にゲーム内のロビー、ラウンド HUD、マップ、役割、ドア、装備、投票、復活、コード画面を見ます。画面に変化がないことも記録し、動画や投稿だけで変更を断定しません。
変更を試すときは、一度に一項目だけを選びます。鍵の表示と位置、モンスターの入力、Taser、復活、投票、マップの接続を同時に検証すると原因が分からなくなります。端末、役割、マップ、ラウンド状態、確認時刻、表示文言、結果を同じ順番で残します。
古い手順が使えなくなった場合は、以前の確認日と現在の結果を分けて書きます。固定の鍵順、座標、価格、射程、クールダウン、次のラウンドの保証は、現行の表示で確認できるまで Needs in-game testing です。公式告知、現行プレイヤーの報告、未確認の観察を混ぜずに更新してください。
変更点を比較する表
更新前後で、ロビーの表示、役割、HUD、マップの入口、鍵の表示、ドアの反応、装備、復活、投票、コード画面を順番に確認します。全部を一度に変えず、たとえば最初はボタン表示だけ、次にそのボタンの結果だけを調べます。端末、マップ、役割、ラウンド状態、確認日と表示文言を添えると、別の条件の結果を混ぜずに済みます。
古いガイドの経路が使えなくなった場合は、前回の確認日と現在の結果を分けます。以前の鍵の場所、固定順、操作キー、費用、射程、クールダウンを現在の仕様として残しません。公式告知が変わっていなくても、ゲーム内の表示が違うなら、その差を観察として記録します。
更新後の最初のラウンドは、勝利だけでなく再現可能な観察を一つ作る機会です。公式情報は Official、プレイヤーが現行環境で再現したものは Community reported、条件が足りないものは Needs in-game testing として整理してください。
更新をラウンドで確かめる
公式ページの説明を読んだら、ゲーム内のロビー、役割 HUD、マップ、鍵、ドア、装備、投票、復活、コード画面を同じ順番で確認します。変更を見つけるために一度に複数の行動を変えず、端末、マップ、役割、ラウンド状態、確認日を残します。
古い経路やボタンが使えなくなった場合は、以前の記録と現在の記録を分けます。価格、数量、射程、クールダウン、固定座標、次のラウンドの保証を、告知や動画だけから補いません。現行プレイヤーの観察は Community reported、公式の説明は Official、条件が不足するものは Needs in-game testing として整理します。
変更を見落とさない確認順
更新後は、公式ページの記載、ロビー、役割 HUD、マップ、鍵、ドア、装備、復活、投票、コード画面を順番に確認します。最初から複数の行動を変えず、表示、入力、結果を一つずつ記録します。端末、役割、マップ、ラウンド状態、確認日を残すと、サーバー差や入力ミスを変更と取り違えにくくなります。
古い経路やボタンが使えない場合は、以前の確認日と現在の観察を分けて書きます。固定の鍵順、座標、費用、射程、クールダウン、次のラウンドの保証を告知や動画から補いません。公式情報は Official、現行プレイヤーの再現は Community reported、条件が足りないものは Needs in-game testing として整理します。
確認後の共有
変更を見つけたら、何が表示され、どの操作を行い、何が変わったかを分けて書きます。公式告知だけで足りない部分は現行のゲーム内で確かめ、確認できない値や固定ルートを推測で補いません。端末、役割、マップ、確認日があれば、次の更新で比較できます。