マガジン

機能を一つ消すと、ゲームは良くなるのか:減らす更新の判断と確かめ方

遊びを届ける

執筆にClaudeを使用しています。

開いた箱から小さなゲームの模型を展示台に移す風景。
記事のテーマをもとに制作したAI生成イメージ。実際のゲーム画面ではありません。

公開から数週間たったパズルゲームに、更新のたびに機能を足してきた作者がいる場面を考えてみます。最初の更新でヒントボタン、次の更新でやり直し、その次で演出スキップを足しました。遊んだ人の感想は「遊びやすくなった」が多いのに、作者自身は「最初の頃にあった緊張感が薄れた」と感じています。どれが効いていて、どれが邪魔なのかは、足した順に思い出してもわかりません。 この記事で確かめるのは、機能を一つ消すと本当に良くなるのか、そしてその判断を自分のゲームで確かめるにはどうすればよいか、という問いです。減らす更新が良い結果につながるのは、消した機能が別の機能の役割を奪っていたり、プレイヤーの考える時間を肩代わりしていたりする場合です。ただし、それが自分のゲームで起きているかどうかは、見た目の印象では決められません。 ここで挙げる事例はすべて仮定の場面です。実際にこうなったという結果は書きません。代わりに、消す前に決めること、小さく試す方法、結果の読み方を順に示します。

この記事の目次
  1. 消して良くなる機能には共通点がある
  2. 公式作品に見る、機能を足し引きできる設計
  3. 消す前に決める三つのこと
  4. 最小のコードで、機能の有無と行動を並べて残す
  5. 結果の読み方と、起こりやすい誤り
  6. 次の行動

消して良くなる機能には共通点がある

機能を消すと良くなる場面には、いくつかの型があります。次のような型に当てはまるかどうかが、消す候補を絞る手がかりになります。

  • 代行型、起きていること:機能が考える作業を代わりに引き受けている、疑うサイン:ヒントを押すとすぐ解け、次の面でも押す
  • 重複型、起きていること:二つの機能が同じ不満を解消している、疑うサイン:やり直しと一手戻すが並んでいる
  • 注意散漫型、起きていること:画面上の選択肢が増え、本来の操作が埋もれる、疑うサイン:最初の数十秒に何も押さない人が多い
  • 緊張破壊型、起きていること:失敗の重みを消し、判断が軽くなる、疑うサイン:失敗しても次の試行までの間が極端に短い

たとえば代行型を考えてみます。詰まったらヒントが答えの一手を出すゲームでは、最初に「自分で考える」より「押してみる」が選ばれやすくなります。ヒントを消すと、考える時間は増えるかもしれません。一方で、詰まって離れる人も増えるかもしれません。どちらに傾くかは、ゲームの難しさとプレイヤーの層次第です。

したがって「減らせば良くなる」とは言えません。「この機能がこの型に当てはまるかもしれない」という仮説を持ち、確かめてから消す、という順序が大切です。

公式作品に見る、機能を足し引きできる設計

アソバースの公式作品には、機能の有無をプレイヤーや場面に応じて切り替える設計がいくつかあります。以下は経緯の説明ではなく、確認済みの仕様から読み取れることです。

  • 小さな軌道には、全軌道予測(点線)と前回の軌道(細い実線)があり、予測を消して挑むこともできます。補助を丸ごと外した状態を、同じ作品の中の選択肢として残している形です。
  • 時計じかけの台所には、時間制限なしの「見習い」と、1皿28秒・配膳6秒・ミス3回までの「本番」があります。制約の有無を二つのモードに分けています。
  • 潮目のオセロでは、ヒントと一手戻すはひとり対局のみで、招待リンクのオンライン対局には含まれません。対局相手がいる場面とそうでない場面で、使える機能が分かれています。
  • かたちのあいだのヒントは、次の一手を示しますが最短とは限りません。「一手戻す」でも手数は減りません。補助が結果を完全には変えない作りです。

これらから読み取れるのは、補助機能を「あるか、ないか」の二択にせず、場面や選択で外せる形にする考え方です。なぜその設計になったのかという意図は、ここでは断定しません。各作品を開いて、補助がある状態とない状態で遊び比べてみると、自分のゲームに応用できる点が見つかります。

消す前に決める三つのこと

機能を消す前に、紙一枚でよいので次の三つを書き出します。これを先に決めないと、結果が出てから都合のよい読み方をしてしまいます。

1. 問いを一文にする

「ヒントを消すと、最初の面をクリアするまでの試行回数と、途中でやめる割合がどう変わるか」のように、変化を見る対象を決めます。「面白くなるか」は測れません。測れる行動に言い換えます。

2. 見る項目と単位を決める

候補は次の四つです。多くても三つまでに絞ります。

  1. 1回のプレイの結果(クリア、途中でやめる、など)
  2. 1回のプレイにかかった秒数
  3. 消す対象の機能を使った回数(消した版では当然ゼロ)
  4. 同じプレイヤーが続けて遊んだ回数

