二回目の更新:難易度を変えるかどうかの判断
遊びを届ける執筆にClaudeを使用しています。

公開から少し経った作品に、「後半がきつい」「難しすぎて途中でやめた」というレビューが付いた場面を考えてみます。一回目の更新では、目についた不具合を直して終えられました。二回目の更新で迷うのは、遊びの手触りに関わる部分です。難易度を下げるべきか、そのままにするべきか、という判断です。 ここで先に「下げる」と決めると、作品の核だった手応えを削るかもしれません。逆に「作者の意図だから」と動かさなければ、本当は直せたはずの離脱を放置するかもしれません。どちらの失敗も、「難しい」という一語を中身に分けないまま判断したことから起きます。 この記事では、遊ばれ方の記録から難しさを見直す手順を扱います。結論を先に言うと、判断の材料は「難しいかどうか」ではなく「どこで、どんな終わり方をしているか」です。その記録を、外部通信なしの作品でも手元で取れる形にします。
「難しい」という一語を四つに分ける
レビューや感想の「難しい」は、少なくとも次の四つに分かれます。どれにあたるかで、更新の中身はまったく変わります。
- 入口の壁:最初の数分で何をすればよいか分からず、やめてしまう状態です。難易度ではなく、説明や最初の操作の問題であることが多いです。
- 中盤の壁:特定の面や局面で失敗が続き、そこで止まる状態です。急に要求が跳ね上がっていないかを疑います。
- 終盤の壁:作品の中心を一通り味わったあとの高い山です。やり込む人向けの山として残す価値があるかが論点になります。
- 理不尽感:失敗した理由が分からない、または避けようがなかったと感じる状態です。数値の難しさとは別の問題で、下げても解消しません。
たとえば「後半がきつい」というレビューは、中盤の壁にも終盤の壁にも理不尽感にも読めます。レビューを読んだ時点では、まだ答えが出ていません。この段階でできるのは、四つのどれかという仮説を立てて、それを確かめる記録を取ることです。
記録できるもの、できないものを分ける
遊ばれ方を知る手段として、まずアソバースの画面上で確認できるものを整理します。
- プレイ回数:作品を起動した実測回数です。同じ端末・同じ作品で30分以内に起動し直した分は重複として除かれます。人数ではないので、「何人が遊んだか」「何人が途中でやめたか」を読み取る数字にはなりません。
- レビュー:1〜5点の評価と、1〜2,000文字のコメントです。遊んだ人の言葉が読める貴重な材料ですが、書く人は遊んだ人の一部です。また、評価順のランキングに載るのはレビューが3件以上になってからです。件数が少ないうちは、1件の印象が全体に見えやすい点に注意が必要です。
- ゲーム内スコアの共通ランキング:現在は提供されていません。全員の到達ステージを一覧で眺める、という使い方はできません。
つまり、プレイ回数とレビューだけでは「どこで止まったか」は分かりません。そこで、作品の側に小さな記録の仕組みを入れ、遊んでくれた数人にその記録を見せてもらう方法を考えます。
ここで前提にしておきたいのは、記録の集め方です。アップロードした作品から作者へ自動で集計が届く仕組みは、現在の確認済みの範囲にはありません。そのため、遊んだ人が画面に出た記録を、自分の手で作者に伝える形が現実的です。身近な数人に遊んでもらい、結果の文字列を貼ってもらう方法なら、外部通信なしのまま実行できます。
ステージごとの結果を画面に出す最小のコード
記録する項目は少なくします。各ラウンドで「どのステージか」「クリアか失敗か」「かかった秒数」の三つがあれば、四つの壁のどれかをかなり絞れます。以下は、単独で動く最小の例です。ボタンはゲーム本体の代わりで、実際には自作ゲームのクリア・失敗の処理から record() を呼びます。
<!doctype html>
<meta charset="utf-8">
<button id="win">クリア</button>
<button id="lose">失敗</button>
<textarea id="out" rows="6" cols="40" readonly></textarea>
<script>
const log = [];
let stage = 1, start = Date.now();
function record(result) {
log.push({stage, result, sec: Math.round((Date.now() - start) / 1000)});
if (result === "clear") stage++;
start = Date.now();
document.getElementById("out").value =
log.map(e => `${e.stage},${e.result},${e.sec}`).join("\n");
}
document.getElementById("win").onclick = () => record("clear");
document.getElementById("lose").onclick = () => record("fail");
</script>結果はテキスト欄に出すだけにしてあります。ボタンでクリップボードへ送る方法は、埋め込み表示の制限で動かない場合があるためです。遊んだ人が欄の文字を選んでコピーし、メッセージに貼れば十分です。
この記録は画面を閉じれば消えます。手元で見るためだけのものと割り切ってください。クラウドセーブを使う作品でも、他の人の分を作者が閲覧できるとは確認されていないので、同じ前提で考えます。
遊んでもらう人数は、まず3〜5人程度を目安に、自分で決めてください。目的は統計を取ることではなく、「同じ場所で止まる人がいるか」を見つけることです。数が少ないぶん、結論は断定せず仮説として扱います。
記録の読み方:パターンと判断
集まった文字列を、人ごとに縦に並べます。見るのは次の三点です。
- 最後の行が「失敗」で終わっているか、「クリア」で終わっているか
- 失敗が続いたステージはどこか、そのあとに再挑戦しているか
- クリアまでの秒数に、極端に長い・短い箇所がないか
読み方の目安を表にします。数値のしきい値は作品ごとに違うので、ここでは形だけを示します。
- 1〜2ステージ目の失敗で記録が終わる、考えられること:入口の壁、最初に確かめること:最初の画面の説明、最初の操作の分かりやすさ
- 同じステージで失敗が続き、その後クリアしている、考えられること:難しいが納得できる壁、最初に確かめること:基本はそのまま。ヒントの置き場所だけ見直す
- 同じステージで失敗が続き、そこで記録が終わる、考えられること:中盤の壁、最初に確かめること:そのステージの要求が前後と比べて跳ねていないか
- 失敗した直後に記録が終わる、考えられること:理不尽感の疑い、最初に確かめること:失敗の理由が画面で分かるか
- 秒数が全ステージで極端に短くクリアが続く、考えられること:簡単すぎる可能性、最初に確かめること:後半に新しい要素が出るまでの間隔
- 終盤まで到達し、失敗を重ねても再挑戦している、考えられること:終盤の壁として機能している可能性、最初に確かめること:残すか、救済の選択肢を足すか
特に大事なのは二行目と三行目の違いです。同じ場所で何度も失敗していても、そのあとにクリアしている人が多いなら、その難しさは遊びの一部として働いています。同じ場所で失敗して終わっているなら、そこが離脱点です。「失敗の回数」だけでは区別できず、「失敗のあとに何が起きたか」を見て初めて分かります。
もうひとつ、記録の数字だけで決めないでください。遊んでもらった人に「失敗した直後、何が悪かったと思ったか」を一言だけ聞いておくと、理不尽感か、単純に腕が足りなかったのかを切り分けられます。
変えるときの進め方
難易度を変えると決めたら、次の順序を守ると失敗しにくくなります。
一回の更新で動かすのは一か所にします。 入口の説明を直し、中盤の数値を下げ、終盤に救済を足す、というまとめての変更は、次に記録を取ったときに何が効いたのか分からなくなります。最も離脱が目立つ一か所から手を付けます。
数値を下げる前に、選択肢を増やせないかを考えます。 作品の手応えを好んで遊んでいる人もいるので、全員の難しさを下げる必要は必ずしもありません。たとえば次のような形があります。
- 失敗の理由を画面に出す
- 一回だけやり直せる救済を付ける
- 難易度を選べるようにする(公式作品にも、時間制限のない練習モードと本番に分けた作りや、複数コースを持つ作りがあります)
どれも、手応えを求める人の遊びを変えずに、止まっている人の入口を広げる方向の変更です。
保存データとの整合を確認します。 ステージの順番や数を変えると、すでに遊んでいる人の「到達ステージ」の意味がずれることがあります。クラウドセーブなどで進行を保存している作品は、保存形式を変えるなら古い形式からの移行も用意し、更新前のデータで起動して確認してください。
更新内容を紹介文や更新の案内に書きます。 アソバースでは、公開内容の更新ができます。「中盤のステージの失敗理由を表示するようにしました」のように、何を変えたかを短く書いておけば、以前に離脱した人が戻るきっかけになり、次のレビューも変更後の作品への感想として読めます。
起こりやすい誤り
最後に、この判断で陥りやすい誤りを挙げます。
- プレイ回数の増減を難易度の評価にする:プレイ回数は起動の回数で、人数でも到達度でもありません。再挑戦が多い作品は回数が増えますし、気に入ってもらえなくても増えます。
- 目立つレビューだけで動く:強い言葉のレビューは目に入りやすいものです。記録と照らして、同じ現象が他の人にも起きているかを確かめてから動いてください。
- 自分の腕前を基準にする:作者は何十回も遊んでいるので、どうしても「簡単」に感じます。記録は、初見の人の分を取ってください。
- 変更後に同じ記録を取らない:更新前と更新後で同じ形式の記録を取ってはじめて、変更が効いたかを比べられます。コードは更新後も残しておきます。
- すべての壁をなくそうとする:納得できる難しさは、作品の魅力でもあります。直すのは、遊びを止めている壁だけです。
次の行動
まず、いまの作品に前掲の記録コードの考え方を入れて、身近な3〜5人に初見で遊んでもらってください。集まった文字列を人ごとに並べ、「失敗のあと何が起きたか」の三行目を見る、という手順で、離脱点が一か所に絞れるかを確かめます。絞れたら、その一か所だけを変えて更新し、同じ記録をもう一度取って比べてください。

