第3章　《酒魂》的五维设计蓝图

「凡事预则立，不预则废。」 ——《礼记·中庸》

在正式开始之前，有一个问题必须先想清楚：你到底在做一个什么东西？这个问题看似显而易见，但大多数半途而废的游戏，恰恰是因为没想清楚就动了手。第2章提到的「范围蔓延」，本质上就是设计层面缺乏明确方向，导致开发中不断加功能、改逻辑，最终陷入混乱。而「MVP思维」的前提也正是这个核心设计——连自己在做什么都没定，最小可行产品就成了无的放矢，做了三个月才发现不好玩或系统之间打架，为时已晚。

解决什么问题： 在动手写代码之前，把《酒魂》的设计想清楚——避免做到一半发现"不好玩"。

本章将介绍《酒魂》所采用的五维设计框架——不是晦涩的学术理论，而是一套实用的设计检查清单。读完本章，你会完成一份《酒魂》的五维设计文档，这份文档就是后续所有章节的开发依据：第7章做战斗时查「醉意阈值」，第15~16章做酿造时查「品质分几级」。它不是练习，而是施工图纸。后续开发中遇到任何困惑，你都可以回到这五个维度重新审视。

3.1 游戏的五个维度：数据、规则、设定、剧情、体验

一款游戏，可以从五个相互独立又彼此咬合的维度来理解和设计。所谓「咬合」，就是像齿轮一样互相带动——改动任何一个维度，其他四个维度都会跟着受影响。先用一张表认识它们：

先说清楚本章的用法。 本章每节末尾都附有一个「动手任务」：照着模板，在《酒魂》项目的 docs/ 文件夹下填写自己的设计文档，然后翻到附录 E《酒魂》完整设计蓝图的对应小节对照。注意：附录 E 不是待填的空模板，而是《酒魂》五维设计的完整填写结果——它已经对齐「2D 像素 + 类暗黑 ARPG + 酿造经营」的定位，并与第 4~24 章的章节口径逐一呼应（每份文档开头都标有「落地章节」）。建议的用法是：先照简版模板自己填一遍，再看附录 E 的范例，看看自己的设计和范例差在哪里。

还要强调一点：这五个维度不是开发顺序，而是任何阶段都必须同时兼顾的五个视角——无论是前期设计、中期开发还是后期优化，都要确保它们协同一致。一个好的游戏，是五维协调的结果；一个崩坏的游戏，往往是某一维度与其他四个脱节。就像第 2 章提到的「完美主义陷阱」：过度追求设定精美或剧情华丽，却忽略了规则的可玩性和数据的合理性，最终做出来的游戏「好看不好玩」。

3.1.1 📊 数据——游戏世界里所有「量」的定义

数据包括： 属性、数值、资源、概率、范围、增长曲线……一切可以量化的东西。

《酒魂》的数据示例：

• 玩家生命值范围 1-200
• 醉意值 0.0-1.0
• 酒品品质分级 F/D/C/B/A/S
• 词缀权重表（决定酒品特效的触发概率）

设计数据时问自己： 这个数值的范围合理吗？它的增长曲线让玩家感受到成长，还是感受到无聊？

为什么数据维度很重要？

因为数据是游戏里最容易被忽视、但出问题最麻烦的东西。如果你在写代码的时候才临时决定「醉意值先写个0.5吧」，后面会发现：

• 醉意值衰减太快，玩家永远放不出大招
• 醉意值衰减太慢，玩家全程满醉意，没有决策空间
• 不同酒品的醉意增加值没有统一标准，平衡性完全靠猜

好的数据设计，应该在写第一行代码之前就确定下来。

在《酒魂》项目中创建数据设计文档

在《酒魂》项目根目录下，创建一个 docs/ 文件夹。在里面新建一个文件叫 01_data_design.md（Markdown格式，用记事本或VS Code都可以打开）。

