bilibili: 这个视频分享者，做《Thronefall》和《Will You Snail》的，有实际的项目经验，讲的都是一些实战中总结出来的东西。我觉得他的思路挺清楚的，模块化：从别的项目里“偷”代码他提到一个很重要的观点，就是代码模块的可复用性。想象一下，你写了一个“物体生成器”，用它来生成敌人。如果你把它写成了一个只能用在你这一个地方的专用脚本，那以后换个项目想用就费劲了。更好的做法是，把它设计成一个通用的“生成器”模块。这样，以后不管是生成敌人、生成道具还是生成粒子效果，你都可以直接拿过来用，稍微配置一下就完事。当然，这个道理可能很多人在学校或者书里都听过，但真正做到的人不多。因为这会带来一个现实问题：系统之间怎么通信。它们都是独立的模块，彼此不知道对方的存在，怎么协同工作呢？他的解决办法是，用“胶水”代码来粘合。就是额外写一些你很清楚“绝对不复用”的专用脚本，它的唯一职责就是连接各个独立的系统。比如，一个“玩家控制器”脚本，它会把“移动系统”和“动画系统”的输出连接起来，让角色动起来并且播放对应动画。这个脚本很“脏”，因为它的逻辑很具体，但它保证了底层那些模块的干净和独立。这么一来，你的项目里大概有70%的代码是那种可拎出来单看的“积木”，剩下30%是“胶水”。这么做的好处是显而易见的：每个模块都很简单，易于理解和调试。出了Bug，定位起来快多了，不用在代码的海洋里捞针。可以攒一个自己的“组件库” 。这个项目里攒下来的东西，下个项目可以直接用，开发速度会越来越快。项目的整体复杂性被大幅降低。系统之间不要直接互相引用，这种纠缠越少，项目越健康，真的。用高墙把数据和代码隔开这一块，我的个人感觉是，很多新手容易忽略的。这里的“数据”指的是那些不变的、用来配置玩法的东西，比如单位的血量、攻击力、移动速度、文本翻译等等。可变的数据，比如单位当前的位置、朝向，则放在代码里。核心思想是，在数据和代码之间立一堵高墙。代码只负责逻辑，而所有需要调整的数值，都应该集中、清晰地存放在一个统一的地方，比如一个巨大的电子表格、一个Scriptable Object数据库，或者其他的数据容器。这样做的好处太明显了：设计师（甚至是你自己）修改数据会变得非常开心。所有平衡性数值一目了然，改起来不用满项目地找，大大提升了迭代速度和手感调整的效率。为将来的内容扩展和Mod支持打下极好的基础。别人想给你的游戏添加新内容，只需要增加数据记录，而不需要去动代码。数据管理变得前所未有的轻松。所有东西都在一个地方，搜索、对比、修改都极其方便。他还提出了一个更极致的做法：先设计数据库，再围绕它来构建游戏系统。这个思路我一开始也觉得挺吃惊的，但仔细一想，确实有道理。这样一来，数据结构的确定性被提到了最高，就不会出现后期为了放置一个数据而大改代码的窘境。时间，这团逃不开的意大利面游戏里的每个系统，比如移动、攻击、AI决策，都得按一定的时间间隔去执行更新。如果不加以控制，它们的执行顺序往往是引擎默认的、无法预期的乱七八糟的顺序。这很容易导致逻辑错乱和奇怪的Bug。一个很实用的办法是：让一个核心管理器脚本，按你设定的优先级顺序，去 Update() 各个系统。这样，所有系统的执行顺序就是确定的、可控的。类似的控制方法有很多，你要找到适合自己项目的那一种。对于复杂项目来说，控制住这团“时间面条”，比什么都重要。模拟与视图，是时候把逻辑和美术分开了这个技能我认为到了项目后期才会真正觉得重要，但早点明白会少吃很多苦。简单说，就是把游戏的核心模拟（数据、状态、事件）和视觉呈现（动画、特效、渲染）彻底分开。模拟层就是游戏的“数学模型”，它只关心世界当前是什么样的，例如角色位置、角色血量、有几个敌人、谁攻击了谁。它完全不关心这些数据是怎么被画到屏幕上的。视图层则负责“观察”模拟层，并把它变成我们能看到的画面。它会去读取模拟层里的数据，然后调用相应的动画、特效去展示出来。对视图层来说，模拟层就是一个实时的数据库。这么做的巨大的好处是：项目被拆成了两个更小的、更易于管理的部分。逻辑是逻辑，美术是美术，泾渭分明。更换或修改其中一个部分，对另一个的影响微乎其微。你想把主角从方块模型换成超精细的3D模型，只需要改动视图层，模拟层根本不知道发生了什么。这极大提升了开发灵活性和后期迭代的安全性。方便团队协作。程序员可以只专注于模拟层的逻辑，美术师也可以只管视图层的表现，互不干扰。最终建议：条理清晰，适合的才是最好的说到底，这种架构是比较进阶的思路。它是一个很好的参考目标，但未必适合所有项目。如果你是单人开发，项目体量也不大，用一点简单的管理器，甚至一些特定于引擎的蓝图脚本，只要能让你开心、开发效率高、项目不乱，那就足够了。 “能用就行”其实是第一位的。在保证这个底线的前提下，尽可能保持条理清晰，无论用什么方式，都会让你的游戏开发之路走得更顺一些。每位开发者的有效方法都需要自己不断尝试和摸索出来。我只能分享我看到的、和我理解的方向，希望能给你一些启发。如果你对另一个相关视频感兴趣，可以点进我们的频道看看，保不准有别的收获。下个视频见。

教程分享：告别屎山代码！独立游戏开发者必看的架构设计指南 | 模块化 / 可复用 / 高效

