game-design

ゲームデザイン

プレイ体験に基づいて書かれた、デザイナー向けのリファレンスです。何をデザインするのか、そしてなぜうまく機能するのかを判断するために使ってください。エンジンでの実装方法は godot が扱います。変更がデザインと実装の両方に関わる場合は、どちらかに任せるのではなく、両方を並行して進めてください。17本のゲームを分析して抽出した、複数のゲームにまたがるパターンカタログ、長く使えるデザインフレームワーク、インターフェースと UX のレイヤー（メニュー、画面、教え方、会話、フィードバック、アクセシビリティ）、そして「確固とした意見を持ちながら、教条的にはならない」という姿勢が含まれています。どちらのアプローチも有効ですが、ゲームによって向き不向きがあります。立場を選び、この考え方に異議を唱える覚悟も持ってください。

ゲームデザインが話題に上がったら、必ずこのスキルが起動します。コンセプトとそれを収める場所が必要な新しいゲームのアイデア、しっくりこないメカニクス、作り直し、バランスに関する疑問、デザインが必要なメニューや HUD、チュートリアル、会話画面、「これは楽しいか／作業感が強すぎないか／支配的な戦略になっていないか」といった問い、あるいはゲームを作る中でエージェントがデザインやインターフェースについて独自に判断する場合などが対象です。詳しい内容は references/ の OKF バンドルにあり、このファイルは手順を示します。

まずこれを参照する

デザインに関わる変更や議論では、まず最初に参照してください。最後の手段として参照するものではなく、誰かが「デザイン」という言葉を使ったときだけ参照するものでもありません。バランスの数値、敵や難易度のスケーリング曲線、ドロップ率、ショップの価格、経済の数値、インベントリのルール、メニューの流れ、進行のゲートを決める前に、その場で思いついたり、トレーニングデータに頼ったりするのではなく、ここにある視点とパターンに照らして検討してください。実装中も同様です。GDScript やシーンを編集していて、その変更にデザイン上の判断が含まれるなら、エンジン作業とデザイン作業を並行して進めます。回答する前にこのファイルを読み込み、そこから考えてください。一般知識だけでデザイン上の回答をしようとしていることに気づいたら、立ち止まって、まず関連するリファレンスファイルを開いてください。この習慣こそがこのスキルの要であり、長いコーディングセッションの中で一度だけ起動して消えてしまうのではなく、影響力を保ち続けるためのものです。

実際のゲームプロジェクトでこれを自動化し、誰にも頼まれなくてもデザインに関わる変更のたびに参照されるようにするには、プロジェクト側で設定してください。パスを対象とする CLAUDE.md ルール、paths: で有効化するルール、またはデザインに関するキーワードがあればこのスキルの参照を促す UserPromptSubmit フックを追加できます。現在のプロジェクトにこれらを設定するには /game-design wire を実行してください。仕組みとコピーして使えるスニペットは INTEGRATION.md にあります。

視点：あらゆるゲームやメカニクスを読み解く方法

分析する対象はすべて、次の軸に照らして考えてください（手法の全容は method.md にあります）。

• 象徴的なメカニクス。 そのゲームのメカニクス上の個性を言い表す一言です。
• 中核となる対立軸。 あらゆる規模で繰り返される、唯一の緊張関係です（「リスク対リターンがフラクタル状に繰り返される」「強欲対黄金」「利便性よりも摩擦」など）。
• マクロループ。 プレイヤーが実際に繰り返すサイクルです。瞬間ごとの行動からセッション全体までを捉えます。
• メカニクスのシステム。 それぞれの主要システムを、中立的に説明します。
• デザイン上の葛藤。 開発者自身の言葉で語られた、開発者が悩んだ点です。開発者の引用は非常に貴重です。
• ルドナラティブの共鳴。 フィクションを抜きにしてループを説明してください。それでも、このキャラクターについての物語として読み取れますか？ これはあらゆるメカニクスに当ててみる視点であり、無理に達成させる目標ではありません。
• パターン。 他のゲームと共有される、再利用可能なデザイン上の工夫です（patterns.md を参照してください）。
• 教訓。 取り入れる価値があるのは何か、そしてその代償は何かを考えます。

コマンド

/game-design <command> [target] として呼び出します。