在这个文件中，写下以下内容（括号里的文字替换成你的设计）：

# 《酒魂》数据设计文档

## 玩家属性
- 生命值：范围 （最小值） ~ （最大值）
- 攻击力：范围 （最小值） ~ （最大值）
- 醉意值：范围 0.0 ~ 1.0

## 酒品品质
分级：F / D / C / B / A / S（共6级）

## 货币
- 铜钱：无上限（普通货币）
- 功德值：范围 0 ~ 999（稀有货币）

## NPC好感度
范围：0 ~ 100（每20级解锁新内容）

如果你暂时不确定具体数值，可以先写「待定」。后续章节会回来填充。

数据维度在本书的落地章节： 第 4 章 4.7（DataManager 统一加载配置）→ 第 7 章（投壶评分参数）→ 第 12 章（醉意参数）→ 第 16 章（品质计算）→ 第 18 章（好感度）→ 第 22 章（货币）。

附录 E 对应小节里有什么： 主角属性表、醉意四阶段阈值、酒品字段与 F~S 分值、12 条词缀池、素材表、货币与好感度、酒坊等级表，以及末尾的「一致性检查清单」与「待定项」。其中「设计口径」一节先划定了不该出现的数值（没有单位、没有建筑、没有三资源条）——建议先读它。

👉 完整范例见 附录 E.1

3.1.2 📏 规则——游戏世界里所有「动词」的定义

规则包括： 什么能做，什么不能做，做了会怎样……一切关于「操作」和「反馈」的定义。

《酒魂》的规则示例：

• 投壶命中目标造成伤害（第 7 章）
• 醉意超过 0.8 才能释放酒魂技（第 12~13 章：阈值检测在第 12 章，酒魂技本体在第 13 章）
• 陈化 30 天，品质每天提升 0.5%（第 17 章）

设计规则时问自己： 这条规则让游戏更有趣还是更繁琐？它是否给玩家留出了足够的决策空间？

为什么规则维度很重要？

因为规则决定了玩家「玩什么」。如果你的规则只是「点一下屏幕，数字+1」，玩家3分钟就腻了。如果你的规则是「点一下屏幕，数字+1，但数字越大，下次点屏幕的风险越高」，玩家就会开始纠结——要不要继续点？

纠结，就是乐趣的来源。

在《酒魂》项目中创建规则设计文档

在 docs/ 文件夹下，新建 02_rules_design.md，写下以下内容：

# 《酒魂》规则设计文档

## 核心玩法：投壶战斗
- 操作：按住鼠标蓄力，松开投掷
- 效果：箭矢沿抛物线飞行，命中敌人造成伤害
- 决策点：蓄力时间越长，射程越远，但瞄准越难

## 核心玩法：醉意系统
- 操作：按E键喝酒
- 效果：醉意值+0.2，生命值+20
- 决策点：现在喝（提升战力但有风险）还是留到关键时刻喝？

## 核心玩法：酒魂技
- 触发条件：醉意值 ≥ 0.8，按R键
- 效果：高伤害大招，屏幕震动，诗词浮现
- 决策点：放完大招后醉意值会下降，后续战斗怎么办？

## 核心玩法：酿造
- 操作：在酒坊按F键打开酿造界面 → 选择配方 → 添加材料 → 点击酿造
- 效果：产出酒品，品质取决于材料和工艺匹配度
- 决策点：用稀有材料赌S级，还是用普通材料求稳？

规则维度在本书的落地章节： 第 78 章（投壶战斗 → 状态机）、第 1113 章（敌人 AI → 醉意规则 → 酒魂技）、第 15~17 章（酿造工艺、品质与陈化规则）。

附录 E 对应小节里有什么： 六大玩法的完整规则（投壶 / 动作战斗 / 醉意 / 酒魂技 / 酿造 / 人际与经营）、投壶四条福缘的触发概率、敌人 AI 状态表、品质计算公式、陈化规则、君臣佐使配伍结构、三维内容门控（等级 + 好感度 + 任务），以及一份待办勾选框形式的 MVP 范围清单。文档开头同样先列了「不该存在的动词」（没有建造、没有单位控制、没有采集进度条）。

