ドカン！お祈りメールクラッシャー

就活の「お祈りメール」やライブの落選メールでモヤっとした気持ちを、ゲームでスカッと発散するアプリです。

ターゲット

• 就活のお祈りメールをもらってモヤっとしている学生
• ライブの抽選に落選してモヤっとしている学生

利用環境

モバイルブラウザ

遊び方の流れ

1. タイトル画面
   • タイトルが表示される
   • モヤっとしたメールの文章を貼り付ける入力フォーム（アプリ連携ではなく直接コピペ）
   • 「スタート」「遊び方」などのボタン
   • 「スタート」を押すとゲーム画面に移動
2. ゲーム画面
   • 入力したメールの文字が1文字ずつブロックに描かれ、空中に浮いた棒の上に 壁のように積み上がっている
   • ポケモンGOのボール投げのように、球を投げつけて棒の上のブロックを落とす。 ブロック自体は壊れないが、棒から落とせばその文字は粉砕された扱いになる
   • 奥行き（3D演出）を出すかどうかは実装しながら判断
3. リザルト画面
   • スコアは出さない（「点数を競う遊び」ではないため）。代わりに、入力した メール本文を1文字ずつ表示し、粉砕できた文字とまだ棒の上に残っている （＝まだ靄が残っている）文字を見比べさせる
   • 全部粉砕できたときは専用の演出で達成感を出す

担当

• タイトル画面: @ちゃんぐー_川口雄矢
• ゲーム画面: @こうた_奥川広大, @いぬぽん（メンター）

画面遷移とメール本文の受け渡し

TITLE → 「スタート」 → MAIL_INPUT → 「ゲーム開始」 → GAME

• src/scenes/MailInputScene.js がメール本文入力画面。ブロックの生成は一切行わず、 入力文字列をトリムしたものを onStartGame(mailText) で渡すだけに徹している。
• 「ゲーム開始」ボタンが押せるのは、入力欄からフォーカスが外れている（blur済みの） ときだけ。入力中に押せてしまうと、スマホではソフトキーボードに隠れたボタンを 手探りで叩くことになり、日本語入力では変換途中の文字がそのまま渡ってしまうため、 「入力欄の外に出る＝入力を確定させる」操作を一度挟ませている。
• src/main.js の App.goTo() が onStartGame の戻り先として GameScene.setMailText(mailText) を呼んでから mount() する （ResultScene.setResult() と同じ「mount前にsetterで値を渡す」パターン）。
• GameScene._setupWall() が実際のブロック生成場所（空中の棒の上に積む）。 積む行は _buildRows() が返す「行（文字配列）の配列」に一本化してあり、 this.mailText が未設定（null）の場合（「遊び方」から直接ゲームへ進んだ 場合など）もランダムな文面を同じ手順で行分解する。つまり「1文字=1ブロック」の 経路は常に1本だけ。

改行・空白・折り返しの扱い

GameScene._splitIntoRows() が行の組み方を1箇所に集約している。

• メール本文中の改行はそのまま新しい行の区切りとして扱う（改行が入るたびに 壁の新しい行になる）。
• 改行のない長い行は自動で折り返す。折り返し幅（1行の最大文字数）は総文字数の 平方根に基づいて決めており、MAX_ROWS（現在6行）を超えて積み上がりそうな 文字数になったら、行数を増やさず折り返し幅（列数）だけを増やして横に広げる。
• 行内のスペース（半角/全角）はブロックにしても意味がないため取り除く （句読点はそのままブロックになる）。分割は絵文字などのサロゲートペアを 割らないよう Array.from() を使う。
• 全行を折り返し幅と同じ列数に揃え、文字が足りない行は右側を空白ブロック （文字なしのBlock）で埋めている。行ごとに実際の文字数で中央寄せすると、 短い行の上に長い行が乗ったときに支えのないオーバーハングができて自重で 崩れてしまうため、必ず全行同じ列数・左詰めで配置している。
• MAX_MAIL_BLOCKS（現在100文字。MailInputScene側のMAX_MAIL_LENGTHと 揃えてある）を超える入力は先頭から切り詰めている（空白ブロックの分は この上限に含めない）。
• 段は反転させて積む。行の並びは本文の先頭から順（row=0が最初の行）だが、 壁は下から積み上がるので、そのままだと最初の行が最下段になって上から下に 読むと逆順になってしまう。_spawnBlock() で高さを反転している。

