游戏引擎学习第35天

开场介绍

今天的任务是继承改进一个虚拟的瓦片地图体系，使其得当处置惩罚更大的天下。我们希望这个体系能管理大范围的游戏天下，其中包罗按需存储的小区域。昨天，我们介绍了“内存区域”的概念，用于管理持久性存储。我们筹划今天继承这个主题，深入探讨它的工作原理及其可能的优化方向。
目前，我们的天下生成还相对简单，只是随机生成了一些内容。今天的目标是进一步完满这个过程，并实现一个可以存储和加载更大规模游戏地图的功能。
创建一些房间

我们开始设计一个简单的房间体系。为了让游戏中的小脚色可以或许在这些房间里活动，我们需要设置一些墙壁来限定空间。最初，体系是随机生成的，屏幕巨细为32x32，每个瓦片的值也都是随机设置的。为了改进这一点，我们决定在游戏中加入一些现实的墙壁。
在实现时，墙壁的放置方式是：如果某个瓦片的位置位于屏幕的边缘，我们就将这个瓦片的值设为1，这样它就会成为一个“拦截器”或者墙壁。这样做可以在屏幕的边缘生成程度墙壁，同时也可以生成垂直墙壁，从而有效地创建封闭的房间。
通过这种方式，我们可以或许创建出一个被墙壁围住的空间，使得脚色无法容易离开这个房间，直到墙壁的设置完成。终极，这种设置形成了一个简单的房间，脚色被限定在其中，无法脱离该区域。通过这样的方式，我们为小脚色提供了一个明白的活动空间。

创建一些门

目前已经有了根本的房间布局，但是还没有添加任何门。接下来需要做的是为这些房间添加门。门的生成有一些条件，起首需要检查是否满意条件才气在指定位置生成门。如果一个房间的高度大于 2，则不需要门；否则，若宽度超过 2，那么门会出如今中间位置。
这样就能在房间中生成门，使得玩家可以或许通过这些门穿越差异的房间。这样创建的天下会非常庞大，但目前它还只是一个简单的房间布局，内里没有其他特殊内容。通过这个过程，可以快速生成多个房间，但这些房间目前并没有充实的内容。
进一步的想法是测试地图的希罕性，尝试举行优化或变化，例如引入一些可能影响帧率的测试。当前的实现方式可能会很慢，因为我们正在循环遍历全部的瓦片并对其举行操作，因此需要进一步优化来提拔性能。

小房间和瓷砖 ID 值的处置惩罚

• 瓦片尺寸调解：
  
  
  
  • 假设我们将瓦片的尺寸做得非常小，这样在同样的屏幕空间内就能放置更多的瓦片。通过调解瓦片的巨细，可以使得在屏幕上表现更多的瓦片，例如，可能将像素单位调解为更小的值，或者以更高的分辨率绘制瓦片地图。
    
  
  
• 调解天下的巨细：
  
  
  
  • 通过改变瓦片的巨细，可以改变游戏天下的规模。当前测试场景的像素数量会影响地图的巨细。例如，将瓦片尺寸缩小，使得每个瓦片占据的空间减少，可以让地图的表现变得更大，绘制的瓦片数量也会增加。
    
  
  
• 绘制瓦片地图：
  
  
  
  • 初步目标是绘制一个较大的瓦片地图版本，而当前的绘制方法可能会导致帧率变慢，特别是如果我们没有举行优化时。例如，当瓦片数量增加，绘制的计算量增大时，性能可能会下降。
    
  
  
• 初始化瓦片地图：
  
  
  
  • 瓦片地图中的某些部分可能还没有初始化。如果某个瓦片区域没有内容（即未初始化），则需要利用差异的颜色或标记（例如灰色）来表示这些区域。这有助于在调试时看到哪些部分是空的，哪些部分是有效的。
    
  
  
• 处置惩罚无效瓦片：
  
  
  
  • 当访问瓦片地图时，如果某个区域没有被初始化或不包罗任何内容，可以将其标记为无效瓦片。当前如果返回值为零，就意味着该位置没有瓦片。在绘制时，可以选择不绘制这些无效区域，避免浪费性能。
    
  
  
• 瓦片的差异值：
  
  
  
  • 当前的地图利用数值来表示差异类型的瓦片。例如，0 代表没有瓦片（空缺区域），1 代表可行走区域（或地面），而 2 可能代表墙壁或不可通过的区域。这些值可以用来定义差异的瓦片类型和其举动。
    
  
  
• 存储和数据布局：
  
  
  
  • 讨论中提到，当前的瓦片存储方法并没有涉及到现实的存储布局和优化。瓦片存储需要更多的考虑，因为随着地图的复杂性增加，瓦片地图的存储需求和数据量也会变得更加庞大。可能需要考虑怎样优化存储布局，以更高效地管理这些数据。
    
  
  
• 下一步工作：
  
  
  
  • 下一步可能是进一步考虑怎样设计和优化这些瓦片地图，特别是在存储和访问瓦片数据时，怎样平衡性能和可扩展性，避免无效区域的绘制，并使地图可以更高效地加载和渲染。
    
  
  