コマンド	内容
dissect	既存のゲームやメカニクスをレンズ全体で分析します。象徴的なメカニクス、中心となる弁証法、マクロループ、システム、緊張関係、共鳴、パターン、取り入れるべき教訓を検討します。
pitch	新しいコンセプトをゼロから練り上げます。象徴的なメカニクスと中心となる弁証法を選び、マクロループの概要を描き、パターンを選び、リスクを挙げます。結果は concept seed で保存します。
concept	ゲームのコンセプトバンドルを作成し、育て、手入れします。これはゲームリポジトリに置かれる、ゲームのアイデンティティのための OKF ホームです。concept seed は聞き取りインタビューを実施し、バンドルの土台を作ります（ビジョン、柱、ループは実際に記述し、世界観、キャスト、敵、システム、アート、オーディオ、スコープは仮の記述にします）。concept check は、コードを書く前に、提案された作業が種となるコンセプトに沿っているかを検証します。concept tend は決定事項を反映し、記録した理由とともに分岐を刈り込み、OKF の記録を維持します。コンセプト領域を参照してください。
mechanic	1 つのメカニクスを仕様化または改良します。解決する問題、支える弁証法、予算または経済、予告、落とし穴を定めます。
loop	ループの階層（瞬間ごと、セッション、進行、メタ）を設計または批評します。各階層が次の階層につながっていることと、核となる部分だけでもそれ自体が楽しいことを確認します。
rework	平坦または破綻したシステム（機会費用がない、支配的な戦略がある、予告が不足している、単調な反復になっているなど）を診断し、的を絞った修正案を提示します。
critique	カタログとフレームワークに照らして、批判的なデザインレビューを行います。落とし穴、支配的な戦略、倫理上の懸念を挙げます。
patterns	デザイン上の課題に関係するパターンを提示し、異なるゲームがどのように解決しているかを比較します。
compare	2 つのゲームまたはメカニクスを、選んだ軸に沿って比較します。バリエーション表の形式でまとめます。
interface	UX の基礎、ダイエジェシス・マトリックス、可読性の最低基準に照らして、画面、メニュー、HUD、ダイアログ、フィードバック表示を設計またはレビューします。
teach	ゲームの導入とメカニクスの教え方を設計します。最初のセッションでの段階的な導入、レベルデザインを通じた学習、「導入・展開・ひねり・テスト」の構成、ヒントの方針を扱います。
wire	現在のゲームプロジェクトでプロジェクト側の自動起動を設定し、デザインに関わる変更のたびにこのスキルが参照されるようにします。INTEGRATION.mdに従って、CLAUDE.md のルール、paths: スコープのルール、UserPromptSubmit フックを作成します。

コンセプトバンドル：魂が宿る場所

ゲームのアイデンティティには、コードを書く前に置き場所が必要です。concept コマンドでコンセプトバンドルを作成し、手入れできます。ゲーム自体のリポジトリに置く小さな OKF バンドルで、実際に記述する必要がある 3 つの種（X ステートメントを含むビジョン、何を拒むかをそれぞれ明示した 3〜5 個の柱、コアループの階層）に加え、世界観、キャスト、敵、システム、アートディレクション、オーディオディレクション、スコープの草案を収めます。この 3 つの種は人間の承認を受け、その後は提案されるすべての機能をそれらに照らして確認します。どの柱に貢献し、どのループ階層につながり、どの批評上の懸念を乗り越えるのかを明示できなければ、理由を記録したうえでカットリストに回します。バンドルは盆栽のように手入れし、意図的に育てて刈り込み、カットするたびに記録を残します。マクロ（レベルの構成と内容）は、プロトタイプでループ全体が成立すると証明されるまで、意図的に含めません。構成についてはconcept-bundle.md、インタビューについてはseeding.md、ライフサイクルについてはtending.md、ひな形についてはtemplates.mdを参照してください。

機能からではなく、体験から設計する

設計を支える枠組みはMDAです。メカニクスがダイナミクスを生み、それが美的体験（感じられる体験）をもたらします。デザイナーが作るのはメカニクスだけですが、プレイヤーがゲームに触れる順序はその逆で、まず美的体験から始まります。ですから、まず望む体験を定め、それを生み出すダイナミクスを導き出し、次にそのダイナミクスを生む最小限のメカニクスを作ります。「楽しさ」を直接コードにすることはできません。壊れているフィードバックループを見つけ、メカニクスの調整点を調整するのです。フレームワーク、8種類の楽しさ、動機づけモデルについてはframeworks.mdを参照してください。

基本となる手法

カタログから特に応用しやすい手法を紹介します（注意点を含む全項目はprinciples.mdを参照してください）。