空中の棒と粉砕判定（src/scenes/GameScene.js, src/game/Bar.js）

• メールブロックの壁は、床ではなく空中に浮いたBar（幅8m・高さ0.3m・ 奥行き1.2mの直方体、src/game/Bar.js）の上に積んである。棒はmass: 0の 完全固定ボディで、球が当たっても棒自体は動かない。棒が落ちる設計にすると、 乗っている壁が一撃で全部落ちて8球という球数設計が壊れるため。
• Blockにあった耐久値・破壊判定（HIT_DURABILITYなど）は撤去した。 ブロックは衝突では絶対に壊れず、棒の上面より1m下（CRUSH_FALL_Y）まで 落ちたら「粉砕された」扱いにしてfallingBlocksに移す。このゲームに スコアは無く、代わりにGameScene._markCrushed()がそのブロックの sourceIndex（元のメール本文での文字位置）をcrushedIndicesに記録する。 記録は1回きりで、その後はGameScene._resolveLandedBlocks()が回収するだけの 存在になる。爆弾が爆発したとき（_resolveBombs()）も同様に記録する。
• ステージには見た目の床が無く、落ちたブロックはそのまま落下し続ける。 物理ボディを無限に走らせないよう、画面には映らない高さ（FLOOR_Y = -20）に 当たり判定だけの床を敷き、そこに着いた時点でブロックを破棄している。 カメラ位置(0,9,28)・フォグ(35〜50)から計算すると、画面の一番下の視線が y=-20に届くのはカメラから59.7m先（フォグの上限50mより外）なので、 この床は画面のどこからも絶対に見えない。
• 棒の長さは固定値ではなく、乗せる壁の幅ぴったりに合わせている （GameScene._setupBar() が new Bar(..., this.wallWidth) を呼ぶ）。 短いと端のブロックが棒に乗らず開始直後に落ち、長いと端に何も乗っていない 余りが見えてしまう。文字数で壁の幅が変わるため、BAR_SIZE.x は既定値の 扱いになっている。
• カメラ距離は壁の実寸とアスペクト比から逆算している （GameScene._applyCameraFraming()）。縦画面のように横方向の視野が狭い ときは横幅基準の距離が、横長画面では高さ基準の距離が効く。画面回転時 （_onResize）にも引き直す。CAMERA_BASE_POSITION(0,9,28) / CAMERA_BASE_LOOK_AT(0,7,0) からは向きと最短距離だけを取り出しており、 24文字のときはこの最短距離が下限として効くので従来の見え方と変わらない。 影の範囲とフォグもカメラ距離に追従させている。
• LAUNCH_ORIGIN は壁からの距離（z=25m）なので、カメラを引いても球の届く 距離には影響しない。ただし AimController の仰角レンジは壁の高さを前提に 実測した値なので、MAX_ROWS を増やして壁を高くしたら測り直しが必要（下記）。

文字数と読みやすさのトレードオフ

文字数が増えると列が増え、壁が横に広がり、収めるためにカメラが下がる。 その結果ブロックの文字は小さくなる。iPhone 14（390×844）の縦画面での実測値：

文字数	列 × 行	壁の幅	カメラ距離	画面上の文字の高さ
24	5 × 5	8.0m	28.1m	20.3px
40	7 × 6	11.2m	33.8m	16.9px
60	10 × 6	16.0m	48.3m	11.8px
100	17 × 6	27.2m	82.1m	6.9px

上限いっぱいの100文字では文字がほぼ読めない。 読みやすさを優先するなら MAX_MAIL_BLOCKS を下げる（MailInputScene の MAX_MAIL_LENGTH も一緒に）。 20px を確保できるのは40文字弱まで。なお「文字数に応じてブロック自体を縮小する」 案は過去に試して、カメラを引いた分と相殺してかえって読みにくくなることを 実機確認済み。