仅在某些位置生成房间 - 随机数的利用

• 天下布局与坐标定义：
  
  
  
  • 当前天下的坐标体系定义了天下的范围，然而并没有对全部位置的瓦片举行定义。例如，某些区域可能没有瓦片或内容，返回值为零。
    
  • 提到天下是“环形的”（torodial），即如果从一边走出会从另一边重新出现，这种设计意味着天下的左右界限是连接的。
    
  
  
• 生成房间的计谋：
  
  
  
  • 当前的想法是，只在某些地方生成房间，而不是遍历整个天下生成房间。这样可以减少计算量，并控制房间的分布，使天下变得更加有序和合理。
    
  
  
• 随机数的利用：
  
  
  
  • 在生成房间时，讨论了随机数的利用。筹划利用某些方法生成随机数字来决定哪些位置生成房间或举行其他操作。
    
  • 提到可以通过利用 C 运行时库来生成随机数，但也在考虑其他方式来生成随机数字，不肯定依赖 C 库。
    
  
  
• 屏幕绘制与布局：
  
  
  
  • 提到当前的屏幕布局是一个 32x32 的瓦片网格，而在优化时，考虑到画面表现数量增加的环境下，怎样使得天下更加高效。
    
  • 筹划将屏幕的生成从简单的循环播放改为更加动态的、基于随机数的方式生成屏幕。生成的屏幕数量将从 32 增加到 100，且不再按固定次序分列。
    
  
  
• 选择和移动屏幕：
  
  
  
  • 接纳随机方式选择屏幕的位置，而不是简单地按照索引次序分列屏幕。例如，可以选择一个随机位置创建一个屏幕，并根据随机数字选择下一个屏幕的位置。
    
  
  
• 屏幕数量与逻辑：
  
  
  
  • 最初的设计利用了 32 个屏幕，但如今筹划增加屏幕数量至 100。新的生成方法将基于随机数来决定屏幕的位置和生成的次序，而不再是按固定的次序举行。这种方法可以或许更机动地布置屏幕，进步游戏天下的多样性和复杂性。
    
  
  

总的来说，这段内容主要讨论了怎样通过改变屏幕的生成方式以及利用随机数来调解天下的布局和房间分布，以创建一个更加动态和复杂的游戏天下。
回到随机地图生成

• 场景描述：
  
  
  
  • 起首，讲述了一个“数字屏幕”或者“房间”的设计过程，房间有门，可以随机生成或调解。
    
  • 随机性在布局过程中起着重要作用，可以通过增加或减少屏幕的X或Y坐标来生成差异的布局。
    
  
  
• 随机选择：
  
  
  
  • 利用随机数生成器来决定选择房间的方向（例如，增加X或Y坐标）。
    
  • 接纳mod操作符来通过取余数来决定随机选择的结果，这通常用于生成二选一的环境，例如取余2，得到0或1。
    
  
  
• 随机数生成：
  
  
  
  • 提到了怎样生成一个随机数表，并利用一个随机数索引来选择数字。
    
  • 生成器需要在后续的天下生成中发挥作用。
    
  
  
• 实现与调试：
  
  
  
  • 随着体系开辟，出现了一些编程标题和调试细节，例如代码缩进标题和性能标题。
    
  • 讨论中提到了生成随机数时遇到的一些困难，以及尝试利用差异的技术来进步代码服从。
    
  
  
• 代码和算法：
  
  
  
  • 对话中涉及到利用宏（例如键盘宏）和文本模式来加速开辟，并批评了C++中的代码布局和调解。
    
  • 还讨论了怎样有效地举行编辑、代码格式化和宏利用。
    
  
  

整体来看，这段对话涵盖了房间布局生成的根本原理，特别是在步调中怎样通过随机数控制房间的分列，而且提到了生成器、调试过程以及优化方面的挑衅。如果需要更具体的代码示例或进一步的解析，随时可以告诉我！

随机生成的房间

还没有到达希罕的效果

怎样将一个本来存储整个地图的做法，转变为一个更加希罕的存储方式。起初，整个地图被预先分配了存储空间，但并没有现实填充任何数据，只是创建了一个巨大的区域。随着开辟的推进，目标是让地图数据的存储更加高效，只在需要的地方分配存储空间。
在实现过程中，接纳了16x16的块来划分地图区域，每个块只有在需要填充瓷砖时才会分配现实的存储空间。这种做法称为“懒加载”或“按需分配”，即只有在需要填凑数据时才举行存储分配，而不是预先为整个地图分配大量内存。
为了实现这一点，起首会检查是否有瓷砖需要存储，如果没有，则不会为该区域分配存储空间。只有在访问某个区域并发现该区域没有初始化时，才会为其分配存储空间。这样，内存利用更加高效，避免了存储不须要的空缺区域。
这种方法使得游戏天下可以更加庞大，因为不再需要为每个可能的区域预留大量的内存。只有现实可见或需要的数据才会被存储，其他地方则不占用内存。这种“希罕存储”的方法减少了内存的浪费，而且可以轻松扩展天下的规模。
终极，通过这种方法，存储变得更加高效，玩家也不会察觉到天下的其他部分的存在，除非他们现实进入并加载这些区域。