按键说明： 上面的 E / R / F 都是「占位按键」，现在不需要去配置——它们分别在第 12 章（喝酒）、第 13 章（酒魂技）、第 15 章（酿造界面）实现时才会真正映射。

👉 完整范例见 附录 E.2

3.1.3 🌄 设定——游戏世界的时代背景、地理环境、世界观和美学风格

设定包括： 发生在什么时代？什么地点？什么画风？什么音乐？……一切关于「世界是什么样」的定义。

《酒魂》的设定示例：

• 唐代江南，酒香弥漫的小镇
• 水墨与工笔并存的视觉风格
• 古诗词贯穿始终

设计设定时问自己： 这个设定是否给规则和剧情提供了一个自洽的容器？玩家相信这个世界吗？

为什么设定维度很重要？

因为设定决定了「玩家信不信」。如果你的游戏设定是唐代，但NPC掏出手机发微信，玩家立刻出戏。出戏之后，再精妙的规则、再感人的剧情，都很难让玩家沉浸。

设定是所有其他维度的「容器」——它决定了什么东西在这个世界里是合理的。

在《酒魂》项目中创建设定文档

在 docs/ 文件夹下，新建 03_setting_design.md，写下以下内容：

# 《酒魂》设定设计文档

## 时代与地点
- 时代：唐代（618-907年）
- 地点：江南某小镇，靠近运河

## 视觉风格
- 主风格：水墨+浅绛彩（参考《绘真·妙笔千山》）
- 建筑：唐代风格酒肆、民居
- 角色：唐代服饰

## 可出现的元素
- 历史人物：李白、杜甫、王维、贺知章等唐代诗人
- 物品：铜钱、酒坛、竹简、毛笔
- 场景：酒坊、河边、诗会

## 绝对禁止出现的元素
- 任何现代科技（手机、汽车、电灯）
- 唐代以后的历史人物（苏轼、李清照等）
- 非中国元素（和服、西式建筑）

设定维度在本书的落地章节： 贯穿全书，集中体现于第 6 章（江南小镇地图）、第 9 章（国风 UI 主题与 StyleBox）、第 26 章（发布物料的世界观包装）。

附录 E 对应小节里有什么： 时代锁定在唐·天宝年间（而非模糊的「唐代末年」——因为李白、杜甫、王维三人只有在这个窗口才能同框）；像素美术规格（瓦片 32×32、角色单帧 128×128、基准分辨率 640×480、最近邻过滤）；15 色统一色板；听觉设定（古琴/箫/筝，三段 BGM）；以及分「世界观 / 美术 / 玩法」三层的禁止清单。

👉 完整范例见 附录 E.3

3.1.4 📖 剧情——发生在游戏世界里的事件序列

剧情包括： 主线、支线、角色弧光、情感节拍……一切关于「发生了什么故事」的定义。

《酒魂》的剧情示例：

• 主角继承破败的酒坊
• 邂逅历史上真实存在的酒仙诗人
• 通过对饮解锁他们的记忆碎片

设计剧情时问自己： 玩家有没有理由在乎这些角色？剧情的节奏是否和游戏进度相互支撑？

为什么剧情维度很重要？

因为剧情给了玩家「为什么要做这些事」的答案。如果只有规则和数据，游戏就像一个精密的机器，能运转，但没有温度。剧情让玩家在乎这个机器里发生的事情。

但要注意： 剧情不应该独立于系统之外。如果玩家可以不玩酿造就解锁剧情，那剧情就成了「额外的负担」，而不是「玩法的奖励」。

在《酒魂》项目中创建剧情设计文档

在 docs/ 文件夹下，新建 04_story_design.md，写下以下内容：

