我翻开知乎查看游戏架构浏览，这问题没有专门答案，歪歪斜斜的每页上都写着"MVC"，“MVVC”,"MVP"，“uFame架构”几个字。横竖想了半天，最后在一个倒影年华 博主下发现一个很好的回答：

框架是为了解决一个又一个在Web开发中所遇到的问题而诞生的。不同的框架，都是为了解决不同的问题，但是对于程序员而言，他们只是 jar包而已。框架的优缺点的评论，也完全取决于其对问题解决程度和解决方式的优雅性的评论。所以，千万不要为了学习框架而学习框架，而是要为了解决问题 而学习框架，这才是一个程序员的正确学习之道。

这段话适用于游戏开发。

游戏题材众多，要通用的一个架构搞定所有题材几乎不可能。但是游戏也是软件，有些常识性的东西可以通用的。个人认为相比于框架，更重要的是设计理念。

0.关注点分离原则

关注点分离是日常生活和生产中广泛使用的解决复杂问题的一种系统思维方法。大体思路是,先将复杂问题做合理的分解,再分别仔细研究问题的不同侧面(关注点),最后综合各方面的结果,合成整体的解决方案
许多游戏的对象都可以分为显示表现部分，逻辑处理部分，数据存储部分。

比如一个MOBA游戏的角色，就要把视觉相关的内容和核心逻辑给分离开。

角色表现部分：动画、模型显示、相关特效、UI等美术资源和控制模型动画播放，生命值血条变化等改变对象显示的部分代码。

核心逻辑部分：控制对象行为（移动、***、技能），控制对象数值变化（被击扣血、击杀获得金钱），处理业务逻辑部分。

数据存储部分：记录玩家自身属性、如***、血量、防御力等。

角色显示和逻辑分开的好处一是可以让我们的代码清晰，出了问题能直观的去相应的代码块去找问题，二是分离代码逻辑后，如果美术资源的更新，以及策划的更新不会影响到主要的业务逻辑代码，这就提高了游戏的可移植性。

/比如王者荣耀一个英雄有很多皮肤，不可能每一个皮肤都要去写一套逻辑代码，我们只要将显示部分替换/
而逻辑和数据分离的好处是可以代码复用减少耦合。

/比如我们游戏中有一个玩家和一个敌方小兵的对象，双方实际上数据是相似的，我们就可以用一个角色数据脚本存储双方数据，而不用写两遍代码在各自的逻辑里面。同时当双方都扣血的时候，UI血条控制脚本能直接去角色数据脚本中取资源/

1.开放封闭原则

开放封闭原则（OCP，Open Closed Principle）是所有面向对象原则的核心。软件设计本身所追求的目标就是封装变化、降低耦合，而开放封闭原则正是对这一目标的最直接体现。

开放封闭原则主要体现在两个方面：

对扩展开放，意味着有新的需求或变化时，可以对现有代码进行扩展，以适应新的情况。

对修改封闭，意味着类一旦设计完成，就可以独立完成其工作，而不要对类进行任何修改。

游戏开发中有很多的突发事件，经常会用到监听观察者模式。这种又叫做响应式编程的思想。

比如一款游戏从开发到发行对一个事件的处理是由简单到复杂的。比如游戏战斗结束，如果在战斗管理器里面写具体执行的逻辑代码，那么后期策划逐渐提出我们要在战斗结束的时候加入“镜头变化”，“加入UI变化”，加入“服务器数据请求”等需求的时候，避免我们每次都要修改已经完成的功能，我们就将战斗结束作为一个事件发送，哪个系统关心这个事件就在各自的逻辑代码函数注册到这个事件中。

这种编程方式广泛用在游戏各个功能块中，比如场景加载模块，当场景加载后调用加载完成事件，谁需要在加载完成后处理什么事件逻辑，自己就去注册调用就好了。

2.不信任原则

这个是最近看腾讯云技术社区发表的文章后总结出来的。深有感触。
说的很好，游戏编程就像扫雷，你一不小心就会在某一步出错，游戏直接Over掉。

所以我们的编程应该步步为营，一个功能能再细化操作的就细化出来，比如一个UI管理器，就得处理UI的加载、创建、设置类型、设置层级、显示、处理逻辑、关闭或删除等功能。因为当后期做优化或者解决冲突，其中的每一步都可能是一个关键问题点。

直接利用引擎实现的部分也需要有一定的封装，你会看到很多游戏源码里面部分类都自己有一个Base基类。

即使这样，以上原则也有部分游戏开发不适应，各位看官还是以自身项目情况出发巧用设计方法。

很多相关框架的答案都用了各种专业的词汇来形容这个框架是多么的牛逼，多么的厉害。但是一般学了几年程序的朋友都能摸索出来自己的框架，不会去主动去问常用框架的问题（一般想了解的话自己就去各种搜索了解了，互联网就是技术人员的后盾嘛）。

而一般问这个问题的基本都是初学者，初学者听到答案后去各种看框架，看到中间后发现越看越看不懂。学具体写法不如学理念，这个东西是永远不会过时的。

对于初学者来说代码量太少了是一个大问题，自己还没有做到一定复杂度的系统时是感受不到框架的作用的。就如同房间里面什么东西都没有，你怎么做物品分类呢？所以先加油去写功B能U代G码吧，然后反复的重构你们会创造属于自己的框架。

我翻开知乎查看游戏架构浏览，这问题没有专门答案，歪歪斜斜的每页上都写着"MVC"，“MVVC”,"MVP"，“uFame架构”几个字。横竖想了半天，最后在一个倒影年华 博主下发现一个很好的回答：

框架是为了解决一个又一个在Web开发中所遇到的问题而诞生的。不同的框架，都是为了解决不同的问题，但是对于程序员而言，他们只是 jar包而已。框架的优缺点的评论，也完全取决于其对问题解决程度和解决方式的优雅性的评论。所以，千万不要为了学习框架而学习框架，而是要为了解决问题 而学习框架，这才是一个程序员的正确学习之道。

这段话适用于游戏开发。

游戏题材众多，要通用的一个架构搞定所有题材几乎不可能。但是游戏也是软件，有些常识性的东西可以通用的。个人认为相比于框架，更重要的是设计理念。