就像大型开放世界游戏可以动态加载大量地图一样,我们不能通过相同的动态加载方法来加载单独的地图,菜单以及几乎任何界面或3D设置吗?在不更改环境的情况下,似乎可以动态加载游戏中的界面和各个位置,就像在浏览大型开放世界地图时一样。
为什么不这样做呢?我看到了很多现代游戏,在加载比赛/地图/关卡时,您需要等待一分钟或更长时间。我知道连接对等方会产生延迟,但是根据我的经验,这不会花费太多时间。该概念存在哪些问题,以至于无法使用它消除加载地图/级别/界面数据所需的加载时间?
就像大型开放世界游戏可以动态加载大量地图一样,我们不能通过相同的动态加载方法来加载单独的地图,菜单以及几乎任何界面或3D设置吗?在不更改环境的情况下,似乎可以动态加载游戏中的界面和各个位置,就像在浏览大型开放世界地图时一样。
为什么不这样做呢?我看到了很多现代游戏,在加载比赛/地图/关卡时,您需要等待一分钟或更长时间。我知道连接对等方会产生延迟,但是根据我的经验,这不会花费太多时间。该概念存在哪些问题,以至于无法使用它消除加载地图/级别/界面数据所需的加载时间?
Answers:
答案是肯定的,在大多数情况下,至少可以做到这一点。
未完成的原因有很多:
如果菜单中有大量资产,则这些资产需要花费一些时间来加载。您也不知道人们将按什么顺序浏览菜单。他们可以依次单击选项->后退->积分,或单击积分->后退->快速开始游戏。因此,没有合理的流策略。
在开放世界游戏中,您知道玩家的移动速度不会超过某些特定速度,因此,您知道不需要加载遥远位置的详细版本,直到他们接近它们为止。
这种解决方案可行性的一个重要因素是需要加载的内容的可预测性。如果玩家加载全新的关卡而无法预料到他们会选择什么,那么就不可能实现完全无缝的解决方案。例如,当玩家可以选择游戏中的任何关卡进行播放时,或者他们有自由传送到开放世界游戏中完全不同的区域时。
在设置多人游戏时,某些Halo游戏开始在后台加载选定的关卡。这减少了玩家准备开始的等待时间,并且当玩家可以自由选择完全不同的资产来选择不同级别时,这可能是最接近这种解决方案的时间。
当然,您说的是“不改变环境”,但是我只想举起Halo示例,因为我希望看到更多。
正如您所说的那样,在连续的活动中,或者每当开发人员对玩家的位置有很多控制权时,这种解决方案肯定是可行的。顽皮狗喜欢取消加载时间,其中著名的是Jak和Daxter在PS2上没有加载时间,而《神秘海域》游戏一开始就只有一个加载时间。
但是,对于许多人来说,加载时间并不是需要解决的问题。或者,这是一个很低的问题,因为从现在到发布日期之间总会有更多事情要做,因此开发人员的优先级很低。
最终,它是有限的资源。
开放世界的游戏,尤其是MMO,都是针对可预测性而精心设计的-您始终知道需要提前加载哪些数据。您可以在世界的体系结构中看到这一点-每当需要加载大量资源时,您就可以通过某种方式来防止用户看到尚未加载的内容。最常见的方法是在需要装载的关键几秒钟内将门挡在下一个区域的视野之外。大多数MMO也使用不太详细的模型和纹理,从而大大缩短了加载时间。
即使精心设计,有些事情还是无法预测的。例如,可能有玩家佩戴的自定义横幅,仅在相关数据已通过网络发送到您的计算机后才显示。当然,大多数游戏都试图限制它以使其更便宜(例如Diablo III的标语是简单的组成,易于发送少字节的数据)。但最终,有时您只需要等待数据传输即可。而且,您需要在加载过程中显示一些内容 -在许多游戏中,这可能会导致沉浸感中断,因为您在等待加载数据时看到一个灰色的,低细节的模型。
因此,像这样的加载是一个解决的问题(TM),但这并不容易。在优化资源及其利用率以确保流畅的播放体验方面,以及在代码本身中,这都要花费大量的资源和时间,而异步代码则很难。即使一切正常,这也可能意味着游戏体验会降低-这意味着您必须确保不超过最低公分母的带宽能力,因此您需要降低模型和纹理的质量,或使其质量下降少变化,世界的几何形状受到严格限制。如果您不这样做,那么游戏将非常无法玩-我记得那些玩过花10分钟(甚至更长!)来加载地图的游戏的人,仅仅是因为他们的计算机无法完全完成任务,游戏之后它本身运行良好。如果它具有无缝加载,则游戏将一直冻结或显示难看的纹理并在等待数据加载的同时进行建模。延迟加载并非双赢,这是工程中大多数事情的权衡:)
动态加载并非始终是其他答案尚未真正考虑的理想解决方案的一个原因,我认为这也是弹出窗口和其他图形工件。
加载什么和不加载什么的预测通常会失败,并且这样做可能会降低您的体验。最糟糕的例子之一是id Software的Rage。至少在早期版本中,超大型纹理系统使它如此之快,以至于诸如旋转太快之类的东西都会产生大量的纹理,甚至出现几何假象,然后才逐渐消失。
这些问题并不是所有内容都已预加载的问题。
不必考虑要加载什么,而是要卸载什么。如果您只有足够的空间预算,则在加载新内容时,要删除的旧内容是什么?您如何确定这些资产在接下来的几秒钟内不会使用?这些都是很难解决的问题。
如果每个游戏状态都小到足以容纳一个通用系统预算,那么每个优势都是显而易见的,而不是加载,您直接进入一个关卡,随着游戏的进行,事物就会逐渐消失。但是,正如主要答案所暗示的那样,小型游戏的加载时间不会太长而不必担心。
我认为值得考虑一下最初创建动态加载系统的原因,因为您知道自己的几个游戏状态对于一个通用系统可能太大,而这种大小的游戏根本不可能完全预加载。
一个普遍的原因是,在不久的将来确定是否需要某种资源并不总是那么容易。
由于您以地形分页为例,因此我将继续。
如果您在给定的地图网格中将所有相邻的地图网格加载到背景中,这是完全合理的。您知道用户最多只能输入其中之一。完成后,您可以卸载不再相邻的那些,并加载现在已经存在的那些。您已注意到这一点。
现在想象一下快速旅行。绝对没有办法预测用户可能选择去的地方。他们(通常)几乎可以选择整个地图。预加载所有可能的快速行驶位置将占用过多的内存(您最好将整个地图首先加载到内存中)和太多的时间(假设您没有预加载整个地图)。什么时候会发生?当他们打开快速旅行对话框时?这个问题只会变得更糟!
这就是为什么即使大多数具有“空载”地形分页的游戏在快速行驶时仍具有装载屏幕的原因。这也是为什么如果移动速度足够快,有时甚至可以在具有空载地图的游戏中触发加载屏幕(我记得在TES Oblivion中已经做到了)。
现在想象一下,这种关系通常适用于游戏资源,而这些资源之间的关系通常并不明显。您最终将不得不加载所有可能的选项,或者开始猜测用户将要做什么。猜测是昂贵的(包括开发和CPU在内),而且编程很复杂。具体示例:
可能有一些方法可以解决这些问题,但是这需要花费现实生活中的钱才能弄清楚。大多数游戏玩家都接受合理的加载屏幕,并且,如果有的话,往往愿意花更多的钱在硬件上来减轻它们。它被视为硬件问题,而不是游戏问题,除非异常过多或具有破坏性(例如在关卡中间加载)。
请记住,后台加载不是免费的。现代使用后台加载地形和一些模型文件通常不会带来多大的影响,但是如果您突然猜测许多不同的资源,尤其是如果您没有可靠的指标并且必须卸载许多资源并加载多余的资源,您可以将系统研磨成灰尘。
后台加载的想法是为了更好地利用死循环,但是只有那么多死循环可以使用。内存也是如此-预加载会大大增加游戏的内存使用率。通过加载屏幕,您可以转储现有资源。后台加载没有这样的奢侈,意味着仅此一项就可以使游戏的内存需求增加一倍。
这是一个普遍的问题,原因是游戏是软实时产品,其中内容的延迟交付不如按时交付有用(与硬实时(如计算机中的汽车)相比,延迟交付可能总比没有交付更好。您必须决定要加载什么以及在何处加载。
有时,延迟交货特别糟糕。例如,如果允许您在所有墙都加载之前在一个世界中跑来跑去,那么您可以躲在一堵墙后面,如果游戏在让您移动之前加载了这些墙,您将永远无法落后。告诉您何时可以轻松完成内容的“懒惰”加载以及何时必须确保内容已完全加载并不总是那么容易。
动态加载也要复杂得多。您必须不断考虑如果资源尚未加载该怎么办。这浪费了开发资源。当您可以依靠资源来生存时,开发起来要容易得多。
延迟也不总是可以接受的。我听说过《星际争霸》中的情况,您会通过加载地图来“热身”游戏,该地图具有缓存每个动态加载的模型/图像的副作用。然后,您将退出并正常玩游戏。对于精英游戏玩家来说,这最大程度地减少了GUI的卡顿现象,这实际上影响了他们的游戏玩法。试图证明哪些延迟对于用户是可接受的,而哪些延迟则不是棘手的。