制作门

在这个逻辑中，主要任务是实现一个体系，管理屏幕之间的门生成和墙绘制逻辑，而且确保这些门和墙的布置可以或许动态地适应屏幕的布局和随机选择。

---

• 门的位置随机性
  
  
  
  • 在进入屏幕时，体系会随机选择门的位置。
    
  • 每个屏幕的门布置需要根据相邻屏幕的门状态来动态调解。例如，如果左侧有一扇门，那么这个屏幕的右侧也需要有一扇门以保持连通性。
    
  
  
• 门和墙的初始化
  
  
  
  • 利用逻辑判定，确定当前屏幕的界限（顶部、底部、左侧、右侧）是否需要绘制墙或生成门。
    
  • 如果界限在中心区域且需要生成门，那么会绘制一扇门；否则会绘制一堵墙。
    
  
  
• 逻辑设计要点
  
  
  
  • 在生成门时，必须确保上一屏幕的门状态被精确传递到下一屏幕。例如，如果当前屏幕右侧有门，那么相邻屏幕的左侧也需要有对应的门。
    
  • 对于顶部和底部界限，同样的逻辑适用。
    
  
  
• 代码的改进点
  
  
  
  • 初始逻辑是基于条件判定和剪切复制的代码，虽然可以工作，但不敷优雅。
    
  • 可以通过优化条件判定，减少重复代码，使逻辑更加简洁和清楚。
    
  
  
• 测试与调试
  
  
  
  • 在完成根本功能后，对生成的门和墙的布局举行测试。
    
  • 确保门的生成逻辑与相邻屏幕的需求一致。
    
  • 修正了一个门生成错误，具体标题在顶部门的条件判定中，因符号错误导致逻辑失效。
    
  
  
• 现实运行结果
  
  
  
  • 完成了根本的门和墙绘制功能，可以或许根据屏幕布局生成合理的门。
    
  • 体系可以动态调解屏幕间的连接，确保每个屏幕的布局与随机性生成逻辑匹配。
    
  
  

---

这个逻辑主要实现了屏幕布局的动态生成，并通过门的随机性加强了地图的可玩性，同时保证了屏幕之间的连通性。

回到表现单个房间的状态

从一个近距离的视角观察，可以想象如果摄像机被锁定在某个位置，玩家只能看到摄像机前的区域。在这种环境下，玩家不会心识到天下的外部是怎样被存储的，因为他们永世看不到天下之外的部分。现实上，虽然天下的外部并未被存储在玩家视野中，但玩家会被引导去认为这个天下是无缝存在的，现实上天下的外部并没有被完全渲染出来。
为了避免让玩家察觉这一点，如果需要让摄像机平滑滚动至其他区域，我们可以通过设计一个“围绕房间”的空间填充来确保无论摄像机怎样移动，都有东西供玩家查看。通过填充这些空缺区域，可以使玩家始终看到一些内容，即使他们看不到现实的天下。
如果不想这样做，也可以接纳另一种计谋。当到达某些没有内容的区域时，可以随机生成一些图像或配景来填充这些区域，而不是让玩家看到空缺区域。这样做可以在视觉上维持一致性，并给玩家一种完整天下的错觉。
在设计这些瓦片地图时，目标是通过平铺数据来填充天下，即使这个天下并不完全被储存，也能让玩家认为它是无缝的。通过精心设计这些瓦片，可以确保当玩家走到某个地方时，他们不会注意到天下的界限。
整体而言，通过这种设计，可以确保玩家在探索虚拟天下时，体验到一个流通且持续的游戏环境，而不必担心地图的巨细或设计上的限定。通过对空间和视觉的精心布局，可以保持游戏的沉浸感。
此时的地图已经相当大，虽然在测试时，穿越一百个屏幕需要相当长的时间，但这也显现了游戏天下的广阔。而这些测试图形本身，更像是展示游戏焦点功能的工具。它们提醒人们，曾经的经典冒险游戏也用了类似的技术。那些早期的游戏在视觉上看起来简单，但依然可以或许给玩家带来深刻的体验。尤其是“冒险”这款经典游戏，它通过非常简单的图形和有限的资源，依然可以或许吸引玩家投入大量时间，探索这个简单但充满乐趣的天下。
瓦片地图的回顾

