========================================================================
プロトタイプ仕様書：50人同時移動テスト (Prototype Spec: Movement Test)
========================================================================


1. プロトタイプ概要 (Overview)
------------------------------------------------------------------------

1-0. 目的
    50人のプレイヤーが同じフィールド上で遅延なく移動できる通信基盤を検証する．
    衝突判定，塗り処理，ゲーム進行管理などの付随要素は実装せず，純粋な「移動同期」と「負荷検証」にフォーカスする．

1-1. 検証範囲
    ・マップ: 100×100マスのグリッドマップ
    ・人数: 最大50クライアント同時接続
    ・動作: 360度移動，カメラ追従，他者位置の同期表示


2. クライアント実装仕様 (Client Implementation)
------------------------------------------------------------------------

2-0. 目的
    入力処理，移動計算，および描画の基本ロジックを定義する．

2-1. 入力・操作系
    ■ ジョイスティック操作
    ・左側エリア: 画面左半分をタッチ可能な移動ジョイスティック領域とする．
    ・入力形式: 360°全方位入力．
    ・ベクトル正規化:
        - 入力ベクトルの長さが1.0を超える場合，1.0に正規化する．
        - これにより，斜め移動時の意図しない加速を防止する．

    ■ 誤操作防止 (UX Protection)
    ・スクリーンロック:
        - ゲーム画面に対するスクロール，拡大縮小（ピンチ操作）を無効化する．
    ・エッジデッドゾーン:
        - 画面左右の端（10px〜）を入力無効領域とし，OSのジェスチャー機能暴発を防ぐ．

2-2. 移動・演算ロジック
    ■ キャラクター仕様
    ・サイズ: 0.8マス×0.8マス
    ・移動速度: 秒速4〜5マス

    ■ 時間管理 (Time Management)
    ・DeltaTime対応:
        - 毎フレームの移動量計算に「前フレームからの経過時間 (DeltaTime)」を乗算する．
        - 計算式: `Position += Velocity * Speed * DeltaTime`
        - 目的: 端末のフレームレート（30fps/60fps/120fps）に依存せず，移動速度を一定に保つ．

    ■ 座標管理
    ・内部座標（計算・通信用）:
        - Float（浮動小数点）で管理し，滑らかな移動を実現する．
    ・グリッド座標（表示目安）:
        - 内部座標の小数点以下を切り捨て（Floor）た値を現在のマスとする．

2-3. カメラシステム (Camera System)
    ■ カメラ追従 (Camera Follow)
    ・挙動:
        - 常に「自キャラクター」が画面の中央に配置されるよう，カメラ座標を毎フレーム更新する．
        - マップ端に到達した場合のクランプ（固定）処理は，本プロトタイプでは実装不要とする（黒背景が見えても良い）．


3. 通信アーキテクチャ (Network Architecture)
------------------------------------------------------------------------

3-0. 目的
    50人の座標をリアルタイムに同期するためのデータ構造と通信フローを定義する．

3-1. 通信フローと役割分担
    | カテゴリ | クライアント (Client) | サーバー (Server) |
    | :--- | :--- | :--- |
    | **自キャラ** | **予測 (Prediction)**: 入力を即時反映し座標を更新・送信． | **中継 (Relay)**: 受信座標を正とし，他者へブロードキャスト． |
    | **他キャラ** | **補間 (Interpolation)**: 受信した過去の座標間を滑らかに補間移動． | **間引き (AoI)**: 距離に応じ送信情報を圧縮・除外． |

3-2. サーバー更新ループ (Server Loop)
    ■ ティックレート (Tick Rate)
    ・頻度: 20Hz（50ms間隔）
    ・処理内容:
        1. 受信バッファ内の全クライアントからの入力を取り出す．
        2. AoI（関心領域）判定を行い，各クライアントに必要なデータをフィルタリングする．
        3. 全クライアントへ「スナップショット」を一斉送信する．

    ■ スナップショット送信 (Snapshot)
    ・送信データ:
        - 視界範囲内にいる全キャラクターの ID，座標，向き．
        - サーバータイムスタンプ（補間計算用）．

3-3. データ構造・最適化
    ■ パケット設計
    ・形式: バイナリパケット（ArrayBuffer等）を採用し，JSON等のテキスト形式は使用しない．

    ■ 座標の量子化 (Quantization)
    ・目的: 通信帯域の削減．
    ・手法:
        - Float座標（0.0〜100.0）を，Unsigned Short（0〜65535）の整数値に変換して送信する．
        - 受信側で再度Floatに戻して使用する．

    ■ 送信データ (Input Data)
    クライアントからサーバーへ毎フレーム（または間引き）送信するデータ．
    ・現在座標 (Position): 物理演算（DeltaTime適用）後の確定座標 (x, y)．
    ・移動ベクトル (Velocity): 補間予測用の補助データ．
    ・角度 (Rotation): キャラクターの向き．

    ■ エリア別同期 (AoI)
    ・ロジック:
        - 各プレイヤーを中心とした一定範囲（例: 画面サイズの1.5倍）外にいる他プレイヤーの座標データは送信しない．
        - これにより，50人全員が動いていても，各端末が受け取るデータ量を視界内のみに限定する．