design-game-design-fundamentals

ゲームデザインの基礎

ゲームデザイン理論の中核――ループ、フィードバックシステム、プレイヤーの動機付け、MDA フレームワーク。あらゆるジャンルのゲームに適用できる基礎です。

---

目的

あらゆるゲームジャンルに適用できる、普遍的なデザインの基盤を提供します。このスキルでは、コアループからプレイヤー心理、進行のペース配分まで、成功するゲームデザインの土台となる理論、フレームワーク、実践的なパターンを扱います。

---

使用するタイミング

トリガー：ゲームデザイン、コアループ、フィードバックシステム、プレイヤーの動機付け、MDA フレームワーク、ゲームの手触り、進行デザイン、難易度曲線、プレイヤー心理、バートルのプレイヤータイプ、フロー状態、報酬システム

---

前提条件

ありません――基礎となるデザインスキルです。

---

中核となる原則

1. 「ゲームとは、興味深い意思決定の連続である」 — Sid Meier。あらゆる瞬間に、プレイヤーに意味のある選択肢を提示する必要があります。
2. コアループは30秒で楽しくなければならない — 宮本茂の原則。基本となるアクションとフィードバックのサイクルがすぐに楽しいものでなければ、どれだけコンテンツを追加しても補えません。
3. MDA：メカニクス -> ダイナミクス -> 美学 — Hunicke、LeBlanc、Zubek。デザイナーが作るのはメカニクスであり、プレイヤーが体験するのは美学です。ダイナミクスは両者の相互作用から生まれます。
4. フローの領域：難易度はスキルに合わせて調整する必要がある — Csikszentmihalyi / Jenova Chen。簡単すぎると退屈になり、難しすぎると不安になります。目指すのは、その間にある狭い領域です。
5. 習熟が楽しさを生み出す — Raph Koster、『A Theory of Fun for Game Design』。プレイヤーはパターンを学ぶことを楽しみます。新たに学ぶことがなくなり、パターンを完全に習得すると、楽しさは消えていきます。
6. 優れたシステム：最小限のルールから創発する複雑さ — Richard Garfield。優れたデザインは、少数の明快なルールを組み合わせ、奥深い可能性の広がりを生み出します。
7. 手触りを重視したデザイン：システムを構築する前に手触りを試作する — 宮本茂。プレイ中の触覚的な感覚や一瞬一瞬の感触は、どんな機能リストよりも重要です。
8. 報酬スケジュール：変動比率 > 固定比率 — 行動心理学（B.F. Skinner）。変動する報酬は、予測可能な報酬よりもはるかに長くエンゲージメントを維持します。
9. プレイヤータイプ：達成者、探索者、社交者、キラー — Richard Bartle。同じゲームでも、プレイヤーによって求める体験は根本的に異なります。
10. 抑制もデザインの手法です — Fumito Ueda。何を取り除くかは、何を加えるかと同じくらい重要です。洗練は引き算から生まれます。

---

手順

フェーズ1：コンセプトとビジョン

1. 中核となるファンタジーを定義します。 プレイヤーは何をしていると感じるのでしょうか。メカニクスではなく、体験を考えます。
2. 対象とするプレイヤータイプを特定します（バートルの分類）。主要なタイプはどれですか。1〜2種類を選び、そのプレイヤーに合わせてコアループを設計します。
3. 一文で企画を説明します。 ゲームを一文で説明できない場合、コンセプトは十分に絞り込めていません。
4. MDA の目標を定義します。 目標とする美学を2〜3種類選びます（感覚、ファンタジー、物語、挑戦、仲間意識、発見、表現、没入）。すべてのメカニクスは、これらの美学に役立つものである必要があります。

フェーズ2：コアループの設計

5. 30秒のループを設計します。 アクション -> フィードバック -> 報酬 -> 意思決定 -> アクション。この部分を最初に試作します。
6. セッションループを重ねます。 目標 -> [コアループ] -> 進行 -> 新たな目標。このループによって、コアループの反復に方向性が生まれます。
7. 長期ループを重ねます。 コミュニティ -> 競争／協力 -> ステータス -> コミュニティ。このループが、セッションをまたいだ継続プレイを促します。
8. ループの入れ子構造を検証します。 各ループは次のループにつながる必要があります。コアループはセッションループに必要なリソースを生み出し、セッションループは長期ループに必要な進行を生み出します。

フェーズ 3：システム設計

9. メカニクスを定義します。 各メカニクスについて、名前、ルール、入力、出力、そしてどのような「感覚」を生み出すかを定めます。
10. メカニクス同士の相互作用を整理します。 互いに効果を高め合うメカニクスはどれですか？ トレードオフを生むのはどれですか？ 相互作用から創発的な複雑さが生まれます。
11. 進行曲線を設計します。 序盤（素早いアンロック、学習）、中盤（意義のある選択、分岐）、終盤（習熟、最適化）、エンドゲーム（ソーシャル、競争、無限のスケーリング）。
12. 難易度曲線を設計します。 時間の経過に伴うチャレンジとスキルの関係を整理します。プレイヤーがフローチャネルを維持できるようにします。
13. 報酬の配分を設計します。 固定報酬（予測可能なマイルストーン）と変動報酬（ランダムドロップ、サプライズボーナス）を組み合わせます。

