Unity3D GameObject代码结构

在学习和教授MVC和类似方法的同时，我发现在设计游戏架构时，通常必须更加灵活。团结一致，我通常采取以下方法。

我将创建一些GameObjects来容纳必要的全局逻辑。这将是诸如总体状态机，联网以及有时是控制输入之类的事情。如果场景之间需要保留任何内容，它将转到此处。每个对象通常具有一个用于游戏逻辑的组件脚本和一个用于临时/调试功能的组件脚本，这些脚本在不需要时会被关闭或删除。

如果项目具有固定的级别，则将使每个级别成为一个场景，并在场景中存储级别布局和其他级别特定的信息。如果我要执行更具过程性的项目，则将使用组件脚本创建一个“ LevelGenerator”对象，该脚本将在运行时生成并填充该级别。

如果我建立的系统中有许多主要是独立的特工（例如敌方生物），我会尽量使每个特工的游戏逻辑和必要的状态信息在层次结构中尽可能接近。例如，代理的位置和旋转将存储在其变换中。我可能会在特工的GameObject的组件脚本中存储特工的健康，弹药，速度和当前状态效果以及移动，射击，治愈和死亡的功能。

尽管还有许多其他可行的方法，但出于某些原因，我还是喜欢这种方法：

它使我不必在中央脚本中手动管理大量数据访问。如果我想知道所有怪物在哪里，我可以保留游戏对象列表，而不必使用自定义数据类型。

代理销毁后，所有本地数据都将随之消失。（没有复杂的功能来清理死掉的代理。）

从游戏逻辑的角度（在我通常从事的项目上），通常每个代理都“了解”自己而不是其他任何人都是有意义的。

必要时，我仍然可以使用所有OO好东西，例如多态等。

这个回应可能比一般的最佳做法更多地说明了我如何处理游戏设计和软件架构，但它可能很有用。

关于Unity中封装的一则说明。您添加到游戏对象中的每个组件脚本都有一些开销。如果您的场景中有几十个座席，那么这并不是什么大不了的事情，我建议您尝试将内容保持为OO和模块化。如果您要构建一个具有成百上千个活动代理的系统，则将每个代理的组件从两个减少到一个可能意味着节省了大量的框架时间。