什么是游戏中的场景图
引擎开发环境?
嗯,这是一些代码,它可以主动对游戏空间中的游戏对象进行排序,从而可以轻松快速找到游戏空间中某个点周围的对象。
这样,很容易:
- 快速找到相机视图中的对象(并仅将它们发送到显卡,使渲染速度非常快)
- 快速找到玩家附近的物体(并仅对那些物体应用碰撞检查)
还有其他的。这是关于允许在空间中快速搜索。它被称为“空间分区”。这是关于分而治之的。
我为什么要实现一个
我的 2D 游戏引擎?
这取决于游戏的类型,更确切地说取决于您的游戏空间的结构。
例如,像 Zelda 这样的游戏如果速度足以测试屏幕中所有对象之间的碰撞,则可能不需要此类技术。然而它很容易真的很慢,所以大多数时候你至少设置一个场景图(或任何类型的空间分区)至少知道所有移动物体周围是什么,并只测试这些物体上的碰撞。
所以,这取决于。大多数情况下,出于性能原因需要它。但是空间分区的实现完全与游戏空间的结构方式有关。
场景图的使用是否站得住脚
作为经典实体的替代品
具有线性实体管理器的系统?
没有。
无论您以何种方式管理游戏实体的对象生命,空间分区/场景图的存在只是为了让您快速搜索空间中的对象,不多也不少。大多数情况下,它会是一个具有一些对象槽的对象,对应于游戏空间的不同部分,并且在这些槽中它将是那些部分中的对象。
它可以是平面的(如 2 或 4 中的 2D 屏幕分隔器),也可以是树(如二叉树或四叉树,或任何其他类型的树)或任何其他限制您必须进行的操作数量的排序结构执行以获取一些与空间相关的信息。
注意一件事:
在某些情况下,您甚至需要为不同的目的使用不同的独立空间分区系统。通常,“场景图”是关于渲染的,因此它以取决于玩家视角的方式进行优化,其目的是允许快速收集要渲染的对象列表以发送到显卡。它并不真正适合在另一个对象周围执行对象搜索,这使得它难以用于精确的碰撞检测,例如当您使用物理引擎时。因此,为了提供帮助,您可能会出于物理目的使用不同的空间分区系统。
举个例子,我想做一个“子弹地狱”游戏,玩家的飞船必须以非常精确的方式躲避很多球。为了获得足够的渲染和碰撞检测性能,我需要知道:
- 当项目符号出现在屏幕空间中时
- 当子弹离开屏幕空间时
- 当玩家与子弹碰撞时进入
- 当玩家与怪物发生碰撞时
所以我递归地将 2D 屏幕分成 4 个部分,这给了我一个四叉树。四叉树在每个游戏刻更新,因为一切都在不断移动,所以我必须跟踪四叉树中每个对象(飞船、子弹、怪物)的位置,以知道哪个对象位于屏幕的哪个部分。
实现1.很容易,只需在系统中输入项目符号即可。
为了实现 2。我在屏幕边框上的四叉树(屏幕的平方部分)中保留了一个叶子列表。这些叶子包含靠近边界的子弹的 id/指针,所以我只需要检查它们是否正在移动,以了解我是否可以停止渲染它们并管理碰撞。 (它可能有点复杂,但你明白了。)
要实现 3 和 4。我需要检索玩家飞船附近的物体。所以首先我得到了玩家宇宙飞船所在的叶子,然后我得到了里面的所有物体。这样,我只会在周围的物体上测试与玩家飞船的碰撞,而不是所有物体。 (它有点复杂,但你明白了。)
这样我可以确保我的游戏即使在成千上万颗子弹不断移动的情况下也能流畅运行。
在其他类型的空间结构中,需要进行其他类型的空间划分。通常,卡丁车/汽车游戏会有一个“隧道”场景图,因为玩家在视觉上只会看到沿路的事物,因此您只需检查他在路上的位置即可检索“隧道”周围的所有可见对象.