# 《酒魂》剧情设计文档

## 主线（30字版）
你继承了一座破酒坊，通过酿酒结识唐代诗人，找回失传的《酒魂谱》，复兴酒坊。

## 剧情与玩法的绑定

| 触发条件（玩法） | 触发的剧情 | 解锁内容 |
|:---|:---|:---|
| 首次酿造成功 | 镇上的人开始知道你的酒坊 | 售卖功能解锁 |
| 酒坊等级达到2级 | 李白路过，被酒香吸引 | 李白NPC出现 |
| 李白好感度达到60 | 李白讲述《将进酒》的故事 | 解锁「诗剑酒魂技」 |
| 酿造出A级以上酒品 | 消息传到杜甫耳中 | 杜甫NPC出现 |
| 收集3个记忆碎片 | 拼凑出《酒魂谱》的线索 | 开放新地图「藏经阁」 |

## MVP版本的剧情范围
只实现：开场 → 首次酿造 → 邂逅李白 → 李白好感度60 → 解锁第一个酒魂技

剧情维度在本书的落地章节： 第 18 章（古人交互与好感度）→ 第 19 章（对话树）→ 第 20 章（任务系统）→ 第 21 章（存档，把剧情进度保下来）。上表中提到的完整叙事在附录 E.4 给出了一份更深的三境界叙事草案，供你写第 18~20 章时取用。

附录 E 对应小节里有什么： 一条 30 字对外主线（继承酒坊 → 结识诗人 → 找回《酒魂谱》）+ 一条内里主线（寻父）；三境界叙事框架（人间·忘忧境 / 草木·渡厄境 / 诗酒·归真境），三境分别由李白、杜甫、王维主导——这一层完全兼容目录的章节骨架：第 18 章仍是「与李白对饮」，第 19 章仍是对话树，第 20 章仍是「找回失传酒谱」任务链，三境界只是给骨架注入血肉。文档还包含 10 个剧情触发点的完整叙事文本、代码级触发条件表、存档字段定义，以及论结局的「两条路都有代价」设计。

👉 完整范例见 附录 E.4

3.1.5 ✨ 体验——玩家实际感受到的情绪弧线

体验包括： 紧张、成就感、好奇、代入感、遗憾……一切关于「玩家感觉到什么」的定义。

《酒魂》的体验示例：

• 第一次酿出S级酒品时的惊喜
• 在醉意大爆发时释放诗号技的痛快
• 陈酒开坛时的仪式感

设计体验时问自己： 我希望玩家在这个时刻感受到什么？我的设计是否在制造那种感受？

为什么体验维度很重要？

因为体验是游戏的最终交付物。玩家花钱买游戏，买的不是代码、不是美术、不是音效——买的是感觉。

数据、规则、设定、剧情，最终都是为了制造某种体验。

在《酒魂》项目中创建体验设计文档

在 docs/ 文件夹下，新建 05_experience_design.md，写下以下内容：

# 《酒魂》体验设计文档

## 关键体验节点

| 游戏时刻 | 目标体验 | 实现手段（技术） |
|:---|:---|:---|
| 第一次酿出酒 | 成就感 | 成功音效 + 品质弹窗动画 + 酒坛发光特效 |
| 醉意达到0.8 | 紧张+期待 | 屏幕边缘泛红 + 心跳音效 + UI闪烁 |
| 释放酒魂技 | 痛快 | 屏幕震动 + 全屏粒子特效 + 诗词浮现 + 高伤害数字 |
| 陈酒开坛 | 仪式感 | 缓慢揭盖动画 + 蒸汽粒子 + 古筝音效 |
| 酿造失败 | 「再试一次」 | 产出「意外变体」（不是纯损失）+ 神秘音效 |

## MVP版本优先实现的体验
- 第一次酿出酒的成就感（最容易实现，用音效+弹窗）
- 释放酒魂技的痛快（最核心的爽点）
- 酿造失败的「意外变体」（让失败不沮丧）