如今，瓦片地图已经根本完成，接下来是讨论怎样优化和改进这一实现。起首，瓦片地图的尺寸可以机动调解。一个关键点是，我们不再需要将瓦片巨细与像素巨细绑定在一起，因为瓦片地图本身不需要关心像素的具体细节，它只是一个抽象的表示。瓦片的巨细和像素之间的关系不再重要，因此应该将这种绑定关系移除。通过这样做，我们能让瓦片地图独立于现实的像素渲染，从而让地图的存储和渲染变得更简洁。
接下来，考虑到存储服从，提出了一个虚拟化的瓦片存储方式。当前的体系在处置惩罚瓦片时仍存储一个包罗指针的数组，而这些指针指向现实的瓦片数据。这样，只管整个天下的巨细可以非常庞大，但现实上我们只存储了小块区域。存储时，天下的每个区域并不是全尺寸的，而是分成了较小的“块”举行存储，类似于一个二维指针数组来表示天下的瓦片。
通过这种方法，可以在有限的存储空间内管理一个非常大的天下。例如，如果当前天下的巨细是四十亿瓦片，那么只存储16x16的区域块。这种分块存储的方式大大减少了内存占用，因为我们只存储须要的区域数据而非整个天下的每个瓦片。
然而，只管这种方式节省了大量内存，但仍然有优化空间。如果能进一步减少存储的数据量，体系将变得更加高效。为了到达更高的希罕性，可以考虑进一步优化存储方法，例如通过“真正的希罕存储”方式，仅在需要时动态加载和存储数据，而不是将每个可能的区域都事先分配好。这种方式可以极大减少内存斲丧，尤其是在处置惩罚大规模天下时。
终极，虽然当前的存储方式已经通过指针数组减少了内存占用，但为了到达最优的希罕性，可能还需要进一步探索差异的存储计谋，比如基于空间位置的希罕查找方法。这些方法可以确保只在须要时加载和存储瓦片数据，从而最大化内存利用率和处置惩罚服从。

添加上下楼梯的功能

在开辟都会地图时，添加了对Z轴的支持，以便能处置惩罚上下条理。这个修改的目标是使地图可以或许处置惩罚多个高度条理，在这种环境下，Z轴代表着垂直维度。增加Z轴的功能不难，主要是通过给地图增加一个“上下”移动的能力来实现。最初，Z轴只是一个附加的概念，用来支持更复杂的地图条理布局。
这个过程中，Z轴并不会像X轴或Y轴那样直接影响地图的存储方式，因为通常我们不需要在任何时刻查看多个Z层。对于大多数环境来说，Z轴层是分离的，与X和Y轴的操作有所差异，通常代表着“上下”之类的条理移动，而不是二维空间中那样的平面划分。
接着，修改了地图存储的方式，将Z轴作为一个附加的维度来处置惩罚。具体来说，存储时，Z轴会对每个瓦片举行标记，将其与X和Y坐标联合，使得每个瓦片都能具备一个高度属性。这样，Z轴的操作和存储方式需要特别处置惩罚，尤其是在获取或设置瓦片值时，每次都会附加Z轴信息。
这个过程中，为了便于操作，接纳了三维坐标的存储方式，而不是简单的二维平面。将X、Y和Z联合后，形成了一个三维空间，使得可以更清楚地表示差异条理的瓦片。在存储时，X轴表示横向，Y轴表示纵向，而Z轴则用于表示上下的层级关系。每次移动Z轴时，都会跨越一整块X和Y的区域。也就是说，Z轴的移动代表着在三维空间中的“跳跃”，每次上升一个Z层就会改变当前可见的瓦片。
总体来说，添加Z轴的支持可以或许为地图带来更多的条理布局，使得都会地图更加立体和复杂。而这个修改并不会引入太多新的复杂性，因为主要的操作还是围绕着传统的二维瓦片地图展开。

继承疯狂地增加一些楼梯

这段文本描述了一段代码调试的过程，涉及到随机选择和门状态控制等标题。下面是具体的总结和复述：

• 开始时，主要关注的是一个与随机选择相干的逻辑，用于处置惩罚某种网格或地图体系。随机选择操作从三个选项中选择一个，每个选项代表一种可能的动作或结果。根据随机选择的结果，触发差异的条件。
  
• 尝试根据随机选择的结果设置差异的动作和条件，具体条件与门的状态相干。例如，当条件即是“二”时，实行某些特定操作；否则，根据差异的条件切换样式或其他变量。条件好像关注门是否存在，以及门的“向上”或“向下”状态，这可能是与游戏机制或关卡元素相干的设置。
  
• 在某一时刻，逻辑涉及设置门的状态，确保某个房间内没有出口，或者根据需要调解瓦片或其他对象的状态。
  
• 接下来，代码检查某些属性（如库存）是否相当，并根据条件触发相应的操作。代码中出现了一个明显的错误，导致门的状态出现非常举动，可能是由于设置不当或逻辑流程错误。
  
• 还有对网格中的瓦片位置（X、Y、Z坐标）举行处置惩罚，处置惩罚“向上”和“向下”门的状态。标题在于确保状态精确转换，避免门被错误地放置或操作。
  
• 调试过程中发现与“门”状态相干的错误，门的状态切换好像存在故障，导致一些预期条件没有得到满意。
  
• 在回顾这些举动后，认为标题可能出在门的切换逻辑上，或者是某些条件值（如库存或瓦片条件）的设置错误。只管面临这些挑衅，仍在尝试通过追踪逻辑找到标题的根源并解决它。
  
