右边是不同实体拥有的组件

2018-11-09 23:31| 发布者: | 查看: |

  本文为GDC 2017上的演讲《守望先锋架构设计与网络同步》,演讲人为暴雪《守望先锋》开发团队首席工程师Tim Ford。在演讲中,Tim Ford带来了大量技术干货,既分享了能够降低代码库复杂度的“实体组件系统”架构,还从“网络同步”这个角度来说明如何管理复杂性。

  前不久kevinan编译了该文章并首发于腾讯GAD,游戏葡萄已获转载授权。

  哈喽,大家好,这次的分享是关于《守望先锋》游戏架构设计和网络部分。老规矩,手机调成静音;离开时记得填写调查问卷;换下半藏,赶紧推车!(众笑)

  我是Tim Ford,是暴雪公司《守望先锋》开发团队老大。自从2013年夏季项目启动以来就在这个团队了。在那之前,我在《Titan》项目组,不过这次分享跟Titan没有半毛钱关系。(众笑)

  这次分享的一些技术,是用来降低不停增长的代码库的复杂度(译注,代码复杂度的概念需要读者自行查阅)。为了达到这个目的我们遵循了一套严谨的架构。最后会通过讨论网络同步(netcode)这个本质很复杂的问题,来说明具体如何管理复杂性。

  《守望先锋》是一个近未来世界观的在线团队英雄射击游戏,它的主要特点是英雄的多样性, 每个英雄都有自己的独门绝技。

  《守望先锋》使用了一个叫做“实体组件系统”的架构,接下来我会简称它为ECS。

  ECS不同于一些现成引擎中很流行的那种组件模型,而且与90年代后期到21世纪早期的经典Actor模式区别更大。我们团队对这些架构都有多年的经验,所以我们选择用ECS有点是“这山望着那山高”的意味。不过我们事先制作了一个原型,所以这个决定并不是一时冲动。

  开发了3年多以后,我们才发现,原来ECS架构可以管理快速增长的代码复杂性。虽然我很乐意分享ECS的优点,但是要知道,我今天所讲的一切其实都是事后诸葛亮 。

  ECS架构看起来就是这样子的。先有个World,它是系统(译注,这里的系统指的是ECS中的S,不是一般意义上的系统,为了方便阅读,下文统称System)和实体(Entity)的集合。而实体就是一个ID,这个ID对应了组件(Component)的集合。组件用来存储游戏状态并且没有任何的行为(Behavior)。System有行为但是没有状态。

  图的左手边是以轮询顺序排列的System列表,右边是不同实体拥有的组件。在左边选择不同的System以后,就像弹钢琴一样,所有对应的组件会在右边高亮显示,我们管这叫组件元组(译注,元组tuple,从后文来看,主要作用就是可以调用Sibling函数来获取同一个元组内的组件,有点虚拟分组的意思)。

  System遍历检查所有元组,并在其状态(State)上执行一些操作(也就是行为Behavior)。记住组件不包含任何函数,它的状态都是裸存储的。

  绝大多数的重要System都关注了不止一个组件,如你所。

<
>
相关文章
 
QQ在线咨询
售前咨询热线
400-800-8888
售后服务热线
400-800-8888
返回顶部