体验维度在本书的落地章节： 第 13 章（酒魂技特效与诗号——「痛快」）、第 14 章（血条/醉意条/伤害飘字——「紧张与成就」）、第 17 章（酿造失败的意外变体——「失败也有趣」）、第 25 章（性能优化，保障体验不掉帧）。

附录 E 对应小节里有什么： 8 个关键体验节点（每个都带 Godot 4.7 的可执行实现细节）、6 种「有趣失败」（醉意溢出 → 宿醉 buff、酿造失败 → 意外变体、陈化超期 → 陈香赌局、连续未中 → 动态难度、主角阵亡 → 只扣铜钱、对饮失败 → 唐诗残卷）、MVP 体验优先级排序，以及节奏原则与文化统一检查表。

⚠️ 文档里做过一处技术修正：原方案的「醉意模糊（FastBlur）」在 640×480 基准分辨率下会糊掉像素网格，已改为纯色叠加 + 边缘暗角。像素项目的特效，锐度优先于华丽。

👉 完整范例见 附录 E.5

3.2 《酒魂》完整设计总览（附GDD核心内容）

上一节把游戏拆成了五个维度；这一节把它们拼回一张完整的图纸。以后任何一章开工前，你都可以先翻回这节，确认当前功能在整体中的位置。

3.2.1 《酒魂》GDD 一页版

GDD（Game Design Document，游戏设计文档）听起来吓人，对独立开发者来说，一页纸就够用了。《酒魂》的全部核心内容如下：

动手任务： 打开 docs/ 文件夹，新建 00_gdd.md，把上表抄进去。这份一页版 GDD 是后面五份维度文档的「封面」，以后每次开发前先看它。

3.2.2 五维 × 全书章节映射表

五个维度分别长在书里的哪些章？这张表是全书的施工索引：

本章开头说「这份文档就是施工图纸」，这张表就是图纸的目录页：写第 7 章投壶之前，先查 E.2；写第 16 章品质计算之前，先查 E.1。

3.2.3 五维之间的咬合关系

五个维度不是平行的，它们之间有方向性的影响关系。理解这些关系，能让你在设计时少走弯路。

设定是容器，其他四维在里面生长

设定决定了什么东西在这个游戏世界里是合理的，是所有设计的基础。

《酒魂》的设定是唐代中国，这意味着：

• 数据： 货币是铜钱，不是金币；属性名叫「功德」而非「荣誉值」
• 规则： 酿酒用的是古法工艺，不是现代蒸馏；对话用古典诗词
• 剧情： 出现的历史人物必须和唐代相关，不能让李白和苏轼同场
• 体验： 视觉风格服务于「水墨江南·诗酒人生」的整体氛围

检查《酒魂》的设定一致性

打开你刚才创建的 03_setting_design.md，在末尾添加一个「一致性检查清单」：

## 一致性检查清单

在设计任何新功能之前，先检查：
- [ ] 数据命名是否符合唐代背景？（用「铜钱」不用「金币」，用「功德」不用「荣誉」）
- [ ] 规则是否贴合唐代工艺？（酿酒用古法，不用现代蒸馏）
- [ ] 剧情人物是否生活在唐代？（李白可以，苏轼不行）
- [ ] 视觉音效是否符合水墨江南风格？

后续每新增一个功能，都先过一遍这个清单。

规则决定体验，数据调节体验

这是五维框架里最重要的一对关系。

以《酒魂》的醉意系统为例：

数据的作用是：在规则确定之后，把体验调节到「刚好好玩」的程度。

在《酒魂》项目中记录数据调节参数

打开 01_data_design.md，在末尾添加「醉意系统参数」：

## 醉意系统参数（MVP版本）

