猫仕様のブラウザ・ピンボールを作りました。
最初のきっかけは、「ヤフーきっずとかで、これ系のゲームを延々とやっていたな」と思い出したことでした。
そして、猫はピンボールと相性が良いと思いました。前足を出す動き、飛んでいくものを目で追う動き、獲物を狙うときの集中した感じ。フリッパーでボールを打ち返す遊びと、うまく重なって見えたのです。
完成したゲームには、鳴く猫バンパー、くるくる回る細長い猫、どこに出るか分からないワープ穴があります。
ただ、この形に落ち着くまでは、今まで作ったものの中でも一段とトライアンドエラーの多い制作でした。
最初はパステルカラーにしようとしていた
作り始めたときは、もっとキャッチーな見た目を想像していました。
パステルカラーを使い、猫の可愛さを前面に出す方向です。でも、ピンボールという遊びが持つ、暗い筐体の中でライトが点滅する感じや、金属と色ガラスのような雰囲気が薄くなりました。
そこで、深い紫をベースに、朱色、黄色、ミント色の光を配し、レトロなピンボール筐体に近づけました。
「猫らしさ」は消さず、それまでのシリーズとは盤面全体の印象を変える。その両方ができたのは良かったと思います。
軽いことを、機能不足だと思わない
このシリーズでは、「軽くて快適で、始めることに抵抗がない」ことを大切にしています。
アカウント登録も、説明の読み込みも、大きなデータのダウンロードもなく、URLを開いたらすぐ遊べる。今回もHTML、CSS、Vanilla JavaScriptだけで作りました。
Canvasはよく使いますが、ゲーム用ライブラリについてはまだまだ知らないものがあります。APIも同じで、知らない手段が見つかるのは楽しいです。
ただ、今回は「知らないライブラリを使うこと」より、「小さくすぐ遊べること」を優先しました。結果として、ファイルをそのまま配信できる構成になりました。
ピンボールをあまり触ってこなかった
ここが、制作中の難しさにつながりました。
私がゲームセンターで遊ぶ年齢になった頃には、ピンボールは「古い台が1台あるかどうか」という存在でした。
そのため、障害物がどれくらいの大きさで、何個くらい置かれていると自然なのか、感覚がありませんでした。
実は、ネットにある実際のピンボールの写真をAIに渡したのは、制作途中の1回だけです。
今考えれば、最初のプロンプトで参考画像を渡すべきでした。ピンボールらしい比率と、デジタルの画面で必要な遊びやすさを、もっと早い段階で比較できたと思います。
ボールの導線は、画面を見るだけでは分からない
一番苦労したのはボールの導線でした。
ボールが止まる、必ず失敗する、フリッパーまで来ない。見た目としては完成していても、実際に遊ぶとこうした問題が出てきます。
自分と上司で何度もテストプレイをして、必ず死んでしまう箇所を潰していきました。
でも、ボールが落ちないようにすると、今度はゲームがぬるくなります。難しくしたいから落とし穴を追加すると、納得感のない失敗が増えます。
ここで上司から出たのが、単に落とすのではなく、ボールの動きそのものを変えるアイデアでした。
その結果、落とし穴は、どこに飛ぶか分からないワープ穴になりました。ミスを罰するのではなく、予想外の動きに変える。難しさの種類を変えることで、ただ安全なだけの盤面になるのを避けました。
「ぬるめ」をゴールにする
最終的に、難易度はぬるめに落ち着きました。
これは調整に失敗した結果ではありません。上司が「これくらい、考えずに遊べるのがいい」と言ったことで、このゲームの使い方がはっきりしました。
曇つぶしや、仕事中に少し気分を変えたいときに触るゲームです。集中して攻略するゲームにする必要はありません。
プレイヤーに力を抜いて遊んでほしいのなら、作る側も、快適さは大切にしつつ、少し肩の力を抜いてもいい。そう思えるようになりました。
楽しさを作る場所は、UI・音・ボールの動きで違う
制作中、「楽しさ」を1つのパラメータで考えないほうがよいと感じました。
気持ちの充実感を作るのは、UIや音です。ボールが当たったときに光る、点数が出る、猫が鳴く。操作が成功したときの「手応え」は、こうした反応で作れます。
一方、難易度を作るのは、障害物の大きさや配置、ボールの速さと導線です。
反応を増やしても難しくはなりませんし、障害物を増やしても気持ち良くなるとは限りません。それぞれの役割を分けて調整すると、何を変えたときにどこへ影響するかが見えやすくなりました。
一番気に入っているのは、回る猫
一番気に入っている仕掛けは、圧倒的に猫風車です。
デフォルメされた細長い猫が、盤面の真ん中でくるくる回ります。ボールが当たると回転方向や速さが変わり、ボールも弾き返します。
しっかりゲームの障害物として機能しているのに、見た目はただただ可愛い。猫をテーマにした意味が、一番分かりやすく出た要素だと思います。
一方、シュールで気に入っているのはワープです。穴に入った瞬間、画面に「どこ!?」と出ます。ワープする箇所自体が「どこ？」としゃべるとは、あまり誰も思わないはずです。
AIと作ると、微調整が主な仕事になる
AIとの開発で、いつも大変だと感じるのは微調整です。
大きな画面を作ることや、機能を追加することは速い。しかし、「ボールがたまにここで止まる」「棒が少し歪んで見える」「右下の隙間が大きすぎる」といった、小さくて具体的な違和感を潰すことに時間がかかります。
今回は、問題が起きた瞬間のスクリーンショットを渡しながら修正しました。
文章で「右下がおかしい」と説明するより、画像でボールの位置を見せるほうが原因を共有しやすく、修正も早くなりました。動的なバグでも、止画が十分役に立つ場合があります。
修正と実装でAIを使い分ける
これはあくまでも現時点での個人的な感覚ですが、Claude CodeよりGPTのほうが、「重箱の隅をつつく」ようなセルフレビューと修正をするイメージがあります。
一方で、最初の実装や大きな構成を進める場面では、別のAIが合うこともあります。
だから1つのAIで最初から最後まで通すより、「大きく作る」と「細かく疑う」で使い分けるのが、今の自分には合っています。
もちろんモデルや指示の出し方によって変わります。いつでも同じ結果になる比較ではなく、私の今の開発スタイルとの相性の話です。
実装が速いと、テストプレイに時間を使える
今回の制作を一言で振り返ると、「今までよりも、より一段とトライアンドエラーだった」です。
でも、それは実装が進まなかったという意味ではありません。逆に、AIで実装が早くなったぶん、遊んで確かめる時間を増やせました。
ゲームは、仕様書と画面を見ても、「なんか楽しい」かどうかは分かりません。ボールがよく動くか、死に方に納得できるか、またやりたいか。最後は遊ばないと判断できません。
実装時間が短くなった分を、完成までの短縮だけに使うのではなく、確認回数を増やすために使う。今回、AIを使ったゲーム制作で一番実感したのはそこでした。
仕事中に遊んでも、たぶん怒られない
このゲームは、少し暇なときや、仕事中に気分を変えたいときに触ってほしいです。
少しの気分転換で仕事が捗るなら、上司も怒らないでしょう。たぶん。
ほどほどに遊んでみてください。
🐱 でぶねこ｜猫好きエンジニア
週2ペースでゆるくネタ系Webアプリを作ってます。
良ければXもフォローしてください🐾
▶ X: https://x.com/dev_cat222