フェーズ 4：経済とバランス

14. リソースを定義します。 流入源（供給元）とシンク（消費先）は何ですか？ すべてのリソースに両方が必要です。
15. 成長曲線を定義します。 線形、多項式、指数関数のどれですか？ 目標とするテンポに合った曲線を選びます。
16. 最初の 30 分間をプレイテストします。 コアループは満足できますか？ アンロックのペースは適切ですか？ プレイヤーは興味深い選択をしていますか？

フェーズ 5：ドキュメント作成

17. ゲームデザインドキュメント（GDD）を作成します。 templates/gdd-template.md を使用します。
18. プレイヤー動機ワークシートを完成させます。 templates/player-motivation-worksheet.md を使用します。
19. コア原則に照らしてレビューします。 すべてのメカニクスがターゲットとする美学に貢献していますか？ コアループは 30 秒で楽しいものになっていますか？ フローチャネルはありますか？

---

コード例

コアループのアーキテクチャ

boilerplate/core-loop.ts を使用すると、ジャンルを問わず使える、ティックレートを設定可能で、システムを順番に実行するシステムマネージャーを利用できます。

import { SystemManager } from './boilerplate/core-loop';

const manager = new SystemManager({ tickRate: 60 });
manager.register('input', new InputSystem());
manager.register('simulation', new SimulationSystem());
manager.register('feedback', new FeedbackSystem());
manager.start();

フィードバックと報酬のシステム

boilerplate/feedback-system.ts を使用すると、イベント駆動型のフィードバック、報酬トリガー、連続記録の追跡、実績の進行状況を管理できます。

import { GameEventBus, RewardSystem, StreakTracker } from './boilerplate/feedback-system';

const bus = new GameEventBus();
const rewards = new RewardSystem(bus);
const streaks = new StreakTracker(bus);

rewards.register({
  id: 'first-milestone',
  condition: (event) => event.type === 'milestone_reached' && event.data.level >= 10,
  reward: { type: 'resource', id: 'premium_currency', amount: 50 },
});

難易度のスケーリング

const getDifficultyMultiplier = (
  playerSuccessRate: number,
  targetSuccessRate = 0.65,
): number => {
  const deviation = playerSuccessRate - targetSuccessRate;
  return 1 + deviation * 0.3;
};

成長曲線

const linearGrowth = (base: number, level: number, increment: number): number =>
  base + level * increment;

const polynomialGrowth = (base: number, level: number, exponent: number): number =>
  base * level ** exponent;

const exponentialGrowth = (base: number, level: number, multiplier: number): number =>
  base * multiplier ** level;

コストのスケーリング

const scaledCost = (baseCost: number, multiplier: number, owned: number): number =>
  baseCost * multiplier ** owned;

---

相互参照

必要な内容	スキル
経済バランス、リソースの流れ、インフレの抑制	game-economy-design
レベル／ワールド設計、空間レイアウト、ペース配分	level-design
クエスト／ミッションの構成、物語の展開	quest-mission-design
スキルツリー、タレントツリー、アビリティのアンロックグラフ	skill-progression-trees
ゲーム UI／UX のパターン、HUD 設計、メニュー	ui-ux-game
バックエンドアーキテクチャ、ネットワーク、状態同期	game-backend-architecture
ビジュアルアセット、プロシージャル生成	game-asset-gen
サウンドデザイン、音楽、オーディオフィードバック	elevenlabs-sound-music
放置系／インクリメンタルゲーム特有のパターン	idle-game-design

---

落とし穴とアンチパターン

設計上の落とし穴

1. ループを検証せずに機能を追加し続けること。 コアループに結びつかないメカニクスを加えると、体験が薄まります。すべての機能はループに貢献する必要があります。
2. 手触りより先にシステムを設計すること。 瞬間ごとのアクションが心地よく感じられる前に、複雑で相互に連携するシステムを構築してしまうことです。まず手触りを整え、その後にシステムを構築します。
3. 難易度曲線が平坦であること。 時間の経過とともにチャレンジが高まらないと、プレイヤーはすぐにゲームを習熟し、離れてしまいます。
4. 学習を促すのではなく、失敗を罰すること。 失敗に対する厳しいペナルティは、試行錯誤を妨げます。プレイヤーが安心して新しい戦略を試せるようにします。
5. 報酬のインフレ。 報酬を与えすぎたり、早く与えすぎたりすると、すべての報酬の価値が下がります。希少性が意味を生みます。
6. セッション設計を無視すること。 プレイヤーが実際に 1 回のセッションでどれくらいプレイするかを考慮しないと、進行が遅すぎる、または速すぎると感じられる原因になります。
7. 単一のプレイヤータイプにのみ焦点を当てること。 バートルのタイプの 1 つだけを対象に設計すると、潜在的なプレイヤーの大半を遠ざけます。
8. チュートリアルを独立した体験にすること。 実際のゲームプレイとのつながりを感じられないチュートリアルです。最高のチュートリアルは、ガードレール付きのゲームプレイそのものです。