• 1つの弁証法を選び、フラクタル状に繰り返す。 どの画面でも、同じトレードオフを新しい形で示します。プレイヤーはゲームの仕組みを一度学べば、どこでも応用できます。
• 1つの動詞を軸に作り、それを深める。 すべての敵、レベル、アイテムを、1つのコアとなる動詞について問いかけるものにし、アップグレードは別の動詞を並行して追加するのではなく、その動詞を発展させるものにします。磨き上げた能力1つは、中途半端な能力5つに勝ります。ただし、動詞をすべての土台にする賭けは、敵やレベルの設計次第で成否が決まります。
• メタ進行では、強さではなく多様性を解放する。 次のプレイは、簡単になるのではなく、より面白くなるべきです。（Hadesのような力を段階的に高めるメタ進行は、いずれ勝利できるようにしたいゲーム向けの意図的な例外です。）
• 代償を伴う強さが、プレイヤーの決断を促す。 明確な欠点を持つ、プレイを左右する戦利品があれば、各プレイに方向性が生まれます。代償のないアップグレードは、どのプレイも同じ何でもありの状態にしてしまいます。
• ロードアウトを予算として扱う。 強さは固定の予算（スロット、ポイント、セル、手札の枚数）の範囲内にあります。何かを増やせば、別の何かが減ります。大きな選択肢に対してスロット数を少なくすると、個性が生まれます。
• 予告は正直にする。 何が来るのかを示し、戦闘を運任せではなく判断の場にします。また、予告を決して偽ってはいけません。偽りの予告は、予告がないよりも悪いものです。正直さが問うのは「何が起きるか」であり、タイミングの厳しさは別の、調整可能なつまみで、アクセシビリティ上の代償を伴います。
• 防御側にも動詞を与える。 攻撃されたとき、プレイヤーが何かできるようにします。ターン間の何もできない時間に、ジャンルへの飽きが生まれます。防御に成功したら、生存だけでなくリソースで報酬を与えましょう。そうすれば、ゲーム内経済そのものが熟達の方法を教えてくれます。
• 引き算する。 より洗練された小さな装備一式のほうが、通常は大きなものに勝ります。見送ることを本当の選択肢にし、追加するのと同じくらい、取り除くことにも価値を持たせましょう。
• インベントリは判断の機会にも、作業にもなります。 装備、戦利品、消耗品、ロードアウト、アップグレードを1つの問題として扱います。持ち運ぶものはスロットに見合う価値があるか、そうでなければ単なる邪魔です。容量制限が選択を生むのは、そのコストが目に見え、すぐに実感できる場合だけです。また、プレイヤーが使わずにため込む消耗品は、プレイヤーを罰しています。詳しくは inventory.mdを参照してください（保管モデル、インベントリパズル、アイテム構成、強化、重量、ため込みの罠）。

ループの階層とフローの回廊

コアループは行動 → フィードバック → 報酬 → 繰り返しで構成され、瞬間ごと、セッション、進行、メタという時間尺度ごとに入れ子になっています。内側のループの出力が、外側のループの燃料になります。確認すべき点は2つです。進行要素をすべて取り除いても、最小単位の瞬間ごとのループが楽しいこと。そして、すべてのループがより大きなループにつながり、行き止まりにならないことです。難易度は、上昇するスキルに挑戦が追いつくフローの回廊に保ちます。フローのチャンネル、コスターの「楽しさとは学ぶこと」、のこぎり歯状の難易度曲線、「公平な挑戦」は、いずれも同じ範囲を指しています。詳細はframeworks.mdを参照してください。

インターフェースレイヤー

プレイヤーが認識、解釈、操作できない仕組みは破綻しています。だから、インターフェースはデザインの一部であり、上から塗るだけのものではありません。インターフェースの問題は、次の2つの問いで大半を分類できます（理論はinterface.mdを参照してください）。ユーザビリティの問題（「できると知らなかった」「間違ったものをクリックした」）でしょうか、それともエンゲージアビリティの問題（「退屈になった」）でしょうか？対処法は互いに流用できません。また、情報をダイエジェティック・マトリックスのどこに置くべきでしょうか。ダイエジェティック、ノンダイエジェティック、空間、メタのいずれでしょうか？そこから表示面ごとに分かれ、以下のバンドル内の各ページで扱います。メニュー、画面、HUD、画面間の遷移、オンボーディングとゲーム内での学習、会話と選択肢のUI、ゲーム世界内でのガイダンスとフィードバック、入力プロンプトとボタンのグリフ、そしてアクセシビリティの最低基準です。全体を貫く原則は、プレイヤーの時間を尊重すること、誠実に予告すること、色や音だけで情報を伝えないこと、そして洗練された見た目で状態を隠さないことです。

批評で見られる兆候

デザインに違和感があるときは、次の兆候を探してください（検出のサインと対処法はcritique.mdを参照してください）。

