导言 Introduction

先确定读者、设计职责、全书结构与配套文件边界，再把‘会想点子’升级为可沟通、可验证、可迭代的专业设计过程。覆盖4个正式目录节点，并通过玩家合同、原型实验与试玩证据复核。

为什么“导言 Introduction”必须从玩家行为开始

先确定读者、设计职责、全书结构与配套文件边界，再把‘会想点子’升级为可沟通、可验证、可迭代的专业设计过程。本页的目标不是复制原书正文、插图或案例，而是依照Pearson官方第3版目录，把每个标题重构成可执行的设计问题、交互原型、失败注入和验收工件。正式目录节点共4个，最终产物是阅读与项目合同、术语台账、版本化设计档案。

游戏设计连接意图与行为。设计者可以声明“紧张”“自由”或“公平”，但玩家只能接触规则、状态、反馈、内容与其他玩家；因此每个体验承诺都必须追溯到可操作条件，再由目标玩家在目标平台上的行为证据验证。把配套文件当成答案，或未声明目标玩家与平台就直接制作内容，正是本单元要主动暴露的失败模式。

版次坐标与设计边界

本课程采用Ernest Adams《Fundamentals of Game Design》第3版，New Riders/Pearson，2014，ISBN 9780321929679；江涛译《游戏设计基础》，机械工业出版社，2017年9月，ISBN 9787111579687。Pearson产品页和出版社预览PDF给出导言、17章、术语表、参考文献与索引的完整顶层目录，共21个正式单元、140个标题节点；课程逐项覆盖，另设学习地图和综合验收，共23页。

目录忠实不等于逐字复制。这里保留原书的问题顺序和概念边界，示例、公式、图解、代码与练习均为独立教学重构。平台、商业模式和在线治理会随时间变化，书中的分类是设计推理起点，不是2026年的产品兼容或法规清单；项目仍需核对当前平台政策、地区规则和目标玩家证据。

五个贯穿本单元的术语

、、、、。

体验承诺限定“成功”是什么；有效选择检查玩家是否真的在决策；问题原型控制验证成本；试玩合同避免看见结果后更改问题；设计证据则让另一位设计师能复查为什么保留、修改或删除某项设计。

四个可复算模型

选择质量同时考虑可辨认度、结果差异与策略可行性：

Q_{choice}=R_{readability} \times D_{outcome} \times V_{viability}

挑战与玩家技能的匹配可记录为带压力修正的差值：

M_{challenge}=1-\frac{|C_{required}-S_{observed}|}{\max(C_{required},S_{observed},1)}-P_{stress}

试玩覆盖率不能只数参与人数，还要覆盖任务、玩家段与关键状态：

C_{test}=\frac{N_{observed\ task\times segment\times state}}{N_{planned\ task\times segment\times state}}

设计置信度由证据一致性、样本相关性和反例惩罚共同决定：

K_{design}=E_{agreement} \times S_{relevance} \times (1-R_{counterexample})

这些式子是比较框架，不是审美真理。每项变量都要声明0到1的评分规则、样本、版本和置信区间；若平均值掩盖新手、专家或无障碍用户的失败，就必须按玩家段拆分报告。

Introduction

正式节点 1/4。 先写出该标题要回答的设计问题、输入和可观察输出，再建立最小原型。 “Introduction”必须落到可操作的规则、状态、反馈或决议，并说明它与“阅读与项目合同、术语台账、版本化设计档案”的关系。

本节点的完成证据至少包含版本、参与者、任务、观察记录、度量和决策。若改变一个关键约束后结论立即失效，就要缩小适用范围或返回概念阶段，而不是隐藏反例。

Whom Is This Book For?

正式节点 2/4。 把该节点放回目标玩家、目标平台与商业边界，检查约束是否改变设计结论。 “Whom Is This Book For?”必须落到可操作的规则、状态、反馈或决议，并说明它与“阅读与项目合同、术语台账、版本化设计档案”的关系。

How Is This Book Organized?

