随机/程序与先前制作的关卡生成


31

使用随机/过程生成与预制级别相比有哪些优点/缺点?

除了项目可能难以在随机生成的地形中分布以及生成的地形看起来很奇怪之外,我几乎没有想到。

但是,以前制作的关卡的缺点是我需要制作一个关卡编辑器。我无法决定使用哪种更好。

答案是否可以包括程序生成和预制生成的代码/示例以及优点/缺点?

Answers:


26

首先简要回答您的主要问题,以程序方式生成的游戏世界的主要优点是:

  • 这个世界可能很大,比任何手动设计的游戏世界都可能大得多。

  • 可以为每个游戏重新生成世界(或至少其中的一部分),这可能会增加重播价值,因为玩家总是会发现新的东西。

相反,程序生成的主要缺点是:

  • 根据所使用的生成方式,可能很难确保世界始终处于可玩状态,即,玩家无法仅仅因为他们对这个世界感到倒霉而无法继续前进。

  • 即使您可以避免产生完全无法玩的世界,随机世界的产生也会导致高度可变的难度:有时候,玩家可能会发现他们需要的一切只是为了排队而方便地排队,有时候他们可能走了很长时间却找不到任何有用的东西。

    在很长一段时间内,这种随机波动的确趋于平均,但是如果游戏难度过大(例如,前途艰巨)(对于生存游戏而言通常如此),那么糟糕的开局可能会毁掉游戏,而非常幸运的开局可能会使它失去所有挑战。

  • 程序生成不当会使整个世界感到单调和无聊:看到了十二个随机生成的迷宫之后,即使细节有所不同,它们也会开始看起来一样。

  • 同样,如果为每个游戏完全重现了游戏世界,那么玩家将无法从以前的游戏中识别出固定的位置或功能。这样的不熟悉可能会使玩家在情感层面上与游戏互动或与其他玩家分享经验变得更加困难。

在这两个列表中,您还可以考虑一件事:在一个游戏中,每个游戏的世界都随机生成的游戏中,没有“演练”指南之类的东西,因为每个演练都会有所不同。

(这种不可重复性对于测试和调试也可能是一个问题,尽管可以通过至少在调试模式下指定RNG种子和/或提供“ cheat”命令来至少部分避免这种不可重复性,快速播放到不同的阶段。)


但是,如果查看劣势列表,您会发现它主要描述了过程生成的劣势。通过手动混合程序生成的内容,可以避免其中的许多内容

例如,玩家可以总是从固定的,手工设计的城镇开始,也许被一个或多或少固定的较宽的家乡区域所包围,但是远离城镇的地方可以随机生成,以始终为玩家提供不熟悉的区域供探索。

在世界上也可能会有其他手动设计的城镇或其他地点(或多或少)随机放置,这样玩家就必须找到它们,但是一旦到达那里就知道会发生什么。相反,可以手动放置突出的特征(例如山脉)(至少在固定的起始位置附近),但是可以随机化其地形细节。

至于导致死锁和难度变化的随机放置,可以通过在过程世界生成算法之上实施各种一致性和平衡检查来解决。例如,如果玩家需要一个特定的物品才能穿越水域,则可以包括一些代码,以确保放置了至少一个这样的物品,以便玩家可以在不穿越水域的情况下到达它。

同样,您可能还需要调整项目放置规则,以便在玩家达到等级x之前不放置任何破坏平衡的棒棒糖,并可能确保至少有一个放置在玩家可以到达的固定位置在进入需要生存的阶段之前就需要使用它。


顺便说一句,使程序和手动生成的内容或多或少无缝地网格化的一种常见方法是使用程序世界生成器启动手动生成过程(可能已进行了适当的调整,例如,在需要的地方生成村庄或山峰) )初始化您要设计的区域,然后手动对其进行调整以添加和调整所需的细节。(这还可以通过仅保存手动更改以及所使用的生成器种子和参数来实现非常紧凑的级别存储。)

组合手动内容和程序内容的其他方法包括在您手动设计的关卡中留空白点,以随机内容填充(例如,城堡可能在地牢中包含随机生成的迷宫,仅固定了轮廓和出口),或者手动设计只能指定该级别某些部分的大致轮廓(例如,城镇中房屋的位置),而让细节(例如每所房屋的确切外观)可以随机选择。

实际上,即使许多具有完全固定游戏世界的游戏也使用某种形式的过程生成作为关卡设计过程的一部分,因为世界生成的某些方面(例如产生看起来自然的地形或在森林中放置单独的树木)手工很难和/或乏味,但相对容易实现自动化。

相反,大多数程序世界生成器将至少使用一些手动设计的对象和元素来构建世界。一个人甚至可以轻松地具有多层嵌套的随机/手动生成:例如,一个程序生成的世界可能包括一个手动生成的城镇,周围环绕着带有手工绘制的轮廓的程序生成的树林,而程序生成的树木带有手动设计的叶子。


还要注意,过程内容生成不一定与固定世界兼容:您可以选择一个固定的RNG种子并使用它来生成您的世界。如果您想让玩家探索一个广阔的世界,但又想让每个游戏和每个玩家都保持相同,这可能会很有用。