• 调试过程涉及大量的试错，目标是修正因随机选择逻辑和瓦片处置惩罚导致的错误，尤其是与门状态和瓦片条件相干的标题。
  

焦点标题是确保门的放置和状态转换符合预期，同时排查在随机选择和瓦片管理中的错误。整个过程强调了在处置惩罚网格或体系中的状态变化和交互时的复杂性，特别是当涉及随机结果和特定条件时。

你会利用德摩根定律（DeMorgan’s Laws）吗？

这段对话讨论了布尔表达式的简化，特别是涉及德摩根定律和真值表的利用。以下是具体总结：

• 德摩根定律和简化布尔表达式：
  
  
  
  • 德摩根定律指出一些常见的布尔表达式等价关系，例如：not (A and B) 等同于 not A or not B，这可以帮助简化复杂的布尔表达式。只管这是一种有效的简化方法，但现实中不常用，尤其是在编写代码时。
    
  
  
• 实践中的做法：
  
  
  
  • 在现实编程中，简化布尔表达式并不是常见的做法。通常环境下，开辟者倾向于将代码保持简洁和直观，只管通过清楚的表达式让代码易于明白，而不是为了优化布尔运算的数量去做过多简化。
    
  • 在很多环境下，编译器会自动优化这些布尔表达式，因此手动简化的须要性较小。
    
  
  
• 编译器的优化作用：
  
  
  
  • 开辟者倾向于依赖编译器来处置惩罚这类优化工作。编译器通常可以或许自动实行这些优化，从而减少开辟者的工作量。因此，简化布尔表达式的主要工作交给编译器完成，而开辟者则更多关注代码的可读性和表达清楚性。
    
  
  
• 语言学简化的优先级：
  
  
  
  • 开辟者更注意语言表达的简洁性，而不是优化布尔运算的数量。清楚的表达式让代码更易于明白和维护，因此在写代码时，开辟者倾向于利用更直观的表达式。
    
  
  
• 真值表的利用：
  
  
  
  • 真值表是一种帮助分析和简化布尔表达式的工具，通过列出全部可能的输入条件并计算每种环境下的输出，帮助相识布尔逻辑的举动。只管这是一种理论上有效的方法，但现实上并不常用。
    
  • 真值表类似于电子表格，其中列出全部条件，并分析每种条件组合下的布尔表达式结果。
    
  
  
• 总结：
  
  
  
  • 总体来说，虽然德摩根定律和真值表是有效的工具，但在现实编程中，简化布尔表达式更多依赖编译器的优化，而开辟者则倾向于关注代码的清楚表达，而不是手动举行布尔运算的简化。
    
  
  

将瓦片地图放入 3D 维度，这是否与体素八叉树算法有关？

• 三维空间和算法：
  
  
  
  • 提到将时间纳入三维空间，虽然这种想法可能不直接相干于某个特定算法（如 “Vauxhall Autrey Algorithm”），但讨论的重点是怎样明白空间的分割与优化。
    
  • 在三维空间中，提到可以将一个体积分割为多个部分，例如将一个立方体划分成八个较小的立方体。这种操作有点像魔方的分割，可以进一步提拔每个小立方体的分辨率。
    
  
  
• 在三维空间中填充：
  
  
  
  • 讨论了在三维空间中怎样以无偏的方式举行空间填充，即确保在全部维度中都有均匀分布。这种方法在某些环境下非常有效，尤其是在处置惩罚三维空间时，避免某一维度不均匀填充。
    
  
  
• 游戏天下的空间划分：
  
  
  
  • 对于游戏天下，尤其是在二维游戏的上下文中，这种三维分割的概念并不总是适用。二维游戏通常会集中于几个“切片”或“视图”，而不是三维空间的完整填充。
    
  • 游戏的天下划分通常依赖于视角和地牢布局。例如，可能会查看地牢的底层或顶部，或者观察肯定命量的“切片”而不是全景。
    
  
  
• 二维和三维视角的差异：
  
  
  
  • 在二维游戏中，三维的空间划分并不总是有意义，因为大多数游戏天下的视角和条理布局较为简单，通常只处置惩罚较少的高度或深度。这里的讨论强调了二维与三维游戏中空间处置惩罚的差异。
    
  
  
• 树形布局的局限性：
  
  
  
  • 提到在游戏天下划分中，利用树形布局来分割空间并不总是最优选择，特别是当游戏涉及到复杂的天下布局时。树形布局可能在某些三维游戏中有效，但在处置惩罚大规模、复杂的二维或多维地图时可能并不高效。
    
  
  

总的来说，这段讨论将三维空间的划分和优化技术与游戏天下的设计举行了对比，探讨了在差异类型的游戏中怎样有效地应用这些概念。
为什么区块巨细设置为 2 的幂次？

这段对话深入探讨了算法优化和存储布局，特别是在处置惩罚数据块巨细和查找操作时的选择。以下是具体总结：