| 参数 | 值 | 设计理由 |
|:---|:---|:---|
| 初始醉意值 | 0.0 | 战斗开始时清醒 |
| 每口酒增加醉意 | 0.2 | 喝4口达到0.8，节奏刚好 |
| 醉意自然消退速度 | 0.02/秒 | 从0.8降到0需要40秒，够打完一场战斗 |
| 酒魂技触发阈值 | 0.8 | 需要喝4口才能放，有明确的积累过程 |
| 酒魂技冷却时间 | 10秒 | 不能连续放，让玩家计算时机 |
| 醉意≥0.5攻击加成 | 1.3倍 | 中段奖励，给「浅尝」的玩家一个理由 |
| 醉意≥0.8攻击加成 | 1.5倍 | 足够诱人，值得冒险 |
| 醉意≥0.8移速惩罚 | 0.7倍 | 让玩家真正感到「控制变差」 |

这些参数会在第 12 章（醉意系统）用到。

剧情借设定生根，借规则推进

《酒魂》的剧情不是独立于系统之外的「看板」，而是通过游戏规则自然流露的。

《酒魂》的剧情推进方式：

• 玩家酿出特定酒品（酿造规则）→ 触发对应古人的好感度（数据）→ 解锁对饮事件（剧情）
• 玩家在投壶小游戏中获胜（战斗规则）→ 获得古人赠送的酿酒配方（数据+规则）→ 解锁新的剧情对话（剧情）

在《酒魂》项目中记录剧情触发条件

打开 04_story_design.md，补充「剧情触发条件」表格：

## 剧情触发条件（代码层面的判断）

| 剧情事件 | 触发条件（代码判断） | 后续影响 |
|:---|:---|:---|
| 邂逅李白 | `brew_count >= 1`（酿过一次酒）且 `winery_level >= 2` | 李白NPC出现在酒坊门口 |
| 李白好感度60 | `li_bai_favorability >= 60` | 解锁「诗剑酒魂技」技能书 |
| 第一次释放酒魂技 | `drunk_level >= 0.8` 且 `skill_cast_count == 0` | 触发李白对话「好酒量！」 |

这些条件会在第 18~20 章（交互 / 对话 / 任务系统）用到。

3.3 从设计到代码：翻译的艺术

3.3.1 创意在纸上总是完美的

在你想象《酒魂》的时候，一切都那么美好。但一旦开始实现，你就会发现：创意的完美，需要大量的执行来支撑。

具体来说：

• 「精妙的酿酒系统」需要数十张数据表、复杂的概率算法和大量的UI开发
• 「鲜活的历史人物」需要大量的对话文本、动画、语音
• 「充满诗意的战斗」需要流畅的碰撞检测、敌人AI、技能系统，和几百次调参

3.3.2 「好的设计」和「能做出来的设计」

对于独立开发者，最重要的设计原则不是「最好的设计」，而是「在当前资源约束下，能做出来的最好设计」。

以下是《酒魂》的务实决策：

在《酒魂》项目中记录MVP范围

打开 02_rules_design.md，在末尾添加「MVP版本范围」：

## MVP版本范围（第一版必须完成）

### 战斗系统
- [ ] 投壶核心玩法（蓄力+抛物线+命中，第 7 章）
- [ ] 3 种敌人类型（近战、远程、巡逻，第 11 章）
- [ ] 醉意系统基础版（0~1 数值，影响攻击力和移速，第 12 章）
- [ ] 1 种酒魂技（醉意 ≥0.8 时释放，第 13 章）

### 酿造系统
- [ ] 3种基础配方（第 15 章）
- [ ] 品质计算（F~S级，第 16 章）
- [ ] 随机词缀（简单版：5个词缀随机抽取，第 16 章）
- [ ] 陈化系统基础版（第 17 章）

### 剧情
- [ ] 开场（继承酒坊，第 18 章）
- [ ] 邂逅李白（第 18 章）
- [ ] 李白好感度达到60的剧情（第 18 章）