正式节点 3/4。 同时记录正常路径、边界条件和一个失败反例，避免只凭顺利演示下判断。 “How Is This Book Organized?”必须落到可操作的规则、状态、反馈或决议，并说明它与“阅读与项目合同、术语台账、版本化设计档案”的关系。

A Note on the Downloadable Files

正式节点 4/4。 用访谈、行为遥测与可重复试玩交叉核对，不把设计者意图当成玩家体验。 “A Note on the Downloadable Files”必须落到可操作的规则、状态、反馈或决议，并说明它与“阅读与项目合同、术语台账、版本化设计档案”的关系。

把本单元转成可维护工件

先写体验合同，再画系统状态。体验合同必须包含目标玩家、使用情境、可观察行为、不可接受伤害与退出条件；系统状态则列出资源、实体、属性、动作、规则、反馈和持久化边界。二者之间每条连线都要能由原型或试玩观察验证。

阅读与项目合同、术语台账、版本化设计档案不是一次性交付物。概念阶段记录最大不确定性，详细设计阶段绑定规则和界面，制作阶段绑定版本与内容，测试阶段绑定行为和反例，发布后绑定遥测与治理。任何修改都应指向被改变的假设，并标记受影响的章节、关卡、玩家段和验证用例。

以下设计合同把范围和判断口径显式化：

{
  "unit": "gdf-3e-introduction",
  "phase": "边界与概念",
  "targetPlayer": "已招募且可观察的玩家段",
  "experiencePromise": "玩家能辨认选择、预测代价并理解结果",
  "artifact": "阅读与项目合同、术语台账、版本化设计档案",
  "rejectWhen": "关键任务失败、选择不可读或反例推翻假设"
}

用数据回答问题，而不是替玩家决定

量化只能帮助定位问题。完成率低可能来自规则不懂、控制困难、反馈延迟、目标模糊、挑战过高或玩家根本不接受体验承诺；单一漏斗无法区分这些原因。需要把事件序列、屏幕录制、口述、访谈和设计版本放在同一时间线上，再判断应改规则、界面、内容还是目标玩家假设。

一个轻量评分函数应保留分项，而不是只输出总分：

type Trial = {
  readable: number;
  outcomeDifference: number;
  viable: number;
  taskCompleted: boolean;
};
 
export function choiceEvidence(sample: Trial[]) {
  const quality = sample.map(
    (trial) => trial.readable * trial.outcomeDifference * trial.viable,
  );
  return {
    quality,
    completionRate:
      sample.filter((trial) => trial.taskCompleted).length / sample.length,
  };
}

输出数组能看见离群玩家与失败任务；若直接求平均，可能把一半玩家完全看不懂、一半玩家轻松完成包装成“中等可用”。决策记录必须同时保存分布、失败录像索引、研究者解释和仍未解决的替代解释。

先预测再运行

在打开实验前，先写下预测：当有效选择从3个增至7个、反馈延迟从80毫秒增至600毫秒、挑战从技能的0.9倍增至1.4倍时，哪一类玩家会先失去控制感？然后一次只改变一个变量，记录完成率、首次有效动作时间、撤销次数、求助次数和主观解释。观察变化后，不要立即调参；先判断测到的是学习成本、操作限制、策略深度还是招募偏差。

可执行验收场景应把体验词翻译为行为：

Feature: Introduction
  Scenario: target player can explain a meaningful choice
    Given a fixed build and an unseen decision state
    When the player compares the available actions
    Then the player predicts a distinct consequence for each viable action
    And the observed result matches the declared rule and feedback contract

三类高频误区

本章回顾

“导言 Introduction”的核心不是产出更多文档，而是把先确定读者、设计职责、全书结构与配套文件边界，再把‘会想点子’升级为可沟通、可验证、可迭代的专业设计过程。转为可验证合同。完整链路应留下体验承诺、规则状态、最小原型、试玩合同、分段证据、反例与版本化决议；缺少任何一环，都无法证明设计意图已经成为玩家可感知的体验。