CH 01第四回からの進化
Login / Logout
ログインでプレイヤーを識別。自分の記録が自分のものになる。
Dashboard
保存されたプレイデータを画面上でまとめて確認できる。
DBStudio
データベースの中身を直接のぞける管理画面。「情報を更新」で最新状態を反映。
第六回
Meow Fortress（SQLあり）
CH 02ゲーム内容 — Fish 経済とコスト制
ゲームの骨格は第四回と同じ拠点攻防だが、遊びの手触りは大きく変わった。画面上部には YOUR BASE 1000 と ENEMY BASE 1200 の HP バーが並び、リソースとして魚（Fish）が時間とともに貯まっていく（上限 1500）。
ユニットにはコストが設定されていて、貯めた Fish を消費して出撃させる。すばやいねこ（Cost 80）のような軽いユニットを数で出すか、盾ねこ（Cost 150）や星煌猫、もちもち巨兵のようなキャラがいる速さで勝負しないものを待って出すか——リソース管理の駆け引きが生まれた。ステージ制（Stage 1〜）で難度も段階的に上がる。
遊び方
魚を使って味方を出撃。左の自陣を守りながら、右の敵拠点を潰せば勝利。
Point
第四回は「どのユニットを出すか」だけだったが、Fish 経済が入ったことで「いま使うか、貯めるか」という時間軸の判断が加わった。コスト設計そのものがゲームバランスのデザインになっている。
CH 03プレイ動画
Meow Fortress を実際にプレイした様子。ゲーム画面の奥で、Dashboard / DBStudio がデータを支えている。
SQLあり版「Meow Fortress」のプレイの様子（YouTube）
YouTube で開くCH 04データベースとの連携
第五回で学んだ「同じ情報は 1 か所に持ち、ID で参照する」という設計を、そのままゲームに当てはめた。ユーザーの情報はユーザーのテーブルに 1 つだけ持ち、プレイ結果はユーザー ID にぶら下げて記録していく。
| データ | SQLなし（第四回） | SQLあり（第六回） |
|---|---|---|
| プレイヤー | 存在しない（全員同じ扱い） | ユーザーテーブルで管理し、ログインで識別 |
| プレイ結果 | 変数（リスト）に一時保存 | ユーザー ID に紐づけてテーブルへ保存 |
| 確認方法 | print で出力するだけ | Dashboard / DBStudio で画面から確認 |
裏側で働く SQL のイメージ
ゲーム側の操作は、裏側ではこうした SQL 文に置き換わって実行されている。
-- プレイ結果を保存（INSERT） INSERT INTO results (user_id, stage, score) VALUES (1, 1, 850); -- ランキング上位を取得（SELECT） SELECT u.name, r.score FROM results r JOIN users u ON r.user_id = u.user_id ORDER BY r.score DESC LIMIT 10;
Point
DBStudio を用意したことで、「保存できたはず」を目で確かめられるようになったのが大きい。データが見えると、バグの切り分けが「ゲーム側か、DB 側か」で判断できるようになる。
CH 05Before / After — SQLが変えたこと
| 観点 | 第四回（SQLなし） | 第六回（SQLあり） |
|---|---|---|
| 記録 | 再起動で消える | DB に残り続ける |
| プレイヤー | 区別できない | ログインで個人ごとに管理 |
| データ確認 | ターミナル頼み | Dashboard / DBStudio で一覧 |
| ゲーム性 | ユニット選択のみ | Fish 経済 + コスト制 + ステージ制 |
| 全体像 | 単体のゲーム | アカウントと管理画面を持つ「サービス」 |
学んだこと
SQL が入った瞬間、「ゲーム」が「サービス」に変わった。消えない・区別できる・目で確かめられる——この 3 つが揃うと、作ったものは提出物ではなく運用できるものになる。第四回で限界を体感してから組み込んだぶん、データベースのありがたみが芯から理解できた課題だった。