### 暂不实现（放到后续版本）
- [ ] 全语音对话
- [ ] 复杂君臣佐使配伍系统
- [ ] 程序化地图生成
- [ ] 多语言支持

3.3.3 翻译的艺术：三步从创意到代码

把一个创意变成能跑的代码，中间隔着三次「翻译」：

1. 设计语言 → 规则语言：「喝酒让人变强但变飘」→「醉意 +0.2/口，≥0.8 时攻击 ×1.5、移速 ×0.7」——把形容词变成数字；
2. 规则语言 → 代码语言：「醉意 ≥0.8 攻击 ×1.5」→ if drunk_level >= 0.8: return 1.5——把数字变成逻辑；
3. 代码语言 → 可玩体验：运行、调参、看手感——把逻辑变成乐趣。

第 1 步发生在你的设计文档里，第 2 步发生在编辑器里，第 3 步发生在运行窗口里。下一节（3.4）我们就完整走一遍这三步。 另外，你在 2.2.2 节用「逐行注释阅读法」读过的那段醉意值管理器代码，正是这三步翻译的产物——读完 3.4 再回看它，检验自己能否从代码反推出设计文档。

3.4 从设计到代码：一个完整的翻译案例（醉意值→攻击力）

这是本章最重要的一节。它演示了「设计文档里的文字」如何变成「Godot里的代码」。

你在 2.2.2 节已经用「逐行注释阅读法」读过一段醉意值管理器代码——那是怎么读；本节演示的是反方向：这段代码当初是怎么从设计文档一步步「翻译」出来的。

案例：醉意值影响攻击力

步骤1：设计语言（你写在文档里的）

「玩家喝酒越多，醉意值越高，攻击力越强。但醉意太高时，移动会变得不稳定（打滑）。」

步骤2：翻译成规则（你补充在文档里的）

• 醉意值范围 0.0 ~ 1.0
• 按E键喝酒，醉意值+0.2，上限1.0
• 醉意值每秒自然消退0.02
• 醉意值 ≥ 0.5 时，攻击力 × 1.2
• 醉意值 ≥ 0.8 时，攻击力 × 1.5，且移速 × 0.7，移动时增加「打滑」惯性

（其中「≥0.5 时 ×1.2」这一档是本案例为演示多档位而增设的简化值；正式的醉意参数以 3.2.3 节写进 01_data_design.md 的调节表为准。）

步骤3：翻译成代码（你在Godot里写的）

# 挂在玩家身上的脚本
extends CharacterBody2D

# 数据设计（对应 01_data_design.md）
var drunk_level: float = 0.0

# 规则设计（对应 02_rules_design.md）
func drink():
    drunk_level = min(1.0, drunk_level + 0.2)

func get_attack_multiplier() -> float:
    if drunk_level >= 0.8:
        return 1.5
    elif drunk_level >= 0.5:
        return 1.2
    return 1.0

func get_speed_multiplier() -> float:
    return 0.7 if drunk_level >= 0.8 else 1.0

func _process(delta):
    # 醉意自然消退
    drunk_level = max(0.0, drunk_level - 0.02 * delta)

先别急着敲代码——先看懂这次「翻译」

上面的代码不长，但它的每一段都能在设计文档里找到出处：

代码	设计文档出处
drunk_level: float = 0.0	01_data_design.md：醉意值范围 0.0~1.0
drink() 里的 + 0.2	01/02 文档：每口酒增加醉意 0.2
_process() 里的 0.02 * delta	01 文档：醉意自然消退 0.02/秒
get_attack_multiplier() 的 1.2 / 1.5	02_rules_design.md：醉意阈值档位
get_speed_multiplier() 的 0.7	02 文档：醉意 ≥0.8 移速惩罚

这段代码现在先不敲。 它的三个前置依赖此刻都还不存在：

依赖	现在有吗	什么时候有
《酒魂》Godot 项目	还没有	第 4 章创建
玩家角色 Player.tscn	还没有	第 5 章创建
E 键输入映射	还没有	第 12 章实现醉意系统时配置

