バージョンの付け方:v1.1とv2.0の違いを自分で決める
遊びを届ける執筆にClaudeを使用しています。

公開したパズルゲームに、ヒント機能を足す場面を考えてみます。作者は更新後の作品名の横に「v1.1」と書くか「v2.0」と書くかで、五分ほど迷います。ヒントは大きな追加に思えますが、ルールは何も変わっていません。逆に、操作キーを一つ入れ替えただけの更新は小さく見えます。それでも、前日まで遊んでいた人の指は、誤ったキーを押し続けるかもしれません。 迷う原因は、番号の意味を決めないまま番号を付けていることです。「大きい更新はメジャー、小さい更新はマイナー」という感覚は、大きさの基準が人によって違うため、判断が毎回ぶれます。この記事では、更新の「大きさ」ではなく「誰に何を約束するか」を基準にして、自分用の番号の規則を作ります。読み終えたら、過去の更新を規則に当てはめて試せます。
この記事の目次
番号は「誰への約束か」で決まる
バージョン番号は、作った本人のための記録というより、遊ぶ人への短い約束です。「v1.x の間は、前に覚えたことがそのまま通じます」「v2.0 になったら、遊び方の前提が変わっているので確かめ直してください」。この約束を番号の桁に割り当てるのが、規則を作るということです。
ゲームの場合、遊ぶ人が積み上げているものは大きく三つあります。
- 手の記憶:操作やルールの理解、コツ
- 記録:最高記録、進行状況、集めたもの
- 期待:紹介文や遊び方の説明から受けた印象
更新がこの三つのどれかを壊すなら、それは遊ぶ人の側から見て「別のゲーム」に近づく変更です。壊さずに足すだけなら、同じゲームの続きです。メジャーとマイナーの境目は、この三つを守れたかどうかで引けます。
規則案:三つの問いで上げる桁を決める
更新のたびに、次の三つの問いに答えます。
- 手の記憶は続くか。 前回遊んだ人が、説明を読み直さずに続きから遊べますか。
- 記録は生き残るか。 保存されていた最高記録や進行は、更新後も読めますか。
- 紹介文は嘘にならないか。 公開ページの紹介文や遊び方を、書き換えずに使えますか。
三つとも「はい」ならマイナー(v1.1 → v1.2)、一つでも「いいえ」ならメジャー(v1.x → v2.0)と決めます。判断を速くするために、さらに二つの取り決めを足しておきます。
- 3桁目は不具合の修正だけに使います。 v1.1.1 のように、遊びの中身を変えない直しにだけ付けます。桁を増やしたくなければ、修正は番号を上げずに更新メモへ書く方針でもかまいません。大事なのは、どちらにするかを先に決めておくことです。
- マイナーは小数ではなく整数として数えます。 v1.9 の次は v1.10 です。v2.0 に上げたくて 1.9 で止める必要はありません。
この規則の利点は、迷ったときに「大きさ」ではなく、三つの問いのどれが「いいえ」かを探せば済むことです。
場面で試す:変更の種類ごとの判定
よくある変更を、規則に通してみます。ここでの結論は規則案に基づく判断の一例で、作品の事情によって変わります。変わる場合は、どの問いが理由かを言葉にしておくと、次回も同じ基準で決められます。
- ヒント機能の追加、桁:マイナー、判断の理由:使わなければ従来通りに遊べます。紹介文には一行足すだけです
- 難易度の選択肢を追加、桁:マイナー、判断の理由:既定の難易度が従来と同じなら、問い1〜3はすべて「はい」です
- 既定の難易度を変更、桁:メジャー寄り、判断の理由:続きから遊んだ人が、前と違う手応えに出会います(問い1)
- ルールや得点計算の変更、桁:メジャー、判断の理由:手の記憶と記録の意味が変わります(問い1・2)
- 操作キーの入れ替え、桁:メジャー寄り、判断の理由:指の記憶が壊れます(問い1)。旧操作も残せるならマイナーにできます
- 保存形式の変更(移行処理あり)、桁:マイナー、判断の理由:古い記録がそのまま読めます(問い2)
- 保存形式の変更(移行処理なし)、桁:メジャー、判断の理由:古い記録が消えるか、読めなくなります(問い2)
- 見た目や効果音の差し替え、桁:マイナー、判断の理由:遊び方が変わらなければ、問い1〜3は「はい」です
- 不具合の修正、桁:3桁目、判断の理由:遊びの中身を変えず、直すだけです
「メジャー寄り」と書いた行は、工夫次第で下げられます。操作キーなら、旧キーも当面は反応させ、新しいキーを追加するだけにすればマイナーで収まります。メジャーに上げることは悪いことではありません。ただ、壊す理由が本当にあるのかを一度立ち止まって考える材料になります。
作品の番号と、保存データの番号は別物
ここで混ざりやすいのが、作品のバージョンと、保存データのバージョンです。前者は遊ぶ人への約束、後者はプログラムが自分の保存を読むための目印で、役割が違います。
アソバースの公式作品の案内には、この二つの番号が別々に出てきます。一つは、公式13作品がv1.1で難易度・ヒント・記録などを拡張したという点です。これを上の規則から眺めると、補助や選択肢を足す拡張は、ルールの核を変えない「マイナー側の更新」として読めます。ただし、公式がどんな基準でv1.1と呼んだのかは、確認済みの情報にはありません。ここは推測にとどめ、実際の作品を開いて、拡張前の遊び方と何が変わったかを自分の目で比べるほうが確実です。
もう一つは、古い保存(version1)が新しい形式(version2)へ移行されるという点です。こちらはデータの形式の番号で、作品の v1.1 とは別に数えられています。保存があるのは余白の庭、WAVE / WAVE、かたちのあいだの3作品で、他の10作品の記録や録音は画面を開いている間だけです。どの保存がどう移行されるかは、作品を開いて確かめてください。
自分の作品でも、セーブにはデータ形式の番号を最初から持たせておくと、後から形式を変えても古い記録を救えます。次は、その最小の例です。
<script>
const SAVE_VERSION = 2;
function migrate(raw) {
const s = raw && typeof raw === "object" ? raw : {};
if (s.version === SAVE_VERSION) return s;
if (s.version > SAVE_VERSION) {
console.warn("新しい形式の保存です。読み込みを中止します");
return null;
}
// version 1(または番号なし): { best: 数値 } だけだった想定
return {
version: 2,
best: typeof s.best === "number" ? s.best : null,
hintsUsed: 0
};
}
console.log(migrate({ best: 42 }));
console.log(migrate(null));
console.log(migrate({ version: 2, best: 10, hintsUsed: 3 }));
</script>ブラウザの開発者ツールのコンソールを開くと、三つの入力がそれぞれ version 2 の形に揃うことを確かめられます。ポイントは二つあります。一つは、番号がない古い保存も version 1 とみなして救うことです。もう一つは、自分より新しい形式を勝手に書き換えないことです。更新を取り消して古い版に戻したとき、新しい保存を壊さずに済みます。
アソバースでは、アップロードしたゲームにSDKが自動で追加され、クラウドセーブは作品ごとにJSONで128KiBまで使えます。形式の番号を持つJSONは、この枠にそのまま収まる形です。なお、アップロード作品内のlocalStorage/sessionStorageは一時メモリーの互換処理とされているので、記録を残したい場合はSDKのクラウドセーブを前提に設計してください。具体的な呼び出し方は、現在の案内で確認します。
自分の過去の更新で規則を検証する
規則は、作っただけでは使えるか分かりません。次の手順で、自分の過去の更新に当てはめて確かめられます。
- 過去に行った更新(または、これから行う予定の更新)を5件、一行ずつ書き出します。更新が少なければ、作りたい変更の候補で構いません。
- 各更新に、三つの問いへの「はい/いいえ」を書き込みます。
- 規則から出る桁(マイナー、メジャー、3桁目)を書き、実際に付けた番号と比べます。
- 食い違った更新に注目します。食い違いには二通りあります。規則が厳しすぎる場合は、問いの文面を調整します。付け方が場当たりだった場合は、次回から規則に従います。
- 迷った更新が2件以上あれば、「迷う理由」を共通の言葉にします。「既定値が変わる」「見た目だけど説明が変わる」といった言葉が見つかれば、それが規則に足す一行目になります。
記録は「更新ごとに一行、三つの問いの答え、決めた桁」の単位で十分です。結果の読み方は単純で、多くの更新が迷わず分類できれば規則は機能しています。分類のたびに例外が出るなら、問いが粗いということです。問いを四つ目に増やすより、迷う更新の共通点を探すほうが効果的です。
起こりやすい誤りは、大きな労力をかけた更新をメジャーにしたくなることです。番号は作者の頑張りの量ではなく、遊ぶ人への約束を表します。大量の見た目の改善でも、遊び方が変わらなければマイナーです。
番号を公開ページにどう反映するか
アソバースでは、公開した作品の内容を後から更新できます。新しい番号を決めたら、利用者の目に触れる場所にも書いておくと、約束として機能します。専用の「更新履歴」欄があるかどうかは、確認済みの情報にないため、現在の案内で確認してください。専用欄がなければ、紹介文や遊び方の末尾に、次のような短い更新メモを置く方法があります。
- v1.1:ヒントを追加しました。従来の遊び方はそのままです。
- v2.0:得点の計算を変更しました。以前の最高記録は引き継がれません。
メジャー更新のメモには、何が変わり、何が残るのかを必ず書きます。マイナー更新のメモは、一行で足ります。
また、投稿画面の「紹介文と遊び方を作成」は、公開済みURLや本人の検証済みアップロードを読み取って、選択言語の下書きを作ります。「この文章を使う」を押したときだけ反映され、生成だけで公開されることはありません。更新後に下書きを作り直して、今の紹介文との差を見れば、問い3の「紹介文は嘘にならないか」の点検に使えます。利用回数に上限(利用者ごとに1時間3回)があるため、更新ごとに何度も回すのではなく、最終版のあとに使うのがおすすめです。
次の行動
まず、自分の作品の更新を5件書き出し、三つの問い(手の記憶、記録、紹介文)に答えてみてください。そのうえで、判定表の中から自作に合う行を三つ選び、メジャーとマイナーの境目を自分の言葉で一文にします。最後に、セーブを持つ作品なら、形式の番号を最初に一つ入れておくことをおすすめします。