技術的なアンチパターン

1. ハードコードされた値。 データ駆動型の設定ではなく、ゲームバランスの定数をロジックに埋め込むことです。
2. 密結合したシステム。 イベントを介して通信するのではなく、システム同士が直接参照し合うことです。
3. シリアライズ戦略がない。 最初からセーブ／ロードを考慮せずにゲーム状態を構築することです。
4. 浮動小数点数の累積。 リソースの合計に生の浮動小数点演算を使うと、時間の経過とともに精度のずれが生じます。

---

デザイナーの哲学

シンプルさについて

「完璧とは、これ以上付け加えるものがなくなったときではなく、これ以上取り去るものがなくなったときに達成される。」 — Antoine de Saint-Exupery

これはゲームデザインにそのまま当てはまります。最も長く愛されるゲームには、シンプルなルールと奥深い創発的な振る舞いがあります。仕組みを追加する前に、既存の仕組みを拡張できないか考えてみてください。

プレイヤーの主体性について

プレイヤーは常に、自分の選択が重要だと感じられなければなりません。最適な進路が常に明白なら、選択はなく、ただ実行するだけです。結果が常にランダムなら、主体性はなく、運任せです。最適なバランスは、スキルに左右される不確かな結果を踏まえた、情報に基づく選択です。

イテレーションについて

どのようなデザインも、プレイヤーとの最初の接触でそのまま通用することはありません。イテレーションを前提に計画しましょう。

• まずコアループをプロトタイプ化します（紙上またはデジタルで）。
• できる限りシンプルなバージョンで、早い段階からプレイテストを行います。
• プレイヤーの「発言」ではなく、プレイヤーの「行動」を測定します。
• 数値の調整は最後に行い、まずプレイの感触を改善します。

敬意について

プレイヤーの時間、知性、自律性を尊重しましょう。人工的な障壁を設けて、プレイヤーの時間を無駄にしてはいけません。過剰な手取り足取りで、プレイヤーの知性を侮辱してはいけません。一本道を強制して、プレイヤーの自律性を奪ってはいけません。プレイヤーはあなたのゲームと過ごす時間を選んだのです。その選択を大切にしましょう。

---

参考資料

書籍

• Koster, Raph. A Theory of Fun for Game Design（2004）。中心的な主張：楽しさとはパターンを習得するプロセスである。
• Schell, Jesse. The Art of Game Design: A Book of Lenses（2008）。デザイン上の判断を分析するための100以上の視点を紹介しています。
• Hunicke, LeBlanc, Zubek. MDA: A Formal Approach to Game Design and Game Research（2004）。メカニクス、ダイナミクス、美学を分析するための基礎的なフレームワークです。
• Csikszentmihalyi, Mihaly. Flow: The Psychology of Optimal Experience（1990）。エンゲージメントとフローチャンネルの心理学について解説しています。
• Bartle, Richard. Designing Virtual Worlds（2003）。プレイヤータイプの分類とマルチプレイヤー設計について解説しています。
• Salen & Zimmerman. Rules of Play: Game Design Fundamentals（2003）。ゲームデザイン理論を包括的かつ学術的に扱っています。
• Fullerton, Tracy. Game Design Workshop（2008）。実践的なデザイン手法とプレイテストについて解説しています。

論文・講演

• Chen, Jenova. Flow in Games（2006）。Csikszentmihalyiのフロー理論をインタラクティブエンターテインメントに応用しています。
• Garfield, Richard. Luck in Games（GDC 2012）。ゲームデザインにおけるランダム性とスキルの役割について解説しています。
• Ueda, Fumito. Design by Subtraction（GDC 2012）。中核となる体験を強めるために機能を削ることについて解説しています。
• Meier, Sid. Interesting Decisions（GDC 2012）。ゲームにおいて、どのような選択が興味深いものになるのかを解説しています。
• Blow, Jonathan. Designing to Reveal the Nature of the Universe（2011）。ゲームメカニクスにおける意味について解説しています。

オンラインリソース

• GDC Vault（gdcvault.com） — 業界のプロフェッショナルによる、何千ものゲームデザイン講演を掲載しています。
• Gamasutra / Game Developer（gamedeveloper.com） — 業界の記事や事後分析を掲載しています。
• Lost Garden（lostgarden.home.blog） — Daniel Cookによるゲームデザイン理論のエッセイを掲載しています。