狙い（src/game/AimController.js）

• 発射地点からブロックの壁までは25m離れており、仰角によって着弾高さが 大きく変わる。当初は「パワー・仰角ともに引き量の2乗で増やす」二次カーブ だったが、これだと速度と角度が両方増えるぶん着弾高さが引き量に対して 跳ね上がるように敏感になり、実測では当たる引き量の幅が0.10程度 （ドラッグ可動域の1割程度）しかなく、狙って当てるゲームとして成立しなかった。
• 現在はパワーの変化幅を85〜100%まで狭め、仰角を引き量に対して線形 （14度〜28度）に変えている。物理シミュレーションで実測した値で、 14度で壁の下端よりやや低く着弾し（素通り）、28度で壁の頂点よりやや 高く着弾する（頭上を越える）。この間（引き量にしておよそ0.3〜0.9、 可動域の6割）で壁のどこかに当たる計算になっており、狙いやすさが 大きく改善している。
• 壁の高さ・カメラ位置・発射地点のどれかを変えたら、この仰角レンジは 実測し直す必要がある（速度と角度が絡む放物線なので、単純な比例計算では ずれる。cannon-esで実際に撃って着弾高さを測るのが確実）。
• この14度〜28度は5行の壁（頂点 y≒10.9）で実測した値。現在は MAX_ROWS = 6 なので文字数によっては6行（頂点 y≒11.9）になり、壁が約1m高くなる。28度は もともと壁の頂点よりやや高く着弾する設定なので届く見込みだが、 実機で最上段に当たるか確認したい。

爆弾ブロック

本文に GameScene.BOMB_WORDS の語が含まれていると、その語を構成する文字の ブロックが爆弾になる。語を増やすときはこの配列に足すだけでよい。1文字だけの 語も指定できる。現在の内訳は次の通り。

系統	語
抽選・チケット	抽選 当選 落選 外れ 用意 希望
選考・就活	選考 不採用 見送 内定 残念 期待 厳正 慎重 検討
単体でも落選を連想させる字	縁 祈 選 残

単漢字ではなく語で持たせているのは、「抽選」「見送」のように隣り合うブロックが まとまって赤くなったほうが、何が爆弾なのかを目で読み取れるため。「結果」のように それ自体は中立な語は、手がかりが薄れるので入れていない。

語どうしは範囲が重なってよい。検出はフラグを立てるだけなので、'選' と '抽選' の両方に当たっても二重には効かない。重ねて持つ意味はあって、たとえば '抽' が 爆弾になるのは「抽選」と続いたときだけになる。

同梱の EMAIL_TEXTS 10文面では全体の約18%が爆弾になり、どの文面にも必ず 1個以上の爆弾が出る。

• 見た目は赤い紙（Block.js の BOMB_* 系の配色）。文字はそのまま読める。
• 引き金は球との衝突だけ。 このゲームにブロックが壊れる仕組みは無いので、 爆弾だけが collide を監視して Block.hitByBall を立てる （BOMB_TRIGGER_SPEED = 1.5 未満のかすった接触は無視する）。 GameScene._resolveBombs() が毎フレームこれを見て爆発させる。
• 爆発した爆弾はその場で消え、棒から落としたときと同じく粉砕された扱いになる。 棒から取り除かれたことに変わりはないため。
• GameScene._explode() が爆心から半径 EXPLOSION_RADIUS 以内の動的なボディ （ブロックと飛んでいる球の両方）を外向きに押す。力は距離に応じて線形に弱まり、 外周でゼロになる。遮蔽は見ていない。
• 調整するのは EXPLOSION_RADIUS（どこまで巻き込むか）と EXPLOSION_IMPULSE （どれだけ飛ばすか）の2つ。ブロックの質量は 1.5 なので、現在の力積 30 は 爆心でおよそ 20 m/s の初速にあたる。半径 6.0m は MAX_ROWS = 6 の壁の高さを ちょうど覆う大きさ。

This is the beginning of the README. Read the rest at the original. Read the full README ↗