• 块巨细与2的幂：
  
  
  
  • 讨论了利用2的幂作为块巨细的原因。这样做是因为在查找操作中，利用移位和掩码（shift and mask）可以高效地分割数据。这种方法仅在块巨细为2的幂时有效，因为移位和掩码操作可以或许快速地提取数据的高低位部分。
    
  • 如果块巨细不是2的幂，就无法利用这种优化方法，可能需要利用通例的除法和余数操作（divide and remainder）来代替。这样的方法虽然能完成相同的任务，但服从较低，因为需要举行除法运算。
    
  
  
• 移位与掩码：
  
  
  
  • 通过移位操作，可以将数据分割成两个部分：一个是块的高位部分，另一个是低位部分。这个过程依赖于块巨细是2的幂的条件，因为这使得移位操作变得简单且高效。
    
  • 这使得块的划分非常清楚，且能高效地举行索引。每次取余数来确定某一部分的数据（比如瓷砖的索引），而通过移位操作来确定命据的其他部分。
    
  
  
• 替代方案：除法与余数：
  
  
  
  • 如果不利用2的幂，理论上可以通过通例的除法和余数操作来举行划分。虽然这种方法可以工作，但其性能通常不如移位和掩码高效，尤其是在需要频繁举行查找操作时。
    
  
  
• 性能调优与选择：
  
  
  
  • 讨论了在性能优化过程中做出的决策，强调在开辟游戏引擎时要只管避免做出那些会限定未来选择的设计决策。例如，某些操作可能并不需要特别快，但在某些环境下为了更好的存储和机动性，接纳简单的除法和余数操作也是可行的。
    
  • 重要的是，在开辟过程中要确保可以或许保持机动性，以便未来可以或许根据需要调解优化方案，避免过早地做出决策导致无法后续调解。
    
  
  
• 存储与操作的平衡：
  
  
  
  • 在决定利用哪种优化方法时，需要权衡存储的服从和操作的速率。如果存储是主要考虑因素，那么可以担当稍慢的操作，以减少对存储空间的需求。
    
  • 反之，如果操作速率更为重要，可能需要继承利用2的幂作为块巨细，利用移位和掩码来优化性能。
    
  
  

总之，这段讨论的焦点在于怎样平衡存储优化与操作服从。在设计和开辟时，必须考虑性能需求，同时保持机动性，以便在现实实现中根据具体环境做出最佳选择。
什么时候会利用 #define 而不是局部变量？

这段对话探讨了利用全局变量的环境及其优缺点，尤其是怎样在差异的情境下决定是否定义全局变量。以下是具体总结：

• 定义全局变量的时机：
  
  
  
  • 利用全局变量是否符合，取决于具体的需求和环境。在某些情境下，利用全局变量可能是一个很好的选择，但没有唯一的“精确”或“错误”的答案。关键在于明白利用它们的差异，并据此做出选择。
    
  
  
• 全局变量的类型标题：
  
  
  
  • 无类型变量（如常量）：在某些环境下，利用没有类型的全局变量（例如常量值）可能是有利的。这样做的一个利益是这些变量可以在任何地方利用，而不需要明白的类型定义。对于一些不需要类型束缚的操作，这种方式非常机动。
    
  • 有类型的变量：然而，如果你需要对数据举行类型控制，尤其是需要确保某些操作只在特定类型（如无符号整数、浮点数等）下举行时，定义全局变量的类型是非常重要的。一个例子是，如果你希望某个值只能在特定环境下（如只有在 UN32 的环境下）利用，明白的类型定义可以避免错误发生。
    
  
  
• 移除类型的优缺点：
  
  
  
  • 优点：没有类型的全局变量可以直接插入表达式中，使得代码更加机动。这种方法适用于那些不需要对数据举行类型严格控制的环境。
    
  • 缺点：没有类型也意味着在某些环境下，可能会导致数据利用错误。例如，如果一个无符号 32 位数（UN32）被错误地用于不得当的场景，可能会导致步调错误。为了避免这种环境，可能需要对变量举行类型转换或额外的类型检查。
    
  
  
• 全局变量的具体应用场景：
  
  
  
  • 在某些环境下（例如利用浮点数后缀或需要特定的类型），全局变量可以帮助确保变量有一个明白的类型。例如，如果想要一个八位类型的全局变量，可能就需要通过显式定义类型来确保其巨细和特性。
    
  • 例子：如果需要利用某些操作（如浮点数运算）而该操作只适用于某种类型，定义类型明白的全局变量就可以或许确保数据的精确性。
    
  
  
• 机动性与限定：
  
  
  
  • 全局变量有助于在不需要特别精细控制类型的环境下实现机动性，但偶然需要明白类型以避免潜在的错误。在某些复杂场景中，无法简单地依赖类型推断，必须利用强类型定义。
    
  
  
• 总结：
  
  
  
  • 总的来说，利用全局变量是否符合取决于应用场景。如果不需要严格的类型控制，利用无类型的全局变量可以进步机动性；如果需要控制数据类型，则需要明白地定义全局变量的类型。每种方法都有其适用的场景，且没有绝对的“精确”与“错误”。
    
  
  

