最初の公開版に何を入れ、何を入れないか：初版の範囲の決め方

初版の定義を一文で書く

範囲を決める前に、初版の目的を一文で書きます。ポイントは「何を完成させるか」ではなく「何を知りたいか」で書くことです。

• 悪い例：「全10ステージと設定画面とランキングを備えた完成版を出す」
• 良い例：「最初の3ステージだけで、遊び手が操作を理解して先へ進みたくなるかを知る」

後者は、確かめたいことが一つに絞れています。ここでの「3ステージ」「先へ進みたくなる」は仮の例です。自分のゲームでは、確かめたい問いに合わせて言い換えてください。

一文を書くときの条件は三つあります。

1. 問いが一つであること。「操作も難易度も世界観も確かめたい」は三つの問いです。
2. 遊び手の行動で判断できること。「最後まで遊ばれるか」「もう一度始められるか」のように、観察できる形にします。
3. 公開後に直せる範囲であること。直せないものは、初版に入れる前によく考えます。

この一文が、以降の仕分けの物差しになります。

機能を三つの箱に仕分ける

次に、思いついた機能をすべて書き出し、三つの箱に分けます。

• 必須、判断の問い：これがないと、初版の問いに答えが出ませんか、例：基本の操作、最初の数ステージ、失敗と再挑戦の流れ
• あとで、判断の問い：問いの答えを見てから決めても間に合いますか、例：追加ステージ、難易度の切り替え、ヒント、効果音の作り込み
• 入れない、判断の問い：今の環境や条件では実現しにくい、または問いに無関係ですか、例：サーバーが必要な機能、問いと関係しない演出

仕分けで迷いやすいのは「あとで」と「必須」の境目です。次の質問で切り分けます。

• この機能がなくても、遊び手は初版の問いに対する反応を示せますか。示せるなら「あとで」です。
• この機能を後から足すと、既存の作りを大きく壊しますか。壊すなら、初版で土台だけ用意します。たとえば、ステージのデータを配列にまとめておけば、後からステージを足すのは簡単です。

つまり「あとで」の箱に入れるのは、機能そのものであって、機能を受け入れる構造は含みません。構造だけを初版に入れ、中身は後回しにするのが現実的な落としどころです。

公式作品の設計から読み取れる範囲の切り方

アソバースの公式作品には、範囲の切り方を考えるヒントがあります。ここで挙げるのは、確認済みの仕様から読み取れることだけです。意図や経緯は、作品を開いて確かめてください。

機能が使える場面を絞る

「潮目のオセロ」には、理由付きヒントや一手戻す機能があります。ただし、これらが使えるのはひとり対局だけで、友達との招待リンク対局では使えません。機能を足すときに「どのモードに効かせるか」を分けて考えている、と読み取れます。初版でも、ヒントを全モードに入れるのではなく、まず一つのモードに限る判断ができます。

同じ中身で厚みを変える

「時計じかけの台所」には、時間制限なしの見習いと、1皿28秒・配膳6秒・ミス3回までの本番があります。料理やレシピの中身を増やさなくても、制限の有無で遊び方が二つに分かれています。初版で素材が少ない場合、遊びの厚みはルールの側で変えられるという例として参考になります。

上限を決める

「余白の庭」は、置けるものが最大80個です。時間制限もありません。上限が仕様に含まれているので、制作側は「何個まで耐えられればよいか」を決めて作れるはずです。上限をどう決めるかは自作でも使える考え方です。なぜ80なのかは、作品を開いて確かめてください。

保存を入れない判断

13作品のうち、保存があるのは「余白の庭」「WAVE / WAVE」「かたちのあいだ」の3作品です。残る10作品の記録や録音は、画面を開いている間だけ残ります。「こだまの森」の最高記録も、ゲームを開いている間だけです。保存を持たなくても成立する作品が、公式作品の中で多数派になっています。

公開後に足す

公式13作品は、v1.1で難易度・ヒント・記録などが拡張されています。初版の後に機能を広げる流れが、公式作品の側にもあります。ただし、v1.0の中身や、何を理由に拡張したかは確認できません。ここから言えるのは「公開してから足す」という進め方が選択肢になる、という点までです。

アソバースの条件から逆算する

初版の範囲は、自分の意欲だけでなく、公開先の条件でも決まります。ここでは、確認済みの条件を範囲の判断に結びつけます。

対戦機能は初版の外に置く

