紙とペンでゲームを試作する：コードを書く前の検証
遊びをつくる執筆にClaudeを使用しています。
ゲームを作ろうとしたとき、多くの人がまずコードエディタやAIツールを開きます。しかし、動くものができてから「思ったより面白くなかった」と気づくのは、時間とモチベーションの両方を消耗します。紙とペンで30分試すだけで、その問題の大半を事前に見つけられます。 紙プロトタイプとは、ゲームのルールや判断の流れを紙の上で再現し、実際にプレイしてみる手法です。カードゲームやボードゲームの設計で長く使われてきましたが、ブラウザゲームやパズルゲームの検証にも同じ考え方が使えます。「コードを書かずにゲームを動かす」ことが目的ではなく、「コアとなる判断や手応えが成立するかを最速で確かめる」ことが目的です。 この記事では、なぜ紙プロトタイプがブラウザゲーム開発に有効なのか、どんな場合に使うべきか、そして実際に手を動かすための手順を説明します。
コードを書く前に紙で試す理由
プログラムでゲームを作るとき、最初に時間がかかるのはたいていUI（画面の見た目）や入出力の処理です。しかし、ゲームの面白さを決めるのはそこではありません。「プレイヤーが毎ターン迷えるか」「選択に意味があるか」「難易度の上がり方が自然か」といった、ルールと手応えの設計が核心です。
紙で試す最大の利点は、この核心だけを取り出して検証できることです。UIを作る時間ゼロで「ゲームとして成立するか」を問えます。また、紙であれば修正に躊躇がありません。ルールを書き直す、カードを増やす、得点の計算式を変えるといった変更が、消しゴム一つでできます。コードに埋め込んだ後では、同じ変更が数時間かかることもあります。
もう一つの利点は、人に見せやすいことです。友人や家族に「これを動かしてみて」と頼むとき、動作環境の準備が不要です。紙のプロトタイプは、最も手軽なユーザーテストの道具でもあります。
紙プロトタイプが特に有効なゲームの種類
すべてのゲームで紙プロトタイプが同じ効果を発揮するわけではありません。次の特徴があるゲームは、紙検証の効果が高いです。
- ターン制や手番がある：パズル・カードゲーム・ストラテジーなど、「一手ごとに考える」構造を持つゲームは、紙で再現しやすいです。
- ルールの組み合わせが複雑：複数の条件が絡み合うゲームは、頭の中だけでは破綻に気づきにくく、紙で動かすと矛盾がすぐ見えます。
- リソース管理がある：体力・コスト・時間など数値を管理する仕組みがある場合、計算式の妥当性を紙でシミュレーションできます。
- プレイヤーの選択肢が複数ある：「次に何をするか」を毎回選ばせるゲームは、その選択が本当に迷わせるかを紙で確かめられます。
逆に、反射神経を問うアクションゲームや、視覚・音響効果がコアなゲームは、紙では体験の本質を再現しにくいです。ただし、そういったゲームでも「敵の出現パターン」「スコアの伸び方」といる設計要素は紙で検証できます。
紙プロトタイプの作り方：最小限の道具と手順
必要なものは、紙・ペン・はさみ、必要に応じてサイコロかコインだけです。
1. ゲームの「一手」を書き出す
最初に、プレイヤーが1回の操作で何を決めるかを一文で書きます。「カードを1枚選んで出す」「マスに駒を動かす」「スキルを選んで敵に当てる」など、最小の行動単位を明確にします。これが曖昧なまま進むと、プロトタイプを動かしているうちに「そもそも何をテストしているか」が分からなくなります。
2. ゲームの終了条件と勝敗を書く
「HPが0になったら終了」「ゴールに先に着いたほうが勝ち」など、終わりの定義を紙に書きます。この時点で矛盾が見つかることが多く、それだけで紙プロトタイプの価値があります。
3. ゲームに登場する要素をカードや駒にする
カードゲームであればカードに見立てた紙片に数値と効果を書きます。マップがあれば方眼紙にマスを書きます。キャラクターは硬貨や消しゴムで代替できます。見た目の完成度は不要で、数値と関係性が読めれば十分です。
4. 一人で1〜2回通してプレイする
実際にルール通りに動かします。この段階で確認するのは次の点です。
- ゲームが詰まらずに終了条件まで進むか
- プレイヤーが「どの手を選ぶか」本当に迷う場面があるか
- 特定の戦略が一方的に強くなりすぎていないか
- 計算や処理が複雑すぎて追いきれない場面がないか
5. 気づいたことをその場でメモし、ルールを修正する
動かしながら感じた違和感は、終わってから思い出そうとしても薄れます。「この手は使う意味がない」「この条件は重なりすぎる」など、感じた瞬間に余白に書き留めます。修正はすぐに紙を書き直して、もう一度試します。
「何が検証できたか」を判断する基準
紙プロトタイプを終えたとき、次の問いに答えられる状態になっているかを確認します。
コアループが回るか：ゲームの基本的な繰り返し（例：カードを引く→使う→補充する）が、詰まることなく一周できるなら、構造は最低限成立しています。
プレイヤーの判断に意味があるか：「どれを選んでも同じ」「正解が1つしかない」という状態では、選択の楽しさがありません。紙で試したとき、自分が迷った場面をカウントしてみると、その数が手応えの目安になります。
バランスが極端でないか：特定のカード・ルートだけが圧倒的に強い場合、プレイヤーはすぐに「正解」を見つけて試行をやめます。紙で複数回試したとき、毎回同じ手順で終わるなら、選択肢の再設計が必要です。
これら三つが「おおよそ成立する」と判断できたとき、初めてコードに移る準備ができたと考えます。完璧である必要はなく、「動かしながら調整する方が速い」と判断できる状態を目指します。
紙からコードへ移るときの引き継ぎ方
紙プロトタイプで確認した内容を、コードに移すときにそのまま設計書として使えます。紙に書いた終了条件・スコア計算式・カードや敵のパラメータ一覧は、変数の初期値やゲームループの骨格に直接対応します。AIツールでゲームを生成する場合も、「紙で確認したルール」を文章でまとめてプロンプトに渡すと、生成される構造がブレにくくなります。
紙プロトタイプの段階で書き留めたメモ（「この条件は重なりすぎる」「この手を選ぶ意味がない」など）は、開発中に同じ問題に気づいたときの参照点になります。コードの中で悩んだとき、紙のメモを見返すと「これは設計の問題なのか、実装の問題なのか」を区別しやすくなります。
次の行動
手元のゲームアイデアがあれば、まず紙に「一手の定義」と「終了条件」を書いてみてください。それだけで、頭の中にある設計の曖昧な部分が見えてきます。紙で動くようになったゲームは、HTMLやZIPにまとめてアソバース（https://aso-verse.com）に投稿することもできます。
