メインコンテンツへスキップ
ブログ一覧へ
開発

ミニゲーム開発記:お昼休みの同僚から始まったランキングシステム

2025年12月7日·8 分で読める

ある日のお昼休み、オフィスを見回すと同僚数人が反射神経テストのサイトを繰り返しプレイしていました。10msでも縮めようと何十分もリトライしているんです。その様子を見て、二つのことを思いました。一つは「このゲームは人を引きつける力があるな」、もう一つは「作るの難しくなさそうだな」。最初のミニゲームはそんなふうに始まりました。

最初のゲームは思った通り簡単だった

反射神経テスト自体は難しい部分がありませんでした。画面の色が変わったらクリック、反応時間を計測して結果を表示——ロジックが単純だったのでGeminiがすぐに基本の骨格を作ってくれて、私はデザインを整える方に集中しました。心理テストをいくつも作る中で積み上げたコツがあったのも助かりました。一つ完成するとNext アイデアが自然に浮かんでくるもので、続けてエイムトレーナーも作りました。

その後、順間記憶テスト、1 to 50の順番で作りました。ゲームごとにロジックは違いましたが、アプローチは似ていました。ゲームのアイデアを説明するとGeminiが基本実装をしてくれて、私は実際にプレイしながらフィードバックを繰り返しました。

でも、ゲームが増えるにつれて…

心理テストは結果の構造が似ているので、一つの共通ページで処理できました。でもゲームは違いました。反射神経テストは3回の平均を出し、エイムトレーナーは30秒間スコアを積み上げる方式でした。回数、タイマーの有無、スコアの計算方法がゲームごとに違うので、「このゲームも同じページに入れればいい」という考えが通用しませんでした。結局、新しいゲームを作るたびにほぼゼロからページを別途作らなければなりませんでした。

心理テストは「型が同じ」がメリットでしたが、ミニゲームは「型がすべて違う」が現実でした。

ランキングがないと面白くない

ゲームをいくつか作って自分で何度かプレイしてみると、何か物足りない感じがしました。一人でスコアを見るだけでは楽しさが半分だという感覚でした。お昼休みに同僚たちがスコアを比べていた光景を思い出しながら、全ユーザーのランキングがあれば繰り返しプレイしたくなるかもしれないと思いました。日次・週次・月次に分けたランキングシステムを追加することにしました。

バックエンドなしでランキングを作る

ランキングを追加すると決めてから、現実的な問題が出てきました。ランキングシステムはユーザーデータをサーバーのどこかに保存する必要があるのですが、それまでバックエンドはまったくありませんでした。誕生記で話したように、Java/Spring Bootのサーバーを自前で立てるのは本末転倒でした。新しいバックエンド手段が必要でした。Geminiに聞いてみると、シンプルに導入するならFirebaseを勧めてくれました。FirestoreでデータをFirestoreに保存して、Functionsでサーバーロジックを処理する構成です。このタイミングで初めてFirebaseをプロジェクトに導入することになりました。

Firebaseは初めて使うサービスでした。コードの接続はGeminiが処理してくれて、そちらは予想通り難しくありませんでした。本当に詰まったのは、Firebaseのダッシュボードでの設定でした。

3編のCloudflareデプロイの時と同様に、ダッシュボードの画面をスクリーンショットに撮ってGeminiに送りました。「この画面で次に何をクリックすればいい?」と聞きながら一つずつ進めました。時間はかかりましたが、最終的に繋がりました。

知人たちが繰り返しプレイするようになった

ランキングシステムをつけてから、まず知人たちに見せました。反応が面白かったです。スコアが気に入らないのか、何度もリトライするんです。特に反射神経テストで1位が入れ替わるたびに互いに刺激を受けて何度もやり直しました。お昼休みに同僚たちが他人の反射神経テストに何十分も使っていたのと全く同じパターンでした。意図通りになったと思いました。

振り返ると悔やまれること

今Q-Fitのゲームリストを見ると、ボタンのサイズ、フォントサイズ、結果の表示位置がゲームごとに少しずつ違います。初期にゲームUIに関する文書化を十分にしていなかったからです。心理テストは結果ページの構造を早期に統一して共通コンポーネントに分離することに成功しましたが、ゲームはそうできませんでした。ランキングシステムを追加した後も、結果画面にランキングをどう表示するか、ボタンスタイルをどう統一するかの基準を前もって決めていませんでした。

ミニゲームに関する文書化をもっとしておくべきでした。もちろん4編で話したように、文書を作ってもAIがちゃんと従ってくれない問題があるので、後から作っていてもうまくいったかどうかはわかりませんが。

最終的には後からゲームの共通コンポーネントやフックを作ってガイドを整備し、ある程度統一できましたが、そのプロセスにはかなり時間がかかりました。最初から基準があればもっとスムーズだったのにという気持ちは今でも残っています。

ゲームを作りながら学んだこと

ミニゲーム開発を通じて、繰り返しプレイを促す要素が何かを少しは理解できました。単純にゲームが面白いだけでは不十分です。「自分のスコアはどのあたりにいるんだろう?」という好奇心、そして「もう一回やればランクが上がりそう」という感覚が必要です。ランキングシステムはその二つを満たしてくれました。もちろん、ランキングをつけたからといってすべてのゲームが面白くなるわけではありません。基本的なゲームプレイが繰り返す価値があるという前提が先にあります。

そして、ゲームは心理テストより「一度やってみればわかる」フィードバックがずっと早く来ます。作ってから5分プレイするだけで、面白いかどうかだいたいの感触がつかめるんです。その素早いフィードバックサイクルのおかげで、比較的短期間に複数のゲームを作ることができました。次の編では、ゲームの数が増えるにつれて共通構造を作っていくプロセスをもう少し話してみようと思います。

関連コンテンツ

他の記事を見る