• 支配的な戦略。 いつも同じ手段が勝つため、選択になっていません。状況に応じて有効になるようにする、対抗手段を加える、またはインセンティブを修正してください（プレイヤーはどんな隙も見つけます）。
• 機会費用がない。 プレイヤーがすべてを手に入れられ、何も犠牲になりません。予算を設けてください。
• 空虚なループ。 報酬が次の段階につながらない、あるいはフィードバックが読み取れません。ループを閉じてください。
• 消耗戦／パワークリープ。 数値は上がるのに何も変わらず、新しいコンテンツが古いコンテンツの価値を下げます。規模ではなく、横方向の選択肢や能力の拡充を優先してください。
• 深さより複雑さ。 覚えるルールの数が、それらによって生まれる意思決定の数を上回っています。削るか統合してください。深さは要素を増やすことではなく、相互作用から生まれます。
• 倫理的な違和感。 プレイヤーの利益に反するエンゲージメント設計です（時間指定の周回、収益化されたランダム要素、ソーシャルグラフの搾取など）。判断基準は、こうした仕組みに応じる場合のほうが、応じない場合よりプレイヤーが楽しめるかどうかです。

スタンス

明確な見解を持ち、実際のプレイに根ざし、教条的ではありません。共鳴は診断のためのもので、規範を押しつけるものではありません。『Slay the Spire』や『Balatro』のように、設定と意図的に切り離されたゲームがうまくいくのは、フィクションを無理に押しつけないからです。計算の規模はチームに合わせ、大きくしないでください。4x4のグリッドで十分です。小さな世界なら、興味を引く地点は100か所ではなく10か所で十分です。実装する以上にデザインし、容赦なく削ぎ落としてください。emダッシュもenダッシュも使わないでください。

リファレンス一式

デザインの中核：

• method.md - 分析の視点、コンセプトページの構成、共鳴の診断。
• patterns.md - ゲーム横断パターンのカタログ（カテゴリー別の19パターン、具体例と落とし穴を掲載）。
• principles.md - 参考にしたい、デザインを支える重要な工夫とその注意点。
• frameworks.md - MDA、コアループとスキルの構成要素、フロー、プレイヤーの動機、深さと複雑さ、ゲームの手触り。
• systems.md - 経済、フィードバックループ、バランス、ランダム性、報酬スケジュール、倫理的な境界線。
• critique.md - デザインレビューで見られる問題のカタログと、作り直しの手順。
• inventory.md - 保管モデル、インベントリパズル、装備とアイテム設計、強化、消耗品、重量、ロードアウト、QoL と倫理的な境界線。

コンセプト領域：

• concept-bundle.md - ゲームコンセプト一式とは何か：ファイルの構成、3つの種、骨子と詳細のルール、OKF 適合性契約。
• seeding.md - 引き出しのためのインタビュー（フック、体験目標、柱、ループ、詳細化の工程）と、骨組みを作る手順。
• tending.md - 確認、成長、剪定：作業内容を種と照らし合わせ、決定事項を反映し、理由を記録して枝を切り落とすこと、そして「編集ではなくイベント」のルール。
• templates.md - コンセプト一式の各ファイルに使えるコピー＆ペースト用の骨組み。

インターフェース層：

• interface.md - 使いやすさとエンゲージしやすさ、ディエジェシス・マトリックス、ゲームのユーザビリティ・ヒューリスティック、UI を制約する認知、可読性の最低水準。
• menus-and-screens.md - メニューの情報アーキテクチャ、HUD の設計思想、ライフサイクル画面、プレイヤーの時間を尊重すること。
• transitions.md - 視覚表現の語彙、頻度を予算とみなすルール、状況別のプレイブック（メニュー、一時停止、ドア、死亡、部屋間の移動）、オーディオ制作。
• onboarding.md - レベルデザインを通じた指導、「導入・発展・ひねり・テスト」の構成、ガイダンスと発見の軸に沿ったヒントシステム。
• dialogue.md - 字幕の実践、分岐構造とハブ構造、言い換えの問題、スキルチェックの会話、選択肢の予告、ツール、短いセリフ。
• guidance-and-feedback.md - 経路探索と道標、シグニファイアとフィードフォワードとフィードバック、演出とその抑制要素、エラーの防止、ウェイポイントをめぐる議論。
• input-prompts.md - キーのヒントの配置、デバイスに応じたグリフの切り替え、キー割り当て変更に対応したプロンプト、グリフのアセット、タップと長押しの表現、コンソールとアクセシビリティのルール。
• accessibility.md - ガイドライン、障害のカテゴリーとその特徴、アシストモード、テキストと字幕の数値、事例。

出典

Sascha Becker の game-mechanics ナレッジベース（17のゲームを分析、ゲーム横断のコンセプトページを19件作成）を要約したものです。バンドル全体で引用している標準的なデザイン関連文献（MDA、Koster、Cook、Schell、Swink、Adams and Dormans、Schreiber、Sirlin）を基盤とし、インターフェース層はゲームのUXとアクセシビリティ関連文献（Hodent、Norman、Fagerholt と Lorentzon のディエジェシス・マトリックス、Desurvire のプレイアビリティ・ヒューリスティック、Hamilton、Game Accessibility Guidelines、Xbox Accessibility Guidelines）を基盤としています。