Smiler は確認済みの Loop [ALPHA] エンティティです。公式バッジ 2 つが範囲を示します。Too Many Smiles は 1 Day に 4 体以上の Smiler が現れること、Stop Smiling は Smiler を気絶させることを条件にします。公開バッジ文は、方法、タイミング、出現ルール、ダメージ、すべての状態が同じ反応をするかを明らかにしていません。
これらを目標として使い、最初に見た Smiler へ急ぐ理由にはしないでください。安全なルートを残し、合図を観察し、長いランを危険にさらす前にライブの操作を確認します。
公式に確認できる Smiler の事実
これらは出現率、固定場所、気絶アイテム、範囲、時間、無効化時間を証明しません。現在の Alpha で再現できる証拠が得られるまで空欄にします。
最初の観察を安全に組み立てる
Smiler だと思ったら、任意の loot や操作を止め、最も近い既知のランドマークを確認します。複数の未知の分岐を曲がらずに戻れる距離を残し、危険になる前に始まる視覚・音・画面の変化を記録します。
顔やモデルだけを見ないでください。部屋で何が起き、ミッションがどうなっていて、照明や画面が変わり、ほかのエンティティが活動していたかを記録すると、一般的な Day イベントと Smiler の合図を分けられます。
方法を推測せず気絶を試す
ライブの部屋にある Item や操作の名前・説明を読みます。中断、気絶、光、制御を明確に示す物があっても、既知の出口がある場所と失ってもよいランでのみ試します。移動停止、表示の変化、危険の終了、バッジの付与など明確な状態変化を見ます。
1 回成功しても、その条件で行動が働いたことしか分かりません。同じ Item、Day、距離、ソロ・協力条件で繰り返してから信頼できる対策と呼びます。バッジが付いて視覚的な変化が不明なら、バッジと行動だけを報告し、時間を捏造しません。
複数の Smiler への対応
Too Many Smiles は、1 Day に少なくとも 4 体が現れる可能性を示します。圧力が増えたら気絶バッジよりルートを優先します。呼びかけを共有できる程度に集まりつつ、別の選択肢がない狭い場所へ全員を詰めないでください。
見分けられるものだけを数えます。4 つの合図があっても、4 体が同時に活動している証拠やバッジ条件とは限りません。公式の目標はライブのバッジ付与で確認します。
ソロでの Smiler 判断
早めの撤退基準を決めます。エンティティを見ていて帰り道を失ったら観察をやめ、1 回に 1 つの行動を試し、Day を替える前に結果を書きます。位置を守る人も別画面を比べる人もいません。
気絶の可能性があるからと、未知の Item を使わないでください。まずライブ説明と使用後の状態を確認します。失敗しても、条件とルートを記録できていれば役立ちます。
協力プレイでの Smiler 判断
「Smiler、ランドマーク、方向、状態」と短く呼びます。1 人が観察またはテストし、別の人が戻るルートを守ります。気絶を試した後、各自が何を見たかとバッジを受けたかを比べます。
気絶が全員に反映される、全員にクレジットが付く、2 体目も安全だと決めつけないでください。直接テストが必要です。
Smiler でしやすい失敗
- 「気絶できる」を普遍的なアイテム手順にする。
- 1 本の動画で気絶時間を測る。
- 4 体が固定 Day に出ると考える。
- 目的やルートが不安定なのに Too Many Smiles を追う。
- ソロか協力かを忘れる。
- バッジ付与をダメージ、範囲、完全な挙動の証拠にする。
Smiler FAQ
Smiler をどう気絶させますか？
公式バッジは可能性を示しますが方法は示しません。現在の Item と操作のラベルを読み、安全に試し、明確な状態変化またはバッジ結果を求めます。
Smiler はどこに出ますか？
固定部屋や率を示す信頼できる公式公開情報はありません。Day が変わる可能性があるため、現在の合図とランドマークを使います。
複数の Smiler は同時に現れますか？
公式バッジは 1 Day に 4 体以上が現れる可能性を示しますが、同時か反復か、特定のトリガーかは定義していません。
次に何を読めばよいですか？
Entities Dex で他の名前のある脅威を確認し、Day Progression で遭遇を現在のラン状態と結び付けます。
証拠状況：Smiler の名前、気絶可能性、1 Day に 4 体以上という条件は公式情報です。合図、出現ルール、方法、時間、ダメージ、複数体の挙動はゲーム内テストが必要です。
Phase 5 追加確認
Smiler を初めて確認したら、顔やモデルを追いかける前に帰路を決めます。どの部屋で、どの Day で、Mission が何を求めていたかを記録し、照明、音、画面表示の変化を観察します。任意の拾得や別の操作を止めると、Smiler の合図と一般的な Day の変化を区別しやすくなります。
Stop Smiling は、Smiler がスタン状態になる結果を示しますが、使う Item、距離、時間、連続して効くかどうかは示しません。安全な出口を確認してから現在の表示を読み、一度に一つの行動だけを試してください。成功しても、その条件で働いたことしか証明しないため、同じ Day、距離、モードで再確認します。
Too Many Smiles は、一つの Day に四体以上が現れる可能性を示します。これは固定された Day や同時出現の時刻を意味しません。複数の合図が出たら、Badge のために狭い場所へ進むより、全員が戻れるルートと短いコールを保つことを優先します。
ソロでは観察を中断する基準を早めにし、協力プレイでは一人が見張り、別の人が状態を呼びます。全員に同じスタン表示や Badge クレジットが出ると決めず、各画面を後で比較してください。失敗した試行も、条件を残せば次の更新で検証できる資料になります。
Phase 5 追加ログ
このページの情報を実際のプレイで使ったときは、結論だけでなく条件も残してください。UTC の確認日、表示されていた Day、ソロか協力か、サーバーの状態、最初に見たランドマーク、直前の操作、画面に出た文章、最後の結果を同じ順番で書きます。条件が一つ欠けていると、別の Day や別の更新で起きた差を同じルールだと誤認しやすくなります。
一回の成功は、その条件で可能だったことを示すだけです。次の試行では、ルート、距離、Item、Mission、カメラ、人数、操作のうち一つだけを変え、何が同じで何が違ったかを比較します。複数の変数を同時に変えた記録は仮説として残し、確定した攻略手順のように書かないでください。UI が変わった場合は、古いスクリーンショットや動画より現在の表示を優先します。
結果が分からないときは、未確認のまま保存することも有用です。Badge が遅れて付く、Inventory や Coins の表示が戻る、Mission の文章が更新されない、エンティティの合図が一度だけ出る、といった事例では、もう一度同じ操作を繰り返す前に状態を記録します。危険な検証は長い進行を犠牲にせず、低リスクの短い試行へ分けてください。
共有する文章では、公式に書かれた条件、現在のゲーム内で見た事実、コミュニティが報告した可能性を見出しや注記で分けます。公式 API の ID や timestamp は体験の身元と確認のきっかけを示しますが、隠れた mechanic や将来の結果を保証しません。Alpha の変更後は同じページを読み直し、確認日を更新してから古い数値を残すか判断します。