序章 制作空间的乐趣

问题：这一单元在原书里解决什么

先预测：如果跳过“体验目标”，直接做到“学习边界”，最终结果会在哪个状态先失真？先写下输入、预期变化和拒绝条件，再操作图示。

序章先建立媒介判断：Unity 是把模型、图像、声音、规则和输入组织成可运行空间的整合环境。读者不必先成为建模师或程序员，但必须知道每种资产解决什么问题、项目运行依赖哪些工具，以及想创造的体验怎样被拆成可验证的技术任务。

原书位置与覆盖边界

本页对应序章，逐项保留中文版本目录中的主题：制作空间的乐趣、这样的环境就近在眼前、用Unity制作的游戏和游戏以外的内容、Unity的可能性、了解Unity的种类、必需的技术：建模、编程、声音、图像、会3D建模、编程不足为惧、能够制作声音、图形技术、安装Unity的环境、安装Unity的步骤、许可证的注册。页面不把相近的现代功能冒充原书章节；对于已经失效的 API，会先解释原问题，再给出现代等价实践和迁移证据。

核心知识与现代 Unity 对照

从兴趣到可执行目标

“制作空间的乐趣”不是宣传语，而是需求边界。先写玩家看见什么、能做什么、系统如何反馈，再决定使用三维模型、二维图像、声音还是脚本。游戏以外的展示、互动装置和沉浸式内容同样遵循这条链，因此项目类型不应被“游戏”二字限制。

技能不是入场券，而是依赖关系

建模决定形体，图像决定表面与界面，声音建立时间和空间线索，编程负责状态变化。零基础并不等于可以忽略这些职责；正确做法是先用占位资产完成闭环，再逐项替换。这样能把“不会某个工具”变成可排期的依赖，而不是项目停摆的理由。

版本、许可证与可复现环境

原书处在 Unity 5 时代，现代实践应记录 Unity Hub、编辑器版本、模板、目标平台模块和许可证状态。团队成员若使用不同版本或缺少平台模块，同一工程可能导入失败或无法构建。环境清单必须进入证据，而不能只说“我的电脑能打开”。

在复刻时，最容易犯的错误是只追求最终画面或最终数值。正确的证据链必须同时保存环境、输入、首个状态变化、中间状态、失败原因和最终产物。版本差异可以改变按钮位置或 API 名称，却不能改变本单元要解决的对象关系和验收问题。

必须在实验记录中对应一个可观察状态，不能只作为名词出现。

必须在实验记录中对应一个可观察状态，不能只作为名词出现。

必须在实验记录中对应一个可观察状态，不能只作为名词出现。

三阶段操作证据链

可复现实验

创建一个空项目，只放置地面、光源、相机和可移动立方体；记录编辑器版本、模板、平台模块和首次运行截图，再换一台环境复现。

先用一个小型组件记录实验身份。它不替代截图和运行日志，但能把环境与对象写进同一条证据。

using UnityEngine;
 
public sealed class EvidenceStamp : MonoBehaviour
{
    [SerializeField] private string unit = "ums-00-prologue-creative-space";
    [SerializeField] private string variant = "baseline";
 
    private void Start()
    {
        Debug.Log($"unit={unit}; variant={variant}; unity={Application.unityVersion}; frame={Time.frameCount}");
    }
}

本单元的最小实现如下。运行前先预测输出，运行后记录实际状态和首个差异。

using UnityEngine;
 
public sealed class ProjectIdentity : MonoBehaviour
{
    [SerializeField] private string learningGoal = "让对象响应输入";
    private void Start()
    {
        Debug.Log($"Unity={Application.unityVersion}; Goal={learningGoal}");
    }
}

最后用签发函数拒绝缺少关键证据的结果。不要为了“绿灯”把条件删掉。

public static class UnitGate
{
    public static bool CanShip(bool baseline, bool boundary, bool failureReplay, bool targetBuild)
    {
        return baseline && boundary && failureReplay && targetBuild;
    }
}

两个必须主动制造的失败样本

验收矩阵

练习

小结

• 已逐项覆盖序章的正式目录，没有用泛化高级主题替代原书。
• 已沿“体验目标 → 媒介清单 → 工具环境 → 最小项目 → 运行观察 → 学习边界”保存输入、中间状态、失败样本和交付证据。
• 已区分原书历史 API 与现代 Unity 等价实践，并保留迁移边界。
• 已通过正常、边界、失败和修复四组样本验证“同一最小项目在记录过的环境中可打开、可运行、可构建，且资产职责能逐项解释”。

术语表

来源与改编边界