明明

bilibili:

这个视频分享者，做《Thronefall》和《Will You Snail》的，有实际的项目经验，讲的都是一些实战中总结出来的东西。我觉得他的思路挺清楚的，

模块化：从别的项目里“偷”代码

他提到一个很重要的观点，就是代码模块的可复用性。想象一下，你写了一个“物体生成器”，用它来生成敌人。如果你把它写成了一个只能用在你这一个地方的专用脚本，那以后换个项目想用就费劲了。更好的做法是，把它设计成一个通用的“生成器”模块。这样，以后不管是生成敌人、生成道具还是生成粒子效果，你都可以直接拿过来用，稍微配置一下就完事。

当然，这个道理可能很多人在学校或者书里都听过，但真正做到的人不多。因为这会带来一个现实问题：系统之间怎么通信。它们都是独立的模块，彼此不知道对方的存在，怎么协同工作呢？

他的解决办法是，用“胶水”代码来粘合。就是额外写一些你很清楚“绝对不复用”的专用脚本，它的唯一职责就是连接各个独立的系统。比如，一个“玩家控制器”脚本，它会把“移动系统”和“动画系统”的输出连接起来，让角色动起来并且播放对应动画。这个脚本很“脏”，因为它的逻辑很具体，但它保证了底层那些模块的干净和独立。

这么一来，你的项目里大概有70%的代码是那种可拎出来单看的“积木”，剩下30%是“胶水”。这么做的好处是显而易见的：

每个模块都很简单，易于理解和调试。 出了Bug，定位起来快多了，不用在代码的海洋里捞针。
可以攒一个自己的“组件库”。这个项目里攒下来的东西，下个项目可以直接用，开发速度会越来越快。
项目的整体复杂性被大幅降低。 系统之间不要直接互相引用，这种纠缠越少，项目越健康，真的。

用高墙把数据和代码隔开

这一块，我的个人感觉是，很多新手容易忽略的。这里的“数据”指的是那些不变的、用来配置玩法的东西，比如单位的血量、攻击力、移动速度、文本翻译等等。可变的数据，比如单位当前的位置、朝向，则放在代码里。

核心思想是，在数据和代码之间立一堵高墙。代码只负责逻辑，而所有需要调整的数值，都应该集中、清晰地存放在一个统一的地方，比如一个巨大的电子表格、一个Scriptable Object数据库，或者其他的数据容器。

这样做的好处太明显了：

设计师（甚至是你自己）修改数据会变得非常开心。 所有平衡性数值一目了然，改起来不用满项目地找，大大提升了迭代速度和手感调整的效率。
为将来的内容扩展和Mod支持打下极好的基础。 别人想给你的游戏添加新内容，只需要增加数据记录，而不需要去动代码。
数据管理变得前所未有的轻松。 所有东西都在一个地方，搜索、对比、修改都极其方便。

他还提出了一个更极致的做法：先设计数据库，再围绕它来构建游戏系统。这个思路我一开始也觉得挺吃惊的，但仔细一想，确实有道理。这样一来，数据结构的确定性被提到了最高，就不会出现后期为了放置一个数据而大改代码的窘境。

时间，这团逃不开的意大利面

游戏里的每个系统，比如移动、攻击、AI决策，都得按一定的时间间隔去执行更新。如果不加以控制，它们的执行顺序往往是引擎默认的、无法预期的乱七八糟的顺序。这很容易导致逻辑错乱和奇怪的Bug。

一个很实用的办法是：让一个核心管理器脚本，按你设定的优先级顺序，去Update()各个系统。这样，所有系统的执行顺序就是确定的、可控的。类似的控制方法有很多，你要找到适合自己项目的那一种。对于复杂项目来说，控制住这团“时间面条”，比什么都重要。

模拟与视图，是时候把逻辑和美术分开了

这个技能我认为到了项目后期才会真正觉得重要，但早点明白会少吃很多苦。简单说，就是把游戏的核心模拟（数据、状态、事件）和视觉呈现（动画、特效、渲染）彻底分开。

模拟层就是游戏的“数学模型”，它只关心世界当前是什么样的，例如角色位置、角色血量、有几个敌人、谁攻击了谁。它完全不关心这些数据是怎么被画到屏幕上的。

视图层则负责“观察”模拟层，并把它变成我们能看到的画面。它会去读取模拟层里的数据，然后调用相应的动画、特效去展示出来。对视图层来说，模拟层就是一个实时的数据库。

这么做的巨大的好处是：

项目被拆成了两个更小的、更易于管理的部分。 逻辑是逻辑，美术是美术，泾渭分明。
更换或修改其中一个部分，对另一个的影响微乎其微。 你想把主角从方块模型换成超精细的3D模型，只需要改动视图层，模拟层根本不知道发生了什么。这极大提升了开发灵活性和后期迭代的安全性。
方便团队协作。 程序员可以只专注于模拟层的逻辑，美术师也可以只管视图层的表现，互不干扰。

最终建议：条理清晰，适合的才是最好的

说到底，这种架构是比较进阶的思路。它是一个很好的参考目标，但未必适合所有项目。如果你是单人开发，项目体量也不大，用一点简单的管理器，甚至一些特定于引擎的蓝图脚本，只要能让你开心、开发效率高、项目不乱，那就足够了。

“能用就行”其实是第一位的。在保证这个底线的前提下，尽可能保持条理清晰，无论用什么方式，都会让你的游戏开发之路走得更顺一些。

每位开发者的有效方法都需要自己不断尝试和摸索出来。我只能分享我看到的、和我理解的方向，希望能给你一些启发。如果你对另一个相关视频感兴趣，可以点进我们的频道看看，保不准有别的收获。下个视频见。