当前位置:游戏 > 综合资讯

《守望先锋》:我们是如何做架构设计与网络同步的?

来源:kevinan 作者:Tim Ford 发布时间:2017年09月12日

免责声明:火星网文章来源于作者原创或整理自互联网,仅为提供更多信息,不代表火星时代同意其观点或描述,版权归原作者所有,如需转载,请联系原作者并注明出处,如涉及作品内容、版权或其他问题,请及时与我们联系,我们将在第一时间予以更改或删除,感谢您的理解和包容!

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

哈喽,大家好,这次的分享是关于《守望先锋》游戏架构设计和网络部分。我是Tim Ford,是暴雪公司《守望先锋》开发团队老大。自从2013年夏季项目启动以来就在这个团队了。在那之前,我在《Titan》项目组,不过这次分享跟Titan没有半毛钱关系。

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

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

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

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

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

ECS架构概述

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

这听起来可能挺让人惊讶的,因为组件没有函数而System没有任何字段。

ECS引擎用到的System和组件

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

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

绝大多数的重要System都关注了不止一个组件,如你所见,这里的Transform组件就被很多System用到。

1 2 3 4 ... 11 下一页