贴吧用户_0CU1WM3 按时阿斯顿9
关注数: 2 粉丝数: 25 发帖数: 4,782 关注贴吧数: 1
星际公民的动态经济和宇宙模拟 Tony与他的团队在今年花了大量时间来充实动态经济/宇宙模拟(Quantuam)的内部基础架构,他们的工作包括: · 增加从专用游戏服务器(Dedicated Game Servers,DGS)到Quantum的数据流量。DGS是你的客户端所连接的服务器,可以处理玩家每一刻的行为模拟,并最终将它们结合在一起。它们负责将所有玩家的状态以比自身模拟刷新率(tick rate)更慢的刷新率上传到整体的宇宙模拟中(Quantum不需要每秒30帧,因为它是更大范围的情景模拟)。 · 连接各种游戏服务,特指诸如商店、货物、资源、遭遇(概率量,AI生成),以及服务信标等任何DGS用来查询宇宙的全局状态的服务。Quantum就是用这些服务将宇宙状态(也即是你们所说的动态经济)传达给各个游戏服务器。这样做是为了不让Quantum过载。每个服务都将自己所负责的部分从Quantum(只负责模拟一个单独的宇宙)那儿缓存下来并更新全局状态(比如商品的价格),然后可以当各个DGS查询时共享给它们。这样做使我们能够增加DGS的数量,同时不必担心会让单一的宇宙模拟过载。 · 从后端数据库,比如永久数据库(即将改成iCache)中读取状态以跟踪玩家的状态和资产 · 改进Quanta(指一组AI在宇宙模拟中的表示形式)的能力,用他们的特质和专精的技能来驱动他们的行为和工作。 · 改进星图和玩家分析,以便全面了解玩家的活动(旅行、战斗、购物等)。 去年在公民控上的演示展示了我们计划采用的高级模拟方法,但让玩家能感受到一个所有玩家(不仅仅是一个实例中50个玩家)都共享的动态宇宙所带来变化所需要的“管道”都还没有铺设,因此公民控之后的很多工作都是将其连接回游戏玩法的必要步骤,只有这样人们才能看到动态宇宙所带来的那些有因果关系的变化。
星际公民的动态经济和宇宙模拟 Tony与他的团队在今年花了大量时间来充实动态经济/宇宙模拟(Quantuam)的内部基础架构,他们的工作包括: · 增加从专用游戏服务器(Dedicated Game Servers,DGS)到Quantum的数据流量。DGS是你的客户端所连接的服务器,可以处理玩家每一刻的行为模拟,并最终将它们结合在一起。它们负责将所有玩家的状态以比自身模拟刷新率(tick rate)更慢的刷新率上传到整体的宇宙模拟中(Quantum不需要每秒30帧,因为它是更大范围的情景模拟)。 · 连接各种游戏服务,特指诸如商店、货物、资源、遭遇(概率量,AI生成),以及服务信标等任何DGS用来查询宇宙的全局状态的服务。Quantum就是用这些服务将宇宙状态(也即是你们所说的动态经济)传达给各个游戏服务器。这样做是为了不让Quantum过载。每个服务都将自己所负责的部分从Quantum(只负责模拟一个单独的宇宙)那儿缓存下来并更新全局状态(比如商品的价格),然后可以当各个DGS查询时共享给它们。这样做使我们能够增加DGS的数量,同时不必担心会让单一的宇宙模拟过载。 · 从后端数据库,比如永久数据库(即将改成iCache)中读取状态以跟踪玩家的状态和资产 · 改进Quanta(指一组AI在宇宙模拟中的表示形式)的能力,用他们的特质和专精的技能来驱动他们的行为和工作。 · 改进星图和玩家分析,以便全面了解玩家的活动(旅行、战斗、购物等)。 去年在公民控上的演示展示了我们计划采用的高级模拟方法,但让玩家能感受到一个所有玩家(不仅仅是一个实例中50个玩家)都共享的动态宇宙所带来变化所需要的“管道”都还没有铺设,因此公民控之后的很多工作都是将其连接回游戏玩法的必要步骤,只有这样人们才能看到动态宇宙所带来的那些有因果关系的变化。
星际公民的服务器架构 对象容器流 服务器端对象容器流 服务器端对象容器流技术(SOCS)是一种流技术,可用于扩展Star Citizen服务器上的Universe规模。[2]基本概念是,如果没有玩家靠近某个物体,则游戏可以“冻结”该物体的状态。并且,游戏可以将其状态序列化(使用序列化变量)并将序列化的状态存储在数据库中,而不是将冻结的实体保留在内存中(招致成本)。当客户端在虚拟环境中移动时,服务器会将其视图更新到数据库中,以恢复现在附近的实体,并释放和存储不再需要的实体。[1] 实体流管理器和StarHash StarHash用于存储游戏中的实体,其方式是通过利用称为RadixTree的数据结构来有效搜索空间区域中的所有实体。然后,Entity-StreamingManager逻辑驱动StarHash-RadixTree查询,以基于所有连接的客户端的位置触发服务器上实体的加载和卸载。[1] 跨会话持久性 跨会话持久性允许游戏将冻结状态的实体存储在进程内数据库中,该数据库可以由不同的服务器或计算机使用。它是有效的网络访问层,允许将实体存储在其他计算机上的数据库中。在交叉会话持久化之前,当服务器崩溃或重新启动时,实体的状态会丢失(除了游戏已经持久的状态)。使用跨会话持久性,对象状态将在服务器重新启动和崩溃后保持(直到擦除持久性数据库)。[1] 智能缓存 智能缓存是一种后端系统和服务,可提供和管理所有播放器和实体数据的可靠持久性。[2] I-cache的第一大部分已于2019年3月完成并在内部进行了测试。它是现有pCache的替代产品。它是一个高度分布式且容错的存储/查询引擎,其性能大大优于pCache。它提供了索引和查询系统,其他服务可以使用该系统进行特定和复杂的项目查询。[3] 服务器网格化 服务器网格划分是一项允许游戏实例利用多个服务器的技术。游戏将由单个服务器分配多个服务器,而不是由单个服务器管理所有视图。这样做将减少每个参与服务器上的负载。将这些服务器放置在Amazon Web Services(AWS)上的不同机器上时,游戏可以轻松地随着玩家人数扩展。[1] 网络绑定剔除 网络绑定剔除是确定要在任何客户端上加载和卸载哪些实体的过程。具体而言,它使用实体组件更新调度程序的信息来确定要在每个客户端上加载或卸载哪些实体聚合的实体聚合单元。[1] 网络绑定剔除于2016年11月首次提及为实体绑定剔除。[4] 实体组件更新计划程序 实体组件更新调度程序是一个系统,用于根据实体组件相对于播放器的空间放置来控制实体组件的更新。它允许游戏跳过太远的各个组件的更新。网络绑定剔除使用相同的信息。[1] 它在2018年4月首次提到经过重构和接近完成。[5] 实体所有权层次结构和实体集合 实体所有权层次结构跟踪彼此相关的实体。如果它们是相关的,则游戏会将它们视为一组或实体聚合。与在关卡设计时将静态关卡几何和对象拆分为构建块的对象容器相比,实体集合由可以在宇宙中四处移动的动态实体(例如玩家,轮船等)组成。[1] 随着实体所有者管理器的发展,实体所有权层次结构于2017年3月首次被提及。[6] 实体生成批次和实体快照 实体生成批次代表一组应一起生成的实体,只有在全部生成后才可以激活。实体快照是属于实体的序列化变量的值。它们还用于将实体状态序列化为持久性,或用于Squadron 42保存游戏。[1] 序列化变量剔除 序列化变量剔除是一种仅在客户端与更新后的实体集合相邻时才将网络更新发送给客户端的系统。它在客户端上提供了显着的性能改进。此外,这是仅在整个宇宙的部分信息下运行我们的客户端游戏模拟的第一次真实测试。[1] 它最初计划用于Alpha 3.0,但被推迟到Alpha 3.1。[1] 基础技术 区域系统 Retaliator Multi-Crew设置中的区域系统(2015年7月) 区域系统是一个空间分区系统,它将一个级别中的所有对象划分为较小的实体。[7]有效地移动大型,复杂和交互式的物理对象组是必需的。[8]它取代了旧的CryEngine八叉树空间分区方案。[9] 它是在2015年1月的一次技术峰会上与CIG工作室的技术工程师Illfonic,Behavior Interactive和Wormbyte提出的。[7]开发工作于2015年5月由法兰克福团队开始。[9]它于2015年6月部署到了星际公民代码主线。[10]它于2015年7月开始被英国,法兰克福和圣塔莫尼卡工作室集成到各种游戏系统中,Retaliator(用作多人游戏,机组测试平台)和Cover System是第一个集成的系统。[8]导航网格和角色的路径于2015年8月开始集成。[11]法兰克福队扩大了区域系统,以更好地支持多种AI在2015年十月对象 [12]法兰克福队重写了的CryEngine的AreaManager(环境音效和混响)与区域系统整合在2015年十一月 [13]的英国团队于2016年1月开始致力于使对象容器与区域系统一起工作。 [14] 2016年3月增加了分层剔除支持。 [15]对标签(标记系统)的支持于2016年5月移入了区域系统。 [16]区域系统中的所有数据于2016年6月转换为AABB树结构。 [17]标签系统于2016年7月经历了一次重大的重构和优化。 [18]区域系统已于2016年11月移入区域系统。[4] C ++实体逻辑 C ++是一种多线程安全的脚本语言,大量用于各种实体逻辑。与不兼容多线程的旧版Lua代码相比,它允许在游戏模拟的同时进行资源加载,而不会由于需要的互斥而引入非常长的等待时间。[1] 转换何时开始尚不清楚,该转换的第一个提及是AI的产卵逻辑于2016年1月从Lua转换为C ++。[14] 2016年4月,这项工作仍在进行中。[19] ]提到它是由英国团队在2018年1月进行的。[20] 实体组件 实体组件代表特定游戏行为的一部分。对于组件,实体的行为由其具有的组件类型定义。如果没有组件,则各种不同的逻辑倾向于在一个整体且非常复杂的中央逻辑块中交错。由于它们是较小的部件,因此在我们同时加载它们时,使其与游戏模拟有效地通信要容易得多。此外,他们将整体游戏逻辑划分为更易于管理的部分,这在允许部分展开并发实体初始化中起着至关重要的作用。[1] 实体组件的基本支持已在2015年7月的主要开发分支中得到实施。[8] 对象容器 对象容器是一个关卡构建块。它取代了旧的游戏关卡格式。内容创建者没有发展一个大的层次,而是发展了一小部分。然后由许多不同的对象容器组成最终级别(或Universe)。它使开发人员在构建关卡时可以将世界分成许多较小的构建块。[1] 对象容器的概念和第一个原型于2016年1月推出。英国团队于同月开始将预制件转换为容器。[14]在2016年2月,法兰克福团队在开发分支机构中实现了用对象容器代替水平进行装载的基本支持。[21] 2016年8月,增加了对LOD网格合并和AI导航网格的支持。[22] 2017年2月,机库和商店中的旧预制系统被对象容器取代。[23] 序列化变量 序列化变量是存储实体状态的过程,以便可以在网络上传输它们并在另一台计算机上以相同状态恢复它们。它接受实体的各个部分并将其放入特殊的包装器对象中,包装器对象提供了序列化实体状态的方法。它允许以统一的方式编写游戏代码,而不管序列化的数据以后是否传输。[1]与CryNetwork中的旧实现相比,游戏程序员只需标记要复制到服务器/客户端的变量即可。底层系统可以检测自上次发送以来哪些已更改,哪些未更改,并以一种有效的方式处理其余部分。[17] 序列化变量的概念于2016年6月引入,开发于同月开始。[17] 超级地图 Mega Map是一个空的地图,用于加载和卸载对象容器。它用于减少加载时间,并且不需要加载屏幕。[24] 巨型地图的概念于2016年10月引入,以减少切换游戏模式的时间。[25]对单人游戏地图(如机库和单人竞技场指挥官)的支持于2017年2月在Alpha 2.6.1中实现。[26]支持于2017年3月在Alpha 2.6.2中实现了适用于多人地图(如Arena Commander和Star Marine)的技术。[27]
星际公民的核心技术发展历程 2015-01 提出了区域系统和实体流传输[7] 2015-05 区域系统正在开发中,实体流正在研究中[9] 2015-06 将区域系统部署到Star Citizen主要开发分支[10] 2015-07 开始在主要开发部门中实施区域系统[8]在主要开发分支中增加了对实体组件系统的基本支持[8] 2016-01 引入了对象容器的概念[14]开始将预制件转换为容器[14]开始让容器与区域系统一起使用[14]将太空飞船AI的产生逻辑从Lua转换为C ++ [14] 2016-02 为使用对象容器而不是作为级别的负载级别增加了基本支持[21] 2016-03 为区域系统添加了分层剔除支持[15] 2016-05 在区域系统中增加了对标签(标签系统)的支持[16]增加了重用实体ID的功能[16] 2016-06 开始进行序列化变量的工作[17]在区域系统中将数据结构转换为AABB树[17] 2016-07 区域系统中标记系统的主要重构和优化[18] 2016-08 增加了对LOD网格合并和AI导航网格物体的对象容器支持[22] 2016-10 巨型地图正在调查中[25] 2016-11 移动区域系统已移至区域系统[4]开始进行网络绑定剔除[4] 2017-02 在Alpha 2.6.1中实现了对Mega Map的单人游戏地图支持[26]开始使用对象容器替换机库和商店中旧的预制系统的工作[23] 2017-03 已实现对Alpha 2.6.2中的 Mega Map的多人游戏地图(不包括PU)支持[27]开始从事实体所有者管理器的工作[6] 2018-04 重构的实体组件更新调度程序[5] 2018-11 完成多线程异步后台生成,完成客户端对象容器流式传输。 2019-12 完成服务器端对象容器流式传输。 2020 全局持久性和服务器网格化????????????? 暂无固定日期
星际公民汉化进度报告和直播预告(7/20),粗翻86.2% 目前汉化粗翻的进度已经来到了86.2%,离不开所有人的努力,同时在@StarA星甲 的安排下我们的一审校对工作也开始同步进行,目前进度也已经达到了21.6%,感谢所有汉化组成员的辛勤劳动。 3D字体(一般用在交互)的工作也在进行中,这里也得感谢俄罗斯本地小组进行的技术支持,将汉化组3D技术人员制作好的中文3D字体转换成CIG所使用的格式,并且在后续进行了一些参数方面的校正。使得3D中文字体能在游戏中得以显现,虽然现在还存在一些问题,但是仍在不断调试中,预计不久就能搞定。 3D字体基本调试好后会进行下次汉化直播测试,时间我会发在这个帖子里敬请大家关注(应该在今天晚上不出意外的话),测试重点为3D中文字体在各个区域的展示是否正常(同时需要一个有890的志愿者伙伴协助测试),各个地点的终端(精炼、交易、叫船、各种商店、罚款,牢房等)。 汉化测试邀请: 汉化测试为我方主动邀请,目前参加汉化测试的人员有: 汉化组全体管理人员,汉化组在记录的贡献人员,Anicat(B站主播),Silverstorm65(斗鱼主播),Li_Yao(B站主播),以及直播间抽取5位幸运观众,贴吧抽取5位幸运玩家。另外如果***斗专精、贸易专精、风景专精,任务专精,以及直播员或者up主,也可以在本帖下方做一个简单的自我介绍,也有一定机会获得测试邀请。测试时间为一周。 汉化测试职责: 玩游戏并且做自己喜欢的事情,仔细观察 寻找汉化BUG并且上报给汉化组 提出合理的意见和建议
首页 1 2 下一页