アソバースが表示するプレイ回数は、作品の起動を実測した数で、人数ではありません。同じ端末・同じ作品の30分以内の再起動は重複として除かれます。「遊ばれた回数が増えた」は「遊んだ人が増えた」とは別の話です。自分で数える項目と、プラットフォームの表示は、混ぜずに区別して読みます。

3. 期間と戻す条件を決める

「この版を何回のプレイが集まるまで置くか」「どの状態になったら機能を戻すか」を、先に書きます。たとえば「途中でやめる割合が明らかに増え、感想にも『詰まった』が並ぶなら戻す」といった形です。数値の閾値は、自分のゲームの規模に合わせて決めます。

最小のコードで、機能の有無と行動を並べて残す

機能を消した版と残した版を並べて見るには、1回ごとのプレイを同じ形式で残しておくと便利です。次のコードは、ヒントの有無を切り替え、クリア・やめるの結果と秒数、ヒント使用回数を配列に残す最小の例です。ゲーム本体の代わりに、クリアとやめるのボタンを置いています。単独のHTMLとして動きます。

html
<button id="hint">ヒント</button>
<button id="clear">クリア</button>
<button id="quit">やめる</button>
<pre id="log"></pre>
<script>
const flags = { hint: new URLSearchParams(location.search).get("hint") !== "off" };
const runs = [];
let cur = null;
function begin() {
  cur = { variant: flags.hint ? "with" : "without", start: Date.now(), hints: 0 };
}
function end(result) {
  runs.push({ variant: cur.variant, result,
    sec: Math.round((Date.now() - cur.start) / 1000), hints: cur.hints });
  render();
  begin();
}
function render() {
  document.getElementById("log").textContent = JSON.stringify(runs, null, 1);
}
document.getElementById("hint").hidden = !flags.hint;
document.getElementById("hint").onclick = () => cur.hints++;
document.getElementById("clear").onclick = () => end("clear");
document.getElementById("quit").onclick = () => end("quit");
begin();
</script>

使い方と注意点は次のとおりです。

  • ファイルを開くとヒント付き、アドレスの末尾に ?hint=off を付けるとヒントなしで動きます。
  • 配列は画面を開いている間だけ残ります。長く残したい場合は、クラウドセーブなどの仕組みを別に検討します。アップロード作品内のlocalStorageは一時メモリーの互換処理であり、永続保存としては頼れません。
  • 投稿後の作品URLにパラメータが渡るかどうかは、公開前の表示確認で確かめます。確かめられない場合は、flags.hint の値をコード内で書き換えた二つの版を作り、下書きで見比べる方法が確実です。
  • 実際のゲームでは、end("clear") を「クリア判定が出た瞬間」に、end("quit") を「タイトルへ戻った瞬間」に呼びます。
  • 記録する項目に個人を特定できるものは含めません。ゲームにFirebaseのUID、認証トークン、メールアドレスを渡すこともしません。

結果の読み方と、起こりやすい誤り

記録が溜まったら、まず消した版と残した版を、同じ項目で並べます。読み方の目安は次のとおりです。

  • 途中でやめる割合が下がり、試行回数が増えた場合は、考える時間が増えて粘り強く遊ばれている可能性があります。ただし、単に難しくて繰り返しているだけのこともあります。感想や、プレイ後の行動もあわせて見ます。
  • やめる割合が増え、秒数が短くなった場合は、詰まって離れている可能性があります。代わりの救済手段があるか検討します。
  • 差がほとんどない場合は、その機能はあまり使われていなかった可能性があります。消しても害は少ないものの、良くなったとも言えません。「減らして整理された」程度に受け止めるのが妥当です。

誤りやすい点もあります。

  1. 少数の結果を傾向と読む。 数回のプレイでは偶然の差が大きく出ます。傾向ではなく「気づきの手がかり」として扱います。レビューも同様で、アソバースの評価順はレビュー3件以上から掲載されます。少ない件数で平均を語らない、という考え方は自作の検証にも使えます。
  2. 同時に別の変更を入れる。 ヒントを消すと同時に面の順番や演出も変えると、どれが効いたのかわかりません。消す更新は、消す以外の変更を入れずに出します。
  3. 同じ人に両方を遊ばせて比べる。 先に遊んだ版で慣れた分が、後の版に影響します。順序を入れ替えるか、版ごとに別の人に遊んでもらいます。
  4. 熱心な人の声だけで判断する。 感想を書く人は、遊びこんだ人に偏ります。感想とは別に、行動の記録も見ます。
  5. 消した理由を残さない。 数か月後に「なぜ消したのか」がわからなくなります。公開内容の更新時に、消した機能、理由、戻す条件を一行ずつメモしておきます。

次の行動

自分のゲームの機能を一覧にして、前の表の四つの型のどれかに当てはまりそうなものを一つだけ選んでください。その機能について、問い・見る項目・戻す条件を紙に書き、上のコードを参考に、機能の有無を切り替えられる形にしてみます。公式作品の小さな軌道や時計じかけの台所を、補助がある状態とない状態で遊び比べておくと、自分のゲームでの切り分け方の参考になります。