请注意,如果您这样做(或者甚至可能不这样做),则实际上应该设计世界生成器以使用多个RNG实例以分层方式工作,例如,整个地图生成器将保留一个RNG实例。它将用于生成子区域,为每个子区域分配不同的种子值,然后区域生成器将使用该种子值来播种用于生成区域的单独的RNG实例,依此类推。这是为了避免“蝴蝶效应”,因为即使更改了地图中最细微部分的最小细节,也可能会使RNG失去同步,并导致世界上所有其他事物完全不同。

避免蝴蝶效应的另一种重要方法,特别是如果您在玩家探索时“动态”生成世界时,是完全避免正常的RNG(除了从玩家的角度来看“瞬时”发生的过程,例如生成玩家进入游戏时进入一个新的关卡),而是使用不存储任何内部状态的随机数生成方法。例如,当为玩家要进入的子区域选择种子时,整个世界生成器可以获取该子区域的坐标(及其自身的总种子),并将其馈入哈希函数以生成子区域种子。这样,每个区域都将始终看起来相同,而不管玩家进入区域的顺序如何。


附言 经过所有这些题外话,让我简要地谈谈您有关程序生成实际代码的最后一个问题。唉,我不认为这是没有任何意义真的听命很多比你提供更详细,因为有字面上许多不同的方式做程序世界一代有游戏使用它们。

例如,在所有通过程序生成的探索游戏中,曾祖父很可能就是Rogue,其关卡生成算法只是将一堆矩形房间随机放置在较大的矩形关卡中,然后将这些房间与通道连接起来(然后将楼梯放置到其中一个的下一个级别)。从NethackDiablo系列的各种继任者都以多种方式详细阐述了该系统,但是大多数都保留了基本层次的基本思想,即由房间,地牢和迷宫组成的不同层次,或多或少地随机放置在网格地图上。

相反,对于具有开放户外设置的游戏,您可能需要从某种分形地形生成算法入手,并在其上构建其他功能(河流,森林,城镇等)。或者,您可以执行类似Minecraft的操作,并生成随机的3D 程序纹理,分别确定地面的哪些部分是地面和空中(按比例缩放和倾斜,以便更可能是下部的块),然后叠加水之类的要素,土壤/岩石,植被等。

当然,如果您正在编写一个太空探索游戏,那么上述方法都不适用,在这种情况下,您只需要根据一些密度函数生成一堆随机放置的恒星系统,然后生成一个随机每一套中的恒星和行星。或者,也许您是让您的玩家探索非欧几里德的风景,在这种情况下,您将面临一系列完全不同的挑战(例如,给定半径内的体积呈指数增长而不是多项式增长的事实)真的很难保持在内存中的大图)。


7

程序生成的优点

  1. 可以轻松地将地图/设计缩放到真正的大尺寸,比手工创建的要大得多。

  2. 通过创建一个动态创建地形块的系统,您可以避免必须编写代码以从永久内存中加载块。

  3. 从长远来看,使用程序设计可能比使用手动地图编辑发现更多可行的关卡。

  4. 对于您的“探索者”游戏,您可以生成数十个,数百个甚至数千个彼此不同的关卡,以免使玩家感到无聊。

程序生成的缺点

  1. 需要进行大量工作才能确保生成的地形看起来像“您想要的样子”。

  2. 创建“测试水平”变得很麻烦。

  3. 正如您提到的,物品和其他类似物品的放置必须谨慎进行,尽管对于自上而下的资源管理器游戏,这可能比您认为的要少。

  4. 除非进行了广泛的测试,否则您可能会遇到这样的情况,即您的游戏玩法完全被某个特定的程序级别破坏了,这比手工制作一个级别要严重得多。

  5. 对于真正复杂的地形,您可能最终会花更多的时间在错误修复和设计工作上,而不是花在制作基本的地图设计工具和文件加载器上。

手动设计的优点

  1. 游戏设计师可以更加放心,游戏玩法在每个级别的上下文中均应发挥作用。

  2. 与程序生成相比,可以更轻松地创建和放置“精细细节”。

  3. 有些地形特征在程序上很难生成,例如流下山的水。这样做将需要对海拔图进行非常彻底的评估,而这可能很难设计。

  4. 引导玩家沿着“线性路径”更容易,尽管正如您所说的那样,您正在构建“探索者”游戏,但这可能并不那么重要。

手动设计的缺点

  1. 对您的地形应用广泛的更改将非常耗时,而在生成过程时,仅修改几个值将产生完全不同的地形。

  2. 您将必须将每个映射存储在内存中,这对于较小的级别可能是可接受的,但是对于较大的级别,过程生成可能是您唯一的选择。增加了游戏的永久内存安装要求。

  3. 可能需要构建地图编辑器和文件加载系统。

我最终列出了过程式内容生成的更多缺点,尽管这可能是因为我的项目完全是过程式的,所以我知道它的陷阱。对于资源管理器游戏,我建议您考虑每个地图的大小,以及是否愿意创建单独的地图编辑工具。


您可以(不在这里,而是在某处)显示您的程序生成的代码吗?我不会使用它,但是我以前从未尝试过以程序方式生成地图。(这就是为什么我问这个问题:P),此外,我还支持您的回答,但是有点想别人的意见,所以我可能不会马上接受它
2013年
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.