它的真正落地路线是：第 5 章把这些逻辑搬进 player.gd → 第 7 章醉意值上交 GameManager 统一管理（切换场景不丢失）→ 第 12 章做成带 UI 反馈的完整醉意系统。本节的任务只是跑通「设计文档 → 代码」的翻译；等你到第 5 章真正写下 player.gd 时会发现——你已经知道每一行为什么存在了。

想现在就验证翻译是否正确？把代码临时粘到一个空 Node 的脚本里，用 print(drunk_level) 看数值变化（就像 2.2.2 节的动手练习那样），验证完删掉即可，不必保留文件。

3.5 三条设计法则：有意义的选择、可读性优先、失败也要有趣

法则一：有意义的选择

检查方法： 你设计的每一个选择，闭上眼睛选A。你会后悔没选B吗？不会？那这个选择删掉。

《酒魂》的选择设计：

为《酒魂》添加一个「有意义的选择」

在 02_rules_design.md 末尾，写下你为《酒魂》设计的一个新选择。要求：两个选项各有优劣，玩家会纠结。

示例：战斗中是先打败小兵（积累醉意）还是直接打Boss（醉意不足，伤害不够）？

法则二：可读性优先

检查方法： 把你设计的系统，用一句话说给朋友听。他点点头，你就过了。他皱眉头，你回去改。

《酒魂》各系统的一句话版：

• 酿造：选配方→加材料→按按钮，出酒
• 醉意：喝越多越厉害，但越不稳
• 好感度：送酒给古人，他喜欢你就会教你新东西

动手练习：用一句话描述《酒魂》的醉意系统

写下来。如果超过20个字，简化它。

法则三：失败也要有趣

检查方法： 玩家失败后，是沮丧地说「烦死了」，还是兴奋地说「有意思，再来一次」？

《酒魂》的失败设计：

为《酒魂》设计一个「有趣的失败」

在 05_experience_design.md 末尾，写下你对「酿造失败」的具体设计。要求：失败后玩家不是空手而归，而是得到一个「意外变体」。

示例：想酿「竹叶青」，失败后得到「苦竹酒」——效果是回血少，但增加暴击率。

3.6 本章小结：《酒魂》的设计蓝图

本章你完成了以下文件（都在 docs/ 文件夹下）：

这些文件就是《酒魂》的施工图纸。 后续每一章开始前，你都可以回到这些文档，确认「这个功能的设计依据是什么」。

注意：本章没有产出任何 .gd 脚本文件。 3.4 节的醉意代码是一份「翻译演练」——它真正的落地在第 5 章（并入 player.gd）、第 7 章（上交 GameManager）和第 12 章（完整醉意系统）。本章的全部交付物是上面 6 份 Markdown 文档（完整范例见附录 E）。

最终检查：

打开你的 docs/ 文件夹，确认：

• 00_gdd.md 加 5 份维度文档共 6 个文件齐全
• 每份文档末尾都完成了本章的动手任务（一致性清单、醉意参数表、剧情触发表、MVP 范围、有意义的选择、失败变体设计）
• 你能不看文档，用一句话说出《酒魂》的核心循环（对照 3.2.1 的 GDD 检查）

下一章： 第4章 创建《酒魂》项目与场景结构——动手之前，先把工程搭好

延伸阅读

• 《游戏设计艺术》（Jesse Schell）——五维框架的灵感来源，书中一个个「透镜」就是一套设计自查清单，用法与 3.5 节的三条法则相同。重点阅读第 1~5 章。
• 《游戏编程模式》（Robert Nystrom，中文版免费在线阅读）——理解「设计模式是解决什么问题的」；本书**附录 A「设计模式实战手册」**会系统用到书中的知识点（覆盖第 10 / 11 / 16 / 17 / 19 / 20 章）。