为什么会偏好利用瓷砖区块数组？

• 内联变量的利用：
  
  
  
  • 对于内联变量的标题，提到并未利用内联变量。没有明白说明为何不利用内联变量，主要是因为相干的概念并不在当前讨论范围内。
    
  
  
• 为什么不用位标志（bit flags）表示门的状态：
  
  
  
  • 标志通常用于表示二进制状态，但当前的游戏设计并不适用这种方法。原因是，目前的地图还未完成设计，也未明白怎样存储这些地图信息。门只是用一个数字表示，以便举行测试，并未深入实现。
    
  
  
• 为什么不利用简单的传送门：
  
  
  
  • 在某些环境下，传送门可以简化游戏的设计，使玩家在地图的差异部分之间移动。但如果只是利用传送门，无法满意更复杂的游戏需求。例如，传送门无法处置惩罚玩家看到的天下多少形状与现实地图之间的关系。想要展示多个房间或差异楼层之间的接洽，简单的传送门机制就不敷用了。
    
  • 游戏需要一个更加持续和一致的天下，其中的每个部分都能通过多少方式举行查询，从而保证更复杂的互动和场景切换。例如，玩家可以从一层看到另一层的内容，这种设计无法通过简单的传送门来实现。
    
  
  
• 游戏天下的多少布局：
  
  
  
  • 游戏天下的设计应答应玩家在一个连贯的多少天下中自由移动，这样不仅可以或许表现多个区域，还能处置惩罚复杂的互动。例如，假设游戏中有一个脚色能粉碎墙壁，产生洞口，玩家能看到并进入这些新的空间。为了实现这一点，游戏需要知道这些空间是怎样通过地图相连的，而不是依赖于传送门或其他不反映真实地理关系的设计。
    
  
  
• 关于声音流传的例子：
  
  
  
  • 声音流传是另一个体现游戏天下多少布局的重要元素。假设玩家站在墙壁旁，能听到另一房间内的声音，尤其是像老板怪物这样的强大存在。如果体系仅仅依赖于传送门，那么就无法处置惩罚这种墙壁穿透声音流传的标题。因此，游戏设计必须具备可以或许处置惩罚空间连接的多少方式，以便在复杂的环境中举行精确的声音流传。
    
  
  
• 为什么利用“块”（Chunks）而不是简单的传送门：
  
  
  
  • 游戏设计希望能以一种多少化的方式查询和展示天下。利用“块”可以将虚拟天下分成较小的单元，在需要时可以通过多少方法查询这些单元。而不必担心将整个天下存储为一个庞大的数组或数据布局。这样设计的优势是既能保持天下的一致性，也能让天下保持更大的扩展性。
    
  
  

是否筹划按需加载/卸载瓦片区块？

这段讨论主要涉及了内存管理、分页计谋和游戏天下的加载与卸载。以下是具体总结：

• 加载和卸载天下数据：
  
  
  
  • 关于游戏天下的内存管理，提到天下的数据（如瓦片块）可能会保存在内存中，但也有可能根据需求举行加载和卸载。加载和卸载的操尴尬刁难当前设计而言非常简单，因为体系已经为这一点做好了准备。
    
  • 如果某个瓦片块没有在内存中，可以通过分页将其加载到内存中。这种加载方式非常机动，且几乎不影响性能。
    
  
  
• 分页方案：
  
  
  
  • 分页（paging）指的是按需加载数据块的方式。在当前方案中，数据块的加载与卸载几乎是无成本的，但仍有一些复杂的操作需要避免过于简单地举行分页。
    
  • 如果需要更复杂的分页方案，比如根据需求动态加载或卸载数据（需求分页），这个过程理论上非常简单，只需大约30分钟的时间举行调解。然而，目前尚不确定是否真的需要实施这种复杂的分页计谋。
    
  
  

是否筹划让瓦片地图分层？

这段讨论涉及到代码的复杂性和未来的筹划，特别是在生成游戏天下时的暂时解决方案。以下是具体总结：

• 代码的复杂性：
  
  
  
  • 游戏的终极步调代码看起来非常复杂，尤其是语言层面的改动非常难以实施。这可能指的是代码的现有布局或设计，使得任何语言上的修改都需要较大的工作量。
    
  
  
• 暂时的农村生成代码：
  
  
  
  • 在开始举行天下生成（尤其是墟落区域）之前，现有的代码只是作为一个暂时解决方案存在。当前的目的是为测试都会地图（town map）提供一个简单的根本，确保可以或许在更广泛的天下范围内举行测试。
    
  • 目前的代码并没有做任何现实的删除或优化，只是用来举行初步的测试。这段代码并不代表终极的设计方案，而只是暂时的过渡阶段。
    
  
  
• 未来的筹划：
  
  
  
  • 这段代码被称为“垃圾”，意味着它在现实项目中不会被利用。它只是一个过渡性工具，用于测试和验证某些功能，比如都会地图的表现。
    
  
  

根本希罕瓦片地图存储是否需要压缩？

