游戏开发中有必要做到逻辑与显示分离吗？如果有,如何做呢？

我觉得逻辑也会根据具体内容的不同而分成很多层。不一定是明确的“逻辑一部分显示一部分”，而是每一层有每一层的逻辑。哪怕是显示层，也会有一些轻量级的逻辑，比如多帧动画播放的控制、常用特效的shader（哪怕它们涉及到“攻击判定”之类偏向逻辑的概念）、三维人物的蒙皮动画。

显示的东西和逻辑分离确实是个好方向，但具体要分离到哪一步却值得每个游戏各自讨论。因为纯粹的显示是不存在的。抽象本身不能带来有效信息，如果觉得某些画面要素和逻辑要素强烈关联，那么把它们合起来，哪怕是纯程序员的角度，也是一种合理设计。

另一个小要点是有些数据可能需要序列化（存档、中断），这些就需要用单独的逻辑对象来处理；相反能包含在画面中的，往往是不需要保存状态、不需要序列化的东西；哪怕需要保存，也可以通过其他数据间接恢复。

基本上已经只能称作游戏图形库的一些“游戏引擎”是可以这么做的

优点是非常方便测试和优化，而复用和维护相对没什么关系是靠代码质量来决定的。

简单来说，就是把一个时间分片，把每一帧划分为逻辑部分和绘图部分，并且严格计算这两个部分的时间

如果游戏的逻辑部分，和绘图渲染部分，时间长度较短或者比较平均，用这种方法是很合适的

缺点是一旦出现一些复杂的逻辑操作，就要防止这个操作阻塞绘图帧的进行

另外，显示对象内挂逻辑理论上没有问题，但是在显示对象过多的情况下会及其影响性能。就继续扣优化

最后现代引擎已经帮你解决这个问题了，遵循引擎推荐的代码风格就不会有太大问题

听完描述给我一种你也没写过什么复杂点的web应用的感觉

要是写复杂点的单页应用也不会这么想啊

能严格mvc单分一层就完事了的 大概得十几年前的web应用

其实就一句话：

他们这么做是为的就是照顾到不懂代码，甚至不懂计算机工作原理的人。

在他们看来一个游戏中的物体包括形状，材质其实和他们的血量，魔法值一样都是属于某个物体的属性，它们就是一体的。

并非说哪个对，哪个错。前者更方便维护是以工程角度来看的好处。但后者更方便非专业人员理解是从设计角度出发。

顺便补充一下，我以前自己用SFML库做过一个2D小游戏。出于和题主一样的考虑我定义了一个人物的类只包含逻辑功能，然后他的成员中引用一个sprite实例来实现显示功能。后来拿到老外的论坛上，很多大佬都纠结我“为什么不把sprite继承出来，建立一个人物子类”。显然逻辑和显示不分离是一种很常见的设计方式。

显示用于逻辑验证 OwO
属于外围
不推荐外围影响核心逻辑