开放世界
文章平均质量分 93
基于Unity的开放世界各种解决方案,可以用于手机和多人联网游戏。
魔术师Dix
API Caller
展开
-
负反馈性能调节系统
最早看到这个概念是在《腾讯游戏开发精粹II》里,看了之后感觉非常实用,于是将其列为开放世界的一个必备组件。其运行逻辑简单总结就是:例如监测到帧率下降时,则进行减少一些特效、音效,对不重要的 AI 降频等操作,使帧率提升。这样使得游戏整体帧率保持平稳,且能最大限度保证玩家的游戏体验。原创 2024-09-04 15:43:55 · 684 阅读 · 0 评论 -
开放世界的开发利器:白模
所谓白模(BlockMesh),就是在关卡设计初期,使用极简模型搭建的示意,用来测试关卡的合理性和可玩性。这不是一个新概念,在众多高质量游戏制作中都是必不可少的流程。这里我推荐一篇顽皮狗关卡策划 David Shaver 关于白模分享(原版PDF下载)五分钟GDC 01:游戏Blockmesh关卡设计技巧——图文版 - 哔哩哔哩Hello 大家好,这里是五 分 钟GDC,今天给大家带来的是游戏关卡设计中Blockmesh 的技巧。首先,让我们先了解一下什么是Blockmesh。原创 2024-09-03 20:41:12 · 1193 阅读 · 0 评论 -
什么是游戏开发流水线?以及我们为什么需要他?
游戏开发流水线,即从构思到成品的一系列过程。相信有的朋友已经迷惑了:哪个项目不是从构思到成品呢?诚然,所有项目都是从构思到产品。但关键在于 “一系列过程”。你经历过的项目,他们的这个过程是相同的吗?有通用的步骤吗?每做完一个项目,能让我下一个项目进行地更快吗?也许,有的项目是先写好策划案,美术和程序再依照制作;有的项目是一边做功能,一边补案子;有的项目做了编辑工具;有的项目有原型流程图……然而,如果不能将游戏的开发步骤形成规范,且既能从项目中抽象出来,也能适配到项目中去;原创 2024-09-03 11:48:15 · 1041 阅读 · 0 评论 -
开放大世界的全局寻路
开放大世界的寻路一直是很困扰我的一个点,地图大、还是动态可变的,所以寻路会有很多要求。根据上面的需求,像 NavMesh、JPS+ 虽然效率高,但是重建代价大;用 A* 重建代价小但是效率也太差了;而 FlowField 又不支持多目标寻路。最后,我根据项目本身的需求,设计了一套适用于航海主题的海洋+岛屿的寻路解决方案。这个方案能够满足项目要求,且只有一个 O(1) 的复杂度,还可以分布寻路,地图的重建开销也很低。当然,这里对岛屿、地图设计做了一些限制,同时是针对航海特化的方案。原创 2024-08-30 14:49:55 · 1037 阅读 · 0 评论 -
开放大世界千人同屏网络设计
客户端(逻辑层)服务器都采用ECS架构(只有ECS能满足设计需求)。总体上还是使用状态同步,各个客户端看到的表现不一致。玩家主要关心周边的单位,而不是全部的AOI块内的单位。同步时,只同步移动(路径)信息,其他信息一概不同步(包括血量)服务器提供一个协议,供客户端直接拉取某个玩家的具体信息(客户端主动请求,避开主服务器的同步,类似于灯塔)。客户端根据相机范围来主动向服务器拉取(只读)。这个请求需要做到能无代价。原创 2024-08-30 11:44:09 · 1239 阅读 · 0 评论 -
开放大世界的碰撞与物理
对于开放大世界的物理碰撞,根据现有解决方案,需要将带物理的物体控制在 1k 以下,就能很好地在手机上运行并支持玩法。对于特殊的需求(例如翻墙、攀岩)等,通过射线手段进行辅助检测,减少物理碰撞的开销。基于 GpuTerrain 实现的地形,则需要通过生成 SDF 图的方式来辅助碰撞,基本上能满足需求。对于一些对碰撞精度要求较高的需求,也可以通过取巧的方式来实现。(例如,如需要玩家在前进过程中自动绕开一些小型灌木。原创 2024-08-28 12:09:16 · 1147 阅读 · 0 评论 -
开放大世界的数据管理
经过前面几个章节的介绍,开放世界的数据管理就已经初具雏形了。实际上,开放世界数据最麻烦的,就是各种地图渲染数据。如果地图渲染数据解决了,逻辑数据处理起来也是相对容易的。所以这里讲的,核心也是在地图渲染数据。这个视频是使用这一套技术整出来的Demo,有美术的配合就好看很多了。Island_G效果演示(8月版本)_哔哩哔哩_bilibili岛屿效果演示视频,项目中的Island_G。除了常规的天气、后期等,此版本主要增加了草海效果。这个版本的草海是根据新的草海插件美术手动绘制的,在CPU多线程进行渲染。原创 2024-08-27 20:59:41 · 631 阅读 · 0 评论 -
【Unity】移动端草海解决方案
草海是开放大世界渲染的必不可少的因素,Unity 原生的 Terrain 草海效率较低,而且无法与 RVT 结合起来,无法在移动端上实现。因此我们自己搓出来一套草海系统,使用 C# 多线程辅助运算,并能支持割草、烧草等进阶玩法。草的位置、密度、类型还需要根据美术和地形的信息进行自适应。最终效果可以看这个演示视频:GpuTerrain+草海_哔哩哔哩_bilibili地形用GpuTerrain渲染;草海是自定义实时生成运算+Gpu渲染。原创 2024-08-24 15:50:06 · 911 阅读 · 0 评论 -
基于 Dots + GPU Instance 的大规模物体渲染
之前写的两篇开放世界技术栈都是公司其他同事做的,所以很多细节了解不详细。但这次是全程我自己搭建的轮子,可以讲得稍微详细些。之前写的大规模物件渲染的 GPU 版本,虽然渲染量大效率高,但是有个很致命的缺陷:无法与游戏逻辑进行交互。因为主要渲染数据都是放在 GPU 中,为了效率要尽可能减少异步回读,也要尽量减少同步数据量,所以要物体与逻辑交互就基本不可能了。但是使用 Unity 的 Dots 系统再加上 GPU Instance 技术,就可以很好地解决这个问题。原创 2024-08-22 13:58:13 · 1196 阅读 · 0 评论 -
GPU驱动的大规模静态物件渲染
GPU Driven 的静态物件渲染,听起来很高级,其实具体操作很简单,基础就是直接调用 Graphics.DrawMeshInstancedIndirect 这个 Unity 内置接口就可以了。但我们项目对这个流程做了一些优化,使得支持的实体数量有大幅提升。这套系统主要也是公司的 TA 实现的,这里我也只简明扼要地介绍一下原理。原创 2024-08-15 17:11:09 · 823 阅读 · 0 评论 -
开放大世界的 GpuTerrain + RVT
Unity 原生有一个 Tarrain(地形)系统,但可惜并不能直接用于开放世界,当然是因为其效率问题。现在开放世界主流是使用 GpuTerrain + RVT ,也是一个成熟技术了。在项目中实现这个技术的是公司的 TA(我只做了接入),具体不了解,这里也只是大概说明下这个技术。如果对这套技术缺乏了解的,建议直接去看参考文章,而不是本文(因为本文写得非常简略,也不包含实现方案)。如果已经了解了的,这篇文章也可以跳过。原创 2024-08-15 11:52:29 · 970 阅读 · 0 评论 -
Unity手游开放大世界解决方案
在介绍技术栈之前,需要先了解下项目需求(因为有不少方案都是基于需求而定制的)。我们这个项目是一个海洋主题的项目,整个大世界是由一片大洋和星罗棋布的岛屿组成。最大的岛屿占地 2048*2048 米,最小的岛屿占地 256*256 米,整个世界大大小小岛屿总量约 1万。评估下来,总世界面积超过 4000 平方公里,总陆地面积约 922 平方公里。其中,岛屿有上岛玩法,即玩家可以扮演一个 NPC 登陆游玩,类似 RPG 游戏,可以进行解谜、战斗、探索等。玩家岛屿固定大小,可以在地图上迁移。原创 2024-08-14 18:30:38 · 677 阅读 · 0 评论