MV分离

1、界面和逻辑分离

逻辑和界面分离，是游戏开发最核心的思路。

简单的说，游戏的逻辑类，依赖于你的游戏框架，而并非unity。

什么是游戏框架呢？也就是具备独立的生命周期的框架。你的游戏逻辑是应该完全依赖于自己的游戏框架。这样，你只需要改动一下框架接口，就可以进行代码移植。

UI最简单就是MVC模式，MVC是一套相对来说简单的代码分离的方案。就个人感觉而言。其实如果不考虑重构，多数情况下，V依赖于M也是可以的。不需要完全分离。

所以一般游戏应该分为逻辑层、视图层、数据层。

数据层通常指基本的配置数据，玩家的游戏数据。

逻辑层是游戏的核心逻辑，是演变数据的逻辑

视图层是展示游戏数据的界面。同时也具备与逻辑交互的接口，以便玩家控制游戏。

V的一个问题是，如果数据变化了，UI应该怎么刷新。

刷新UI的方法有两种，

1、对于进度条这类，变化很频繁的，由UI定时轮询

2、对于刷新次数不频繁的，比如给背包中添加一个道具。此时推荐通过事件传递。

做两个简单的例子。2d和3d。rpg

在游戏引擎中，如果需要让go产生变化，相应的需要为go绑定与游戏逻辑耦合的脚本。这些脚本会控制go产生变化，从而让玩家能够随时掌握数据的变化（即时反馈）。

在物理模拟上，也有两种方案，如果是简单的位置判断，AABB也可以实现，那么完全不用给对象添加碰撞体，在自定义的简单物理系统中进行模拟，效率更高。但是对于fps这种，需要相对完备的碰撞体的游戏，则需要使用游戏自带的物理系统进行模拟，而发射出来的子弹，也是一个实实在在具备有游戏逻辑的实体。这些实体通过相互的碰撞事件来驱动游戏逻辑。

而各种特效，只是特效，不应该具备任何逻辑。

也就是说，如何做碰撞判断可以交给引擎。但是如何处理碰撞产生的效果，有游戏逻辑进行处理。游戏逻辑不应依赖于视图，也就是游戏引擎部分，理论上，游戏视图展示的效果无论多复杂，他都不能影响游戏逻辑的复杂度。也就是说，视图的设计不应该影响游戏逻辑的设计。

2、数据驱动

保存数据的方案有很多种，在unity能够支持c#热更后，甚至有将配表数据保存为C#代码，从而实现而小的内存，更快的加载。

但使用数据驱动的目的是，在尽量少改动代码的情况，实现更多的游戏内容。实现一个数据驱动的关卡，等于实现了无数个数据驱动的关卡。

因此，数据驱动并不意外着不需要增加代码。