• 图形、物理和逻辑的分层：
  
  
  
  • 对于游戏的图形、物理和逻辑体系的分层，虽然可能存在差异的体系设计，但这些体系可能并不会完全分开，而是有肯定程度的合并。例如，图形和物理体系虽然是差异的部分，但它们之间不肯定会有完全分离，可能会在实现时合并在一起。这样做是为了机动性和便于修改。
    
  
  
• 资源切换和类型定义：
  
  
  
  • 在类型定义方面，倾向于利用较为简化的方法。例如，不利用特定的布尔类型，而是接纳整数类型来表示数据池，这样可以避免频繁的转换，减少性能开销。这种方式源自已往的习惯，即避免过多定义和视觉化的类型，从而简化了代码的书写和明白。
    
  
  
• 声音和平台的隔离：
  
  
  
  • 在声音管理方面，游戏的声音部分需要独立管理，以便在开始播放更多的声音时能有效地处置惩罚这些数据。同时，也有肯定的隔离意识，避免过多依赖平台特定的实现，保持肯定的机动性，以便更好地控制声音资源。
    
  
  
• 资源压缩和内存管理：
  
  
  
  • 对于资源巨细的担心，尤其是关于地图和艺术资产的巨细，虽然考虑过压缩计谋，但由于游戏资产（如大规模的地图和图像资源）可能非常庞大，压缩可能不会带来显著的效益。尤其是如果瓷砖地图本身造成了内存压力，压缩才可能成为一个值得考虑的方案。总体来说，艺术资产的巨细可能会限定压缩的有效性，因此压缩方案不肯定是优先选项。
    
  
  
• 内存压力和性能：
  
  
  
  • 对于游戏天下的巨细，预计不会对内存产生巨大的压力，但如果瓷砖地图的内存需求超出了预期，那么可以考虑利用一些技术来优化内存利用，例如压缩。这些决策将依据现实的资源需求和内存利用环境来调解。
    方法。
    
  
  

房间是否应该仅在玩家接近时才创建？

是否担心内存泄漏？

三目运算符欠好吗？

为什么无法保存完整地图？

主要观点：

• 希罕存储的挑衅：
  
  
  
  • 希罕存储（Sparse Storage）是指只在需要时才分配内存，避免预先分配过多空间。只管这种方法可以节省内存，但其代价是需要额外的计算和内存管理开销。随着资源减少，希罕存储的密集度会增加，这意味着管理变得更复杂，服从下降。
    
  
  
• 计算复杂度与存储的权衡：
  
  
  
  • 在大天下设计中，如果希望通过希罕存储减少内存占用，那么在存储管理方面需要付出更高的代价。直接存储和访问希罕天下中的数据可能会导致性能标题，尤其是在动态改变天下（如可粉碎环境）时，存储需求会激增。
    
  
  
• 优化的重点是最坏环境：
  
  
  
  • 游戏开辟中，通常优化的焦点应该是“最坏环境”，即当玩家处于复杂的环境中，屏幕上表现的内容是最为密集和复杂的，而不仅仅是优化那些玩家几乎不接触的区域。例如，只管优化那些不需要渲染的部分（如被墙壁遮挡的区域）看起来有意义，但如果忽视了最坏环境的优化（如大规模渲染的复杂环境），反而可能导致游戏性能标题。
    
  
  
• 内存泄漏与资源管理：
  
  
  
  • 在内存管理上，有些时候不需要过于担心内存泄漏的标题，尤其是当全部的数据都存储在永世存储中，而不常驻内存时。此时内存泄漏的风险较低，但如果在游戏中涉及到动态修改（如粉碎环境），那么数据存储和内存管理的计谋就需要更加细致。
    
  
  
• 巨型纹理（Mega Texture）：
  
  
  
  • 在设计大规模天下时，可能会考虑利用“巨型纹理”来存储完整的天下地图。但这种方法在内存中无法完全保存整个纹理，而是通过分页的方式，将需要的部分动态加载到内存中。巨型纹理的处置惩罚方式和存储方法，要求在运行时将纹理分割并根据需要加载部分数据，避免了将整个地图都加载到内存中的标题。
    
  
  
• 存储空间与游戏设计的平衡：
  
  
  
  • 在游戏设计中，必须在存储空间、内存管理和计算成本之间找到平衡。例如，利用希罕存储可以减少内存占用，但也可能导致存取速率的下降，特别是在大规模动态天下中。当房间或环境发生变化时，存储和管理这些变化的数据会变得更加复杂，乃至可能导致性能标题。因此，只管理论上可以保存整个地图，但由于内存限定和计算成本，现实开辟中通常选择动态加载和部分存储的方法。
    
  
  

总结：

这段内容深入探讨了大规模游戏天下中怎样处置惩罚存储和内存标题。关键在于怎样在保持游戏天下动态和可变的同时，优化内存利用和计算复杂度，特别是在需要存储希罕数据和应对动态变化时。
仓库 : https://gitee.com/mrxiao_com/2d_game

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。