1週間でブラウザゲームを公開するための日程設計と判断基準
遊びをつくる執筆にClaudeを使用しています。
「1週間でゲームを作って公開する」という目標を立てたとき、多くの人が直面するのは時間の配分ミスです。最初の2日間をアイデア出しに費やし、実装が間に合わず、未完成のまま締め切りを迎える。あるいは逆に、初日から実装を始めてしまい、後から設計の根本的な問題に気づいて作り直す羽目になる。1週間という期間は短いようで、正しく分割すれば十分に公開まで到達できる長さです。 この記事では、7日間をどう区切り、各日に何を決めて何を避けるべきかを具体的に整理します。体験談ではなく、ゲーム開発の工程論と1週間という制約から導いた設計指針です。初めて公開を目指す人にも、以前挫折した人にも使えるように書いています。
なぜ「日ごとの設計」が必要なのか
1週間の失敗パターンの多くは、「残り日数に対してスコープが大きすぎる」という一点に集約されます。ゲームには、アイデア・設計・実装・素材・デバッグ・公開という最低6つの工程があります。これを7日間に当てはめると、1工程に使える時間はほぼ1日です。余裕は1日しかない。
この制約を最初に受け入れることが、完走の前提条件です。1週間プロジェクトで重要なのは「良いゲームを作ること」ではなく、「公開できる状態まで持っていくこと」です。公開した0.1点のゲームは、未完成の10点のゲームより価値があります。公開という行為そのものが、次のゲームを作るための経験と動機になるからです。
1〜2日目：スコープを決める唯一の機会
最初の2日間は、アイデアを絞ることに使います。ここでの判断が全体の完走率を左右します。
1日目：ゲームの「核」を一文で書く
「〇〇をして、△△になるゲーム」という一文で説明できないアイデアは、1週間では作れません。たとえば「ブロックを積んでタワーを高くするゲーム」は一文で書けます。「様々な職業のキャラクターを育てて街を発展させるゲーム」は一文ですが、1週間では無理です。
判断基準は「プレイヤーがやることが一つに絞れているか」です。操作・目的・終了条件の三つが初日中に決まらないアイデアは捨てます。
2日目：技術的な実現可能性を確認する
使うツールやAIで、その核が作れるかを確認します。物理演算が必要か、サウンドは要るか、データの保存は必要かを洗い出します。「〜があると良い」という要素はすべて削除リストに入れ、「なければゲームが成立しない」要素だけを残します。
この段階で「作れるか不安な要素」が一つでもある場合、その要素をなくす方向でアイデアを修正します。技術的な問題を抱えたまま実装フェーズに入ると、3〜4日目に詰まって全体が崩れます。
3〜5日目：実装は「遊べる最小形」から始める
3日目：動くものを作る
3日目の目標は、見た目がひどくても良いので「一回プレイできる状態」にすることです。UIも画像もなくて構いません。四角形が動いて、何かにぶつかって、スコアが変わる。それだけでいいです。
この日に完璧を求めると、5日目に何も動いていないという最悪の事態になります。「完成度30%のものをこの日に作る」という目標設定が正しいです。
4日目：ゲームループを完成させる
ゲームに「開始→プレイ→終了→もう一度」というループがあれば、それが動く状態にします。スタート画面とゲームオーバー画面だけで十分です。スコア表示、リトライボタン、このループが4日目の成果物です。
ここでよくある失敗が「演出を作り始める」ことです。エフェクト、アニメーション、BGM——これらは5日目以降に回します。4日目は「遊べる形であること」を優先します。
5日目：最低限の見た目を整える
ゲームの視認性に関わる部分だけ直します。テキストが読めるか、ボタンが押しやすいか、スマートフォンで崩れないか。この日に「かっこよくする」作業をしてはいけません。「分かりにくい部分をなくす」作業に絞ります。
スマートフォン対応は、ブラウザゲームとして公開する場合に見落とされやすい点です。タッチ操作への対応と画面幅の違いは、5日目の時点で確認しておかないと、公開直前に大きな修正が必要になります。
6日目：デバッグと「他人の目」
6日目はデバッグです。自分でプレイするだけでなく、自分以外の人に触れてもらうことが理想ですが、それが難しい場合は「初めてこのゲームを見た人の目」を意識して操作します。
チェックする観点は次の三つに絞ります。
- クラッシュしないか：エラーでゲームが止まる状態のまま公開しない
- ルールが分かるか：説明なしで最初の操作が分かるか
- 終了条件が伝わるか：ゲームオーバーや達成の基準が画面から読み取れるか
この日に新機能を追加するのは禁止です。「あれも入れたい」という気持ちが出てきますが、デバッグ中に新しいバグを生み出すリスクが高まります。追加したいものはメモに残して、公開後のアップデートに回します。
7日目：公開の手順と確認点
最終日は公開作業です。アソバースの場合、HTMLファイルやZIPファイルの直接投稿、または公開済みURLの登録に対応しています。自分の開発環境に合った方法を選びます。
公開前に確認するのは以下の点です。
- タイトル・説明文・サムネイルが揃っているか
- 説明文にプレイ方法（操作キーやタップ操作）が書かれているか
- 異なるブラウザ（ChromeとSafariなど）で動作するか
- スマートフォンの実機またはブラウザの開発ツールで表示を確認したか
説明文は「このゲームで何をするか」を3行以内で書きます。長い説明はほとんど読まれません。操作方法を一言で伝えることを優先します。
公開後にやることも決めておきます。バグ報告を受けた場合の修正フロー、次のバージョンで追加したい要素のメモ。公開はゴールではなく、フィードバックを得るための開始地点です。
次の行動
まず「ゲームの核を一文で書く」作業を今日中に行い、その一文を1日目の成果物として扱ってください。アソバースへの公開方法（HTMLファイル・ZIP・URL登録）は公式サイトで最新の手順を確認してから7日目に備えます。作り切って公開することが、次のゲームを作る最短の準備になります。
