之前为了了解UE5.2和搭建大世界开发工具管线,用了一些时间,和团队做了个小Demo。
在开发过程中,我们意识到无缝大世界的早期流程要比分块世界游戏复杂一些。对于早期参与人员素质的要求也较高。尤其是策划和美术,需要有相对有经验的人来指挥早期的迭代,统筹安排每一个阶段的起止点。
本文用来记录和分享在这个阶段遇到的问题和解决方案,以及在目前阶段形成的工作流。
我们先快速回溯一下传统分块世界的设计过程中。大体分为三个阶段:
勾勒一个大致的世界结构,并确定游戏中所要制作的每个场景在世界中的位置。
在上述过程中,策划会进一步确定每个场景的几个出入口,和大致的地势结构。
有了上述的情况,一张没有颜色的世界区域草图和大致的路线图就可以由美术团队勾勒出来了。
在此基础上,我们可以大致再一次合理化每个场景的经纬度,进而策划美术双方达成对于每个场景大致出入口位置或者方向的统一。
1 根据世界设定和故事设定,策划可以确定每个场景的:
2 美术(在条件允许的情况下)进行概念——原画——地编粗——地编细的顺序进行场景制作。在这个过程中,策划和美术同时进行细化设计和制作,互相迭代,逐步推进细节。
1 根据实际开发节奏,关卡策划对自留地进行白盒搭建,程序配合验证玩法。
2 美术先配合世界观和剧情策划对故事需要的地形进行修改,造景,同时配合这些地形逐步填充整个场景。
3 在关卡自留地的白盒确定之后,根据关卡的需要进行美术资源填充。双方确定之后,美术将整个场景润一次,交货。
(我就说个大流程,而且每个项目可能都会有自己的独特性,超多细节就不一一罗列了。)
而在无缝大世界游戏的设计过程中,最大的问题就是“地形地势需要整体考虑,确定之后就是一切的基础,大改场景就是伤筋动骨,伤筋动骨一百天(起)!”。所以,上述三个阶段可能会变为两条并行的管线线,并且在中期会合并在一起形成一个滚动迭代的工作流。
策划需要根据故事需要确定世界的结构,并确定世界各个区域的地势和生态,并且确定山脉、地标性地形、河流等需要符合大自然规律的场景主体元素。
在上述过程中,美术可以用程序化生成的方式快速根据策划的需要迭代基础地势。
策划需要根据美术给的地势确定每个区域的大致形状、大小以及地标性地形的位置。有些东西该用白盒示意就用白盒示意。需要关卡或者剧情细节设计的区域需要将占地面积设计的大一些,设计大了可以靠各种方式改小。但是设计小了,就很难扩大了。
而且,每个区域完成策划所需求的范围规划之后,美术还需要考虑场景包边、远景的视觉效果和不同场景风格、不同地貌如何接续。
由于专业和关注点不同,策划很可能会意识不到远景和场景主体地形剪影带来的视觉引导和氛围感。但是美术需要考虑。当没有原画和概念支撑的前提下,地编需要时刻保持警觉。
所以在策划完成第一版场景区域设计之后,美术很可能会由概念设计师和地编一起,对各个场景进行一轮基于美术视角的修缮,顺序可能是从主程到郊外,从中心向四周。重新推敲整个世界结构之后,将场景区域设计图重新输出。再和策划进行讨论,进行迭代。
3 在此阶段,制作人、主美、主策需要在实际制作中的场景内模拟演绎未来游戏中可能会出现的各种玩法、活动。确定为未来的活动玩法预留的区域。这些区域可能会涉及到策划的调整和美术的制作方案。甚至可能会产生程序需求。
1 建立关卡元素标准 战斗策划、关卡策划、数值策划在白盒区域和技术一起验证核心玩法。确定不同规格的核心玩法所需的空间大小。 在白盒区域根据玩法需要确定各种基础结构,作为比例尺来约束美术。比如用来描述:
这些东西最大的作用是在美术进行世界场景设计时,可以直接抡到实际场景里来判断自己做的东西是否符合策划预期。以及在此基础上确定自己预留的额外空间够不够。
这条线的东西随着产出,会直接被第一条线的开发者拿去当作尺,所以制作人、主策和主美需要约定有多少“尺子”需要尽早确定,并且有优先级。
尺子的确定,来自于核心玩法的逐步清晰。部分的关卡白盒原型就可以出来了。
这些关卡白盒可以作为整体结构放在第一条管线中进行验证。
理想情况下,随着关卡整体白盒的逐步完善,第一条管线中的设计就越发精确了。 但是现实是臃肿的,因为第一条管线的快速滚动,且美术自己的流程会导致美术的工作会逐步走向快速工业化,策划注定是跟不上的。这个时候美术为了减少自身的迭代,必然会主动预留空间。而且为了每个微观场景的视觉效果,远景的制作必然存在在这个世界中。这就导致世界的结构比策划预期的要大。
于是,策划需要有一些灵活的内容来“溜缝儿”,即用一些零碎的内容填充大量过度场景。所以这个时候会产生一些策划向的程序化生成需求。而这些需求需要策划全体一起上。 其实,在一个广阔的无缝大世界上,策划原本想要精确设计的游戏内容区域大概只有整体面积的不到30%,但是却因为玩家真实的需要用双脚(或者骑着载具)丈量这个世界,而让整个世界的每个角落都充满生机。这就导致策划需要设计的游戏内容区域可能会占整体面积的70%,甚至更多。
我们拿《原神》举例子。我们可以找到早期《原神》1.1版本时候的地图规划。那个时候我们可以看到《原神》的早期规划地图是从东向西延申的。
但是,我们可以发现地图的延申方向变为从东北向西南。
已经完成的版本必然会涉及到未开放区域的地形,并将其作为远景使用。如果实际制作时发现不合适,就会进行修改,那就会造成对之前地形的远景修改,可能会产生非常大的工作量,对玩家也很不友好。所以,让地图的延申方向从一个边改为一个角,最大限度的减少对已完成部分(尤其是已推送给玩家的部分)的修改。
当然还有一个很重要的问题是这样可以提高运行时的效率。
看完上图有没有一种感觉,交叠的部分越多的区域,那个版本更新的时间其实相隔的时间就很久。璃月和须弥中间隔着好大一个稻妻的版本。沙漠的一整块地方明明是连着的,但是千壑就没办法和沙漠版本一起出。
评论区
共 7 条评论热门最新