オンライン対戦は、公式の「潮目のオセロ」と「灯りのチェス」だけです。投稿作品向けの共通対戦APIは未提供で、投稿するコードにサーバー用のものは含められません。投稿作品の「遊び方・最大参加人数」は任意の作者申告であり、共通対戦を有効にするものでもありません。対戦を前提にした設計は、初版では「入れない」の箱に入れるのが現実的です。同じ画面でふたりが交互に遊ぶような形なら、サーバーなしで実現できます。

スコア競争の仕組みを作り込まない

ゲーム内スコアの共通ランキングは未提供です。ランキングはプレイ回数・いいね数・レビュー平均で作品を並べるもので、ゲーム内のスコアは反映されません。スコア送信の仕組みを初版に入れても、共通の場には載りません。ゲーム内で自己ベストを見せるだけなら、「あとで」の箱で十分です。

保存は「あとで」か、仕様を確かめてから

アップロードしたゲームにはSDKが自動で追加され、作品専用のプレイヤーIDとクラウドセーブ（作品ごとにJSONで128KiBまで）が使えます。URL投稿のゲームは、作者がSDKを読み込むと使えます。一方、アップロード作品内のlocalStorageとsessionStorageは一時メモリーの互換処理です。端末への永続保存の手段としては当てにしないほうが安全です。保存が必要になったときは、SDKの案内を現在の公式情報で確認してから設計します。初版では「保存なし」でも成立するかを、まず考えます。

容量とファイルの上限

アップロードは20MiB以内で、ZIP展開後は合計100MiB・1,000ファイル以内、1ファイル30MiB以内です。直下のindex.htmlが入口で、素材は相対パスで参照します。サービスワーカーやSharedArrayBufferを使うマルチスレッドは対象外です。大きな音声や画像を山ほど詰めた初版は、この上限に当たりやすくなります。初版では素材を絞るほうが、アップロードの面でも安全です。

範囲を決める手順

ここまでをまとめ、手を動かせる手順にします。紙でもテキストファイルでも構いません。

1. 初版で知りたいことを、一文で書きます。
2. 思いついた機能や素材を、思いつくだけ書き出します。この段階では削りません。
3. 一つずつ「必須／あとで／入れない」に分けます。分けるときは、前述の二つの質問を使います。
4. 「必須」の箱の中で、さらに優先順位をつけます。全部を作る前に時間切れになった場合、どこで切るかを決めておきます。
5. 「あとで」の箱の機能のうち、構造だけ先に用意するものに印を付けます。
6. 公開先の条件（容量、サーバー不可、対戦・ランキングの扱い）と照らして、「必須」に矛盾がないか確認します。
7. 公開の前に、投稿画面の「表示の確認」で自分のゲームが正しく開くかを確かめます。投稿は、入力、表示の確認、公開の3段階です。下書き保存もできるので、仕分けの途中でも状態を残せます。

「必須」の箱には、思ったより少ししか入らないはずです。入りきらないほど多い場合は、初版の問いが大きすぎる可能性があります。その場合は、一文を書き直してください。

失敗しやすい点

「あとで」のつもりが、いつの間にか必須になる

作っているうちに「これも入れたほうがいい」が増えていきます。追加するたびに、一文の問いに照らして「この機能がなくても問いに答えが出るか」を確認します。答えが出るなら、「あとで」に戻します。

公開後の数字を実際より大きく読む

プレイ回数は、作品の起動の実測回数です。人数ではありません。同じ端末・同じ作品で30分以内に再起動した分は、重複として除かれます。初版の反応を読むとき、プレイ回数を「遊んだ人数」とは扱わないでください。レビューは、1アカウントにつき1作品1件で、自作の評価はできません。件数が少ない段階では、一件一件の文章を読むほうが有用です。評価順のランキングは、レビュー3件以上から掲載される条件もあります。

直せないと思い込む

公開後は、公開内容の更新、非公開化、削除ができます。初版に不安があるときは、直せる前提で出すという選択肢があります。ただし、公開にはメールアドレスの確認が必要です。公開当日に慌てないよう、先に確認を済ませておきます。

紹介文の準備を後回しにする

投稿画面の「紹介文と遊び方を作成」は、公開済みURLまたは本人の検証済みアップロードを読み取り、選択言語の下書きを作る機能です。「この文章を使う」を押したときだけ反映され、生成操作だけで公開されることはありません。ただし、利用者ごとに1時間3回という回数の制限があります。生成された下書きは、必ず自分の目で読み、実際の遊び方と合っているかを確認してください。

次の行動

まず、初版で知りたいことを一文で書いてください。次に、いま頭にある機能を「必須／あとで／入れない」の三つに分け、「必須」が片手で数えられる数に収まるかを確かめます。収まらなければ、一文のほうを小さくします。仕分けができたら、投稿画面で下書き保存し、表示の確認まで進めてみてください。