浅谈《守望先锋》中的 ECS 构架
时间:2019-01-08 07:03 来源:百度新闻 作者:巧天工 点击:次
最近读了一篇《守望先锋》架构设计与网络同步。这是根据GDC 2017上的演讲Overwatch Gameplay Architecture and Netcode视频翻译而来的，所以并没有原文。由于是个一小时的演讲，不可能讲得面面俱到，所以理解起来有些困难，我反复读了三遍，然后把英文视频找来（订阅GDC Vault可以看，有版权）看了一遍，大致理解了ECS这个框架。写这篇Blog记录一下我对ECS的理解，结合我自己这些年做游戏开发的经验，可能并非等价于原演讲中的思想。 onent System(ECS)是一个gameplay层面的框架，它是建立在渲染引擎、物理引擎之上的，主要解决的问题是如何建立一个模型来处理游戏对象(Game Object)的更新操作。 传统的很多游戏引擎是基于面向对象来设计的，游戏中的东西都是对象，每个对象有一个叫做Update的方法，框架遍历所有的对象，依次调用其Update方法。有些引擎甚至定义了多种Update方法，在同一帧的不同时机去调用。 这么做其实是有极大的缺陷的，我相信很多做过游戏开发的程序都会有这种体会。因为游戏对象其实是由很多部分聚合而成，引擎的功能模块很多，不同的模块关注的部分往往互不相关。比如渲染模块并不关心网络连接、游戏业务处理不关心玩家的名字、用的什么模型。从自然意义上说，把游戏对象的属性聚合在一起成为一个对象是很自然的事情，对于这个对象的生命期管理也是最合理的方式。但对于不同的业务模块来说，针对聚合在一起的对象做处理，把处理方法绑定在对象身上就不那么自然了。这会导致模块的内聚性很差、模块间也会出现不必要的耦合。 我觉得守望先锋之所以要设计一个新的框架来解决这个问题，是因为他们面对的问题复杂度可能到了一个更高的程度：比如如何用预测技术做更准确的网络同步。网络同步只关心很少的对象属性，没必要在设计同步模块时牵扯过多不必要的东西。为了准确，需要让客户端和服务器跑同一套代码，而服务器并不需要做显示，所以要比较容易的去掉显示系统；客户端和服务器也不完全是同样的逻辑，需要共享一部分系统，而在另一部分上根据分别实现…… (责任编辑：波少) |
