游戏引擎学习第64天

代码改的我看的比较懵
原视频可以去这个网站去看
https://guide.handmadehero.org/

回顾我们在模拟区域方面的进展

在目前的情况下，如果有很多任务需要完成，可以进行分解。在昨天收到的改变中，决定将任务分解成模拟区域。模拟区域是可以随时创建的，它们涵盖了游戏世界中的某个区域，并且这些区域能够进行模拟。模拟之后，数据可以被写回。简而言之，数据被送入模拟器，进行模拟处理，然后返回。

重新组织实体结构

计划是将低实体和高实体的处理方式进行整合，避免频繁地引用两者。在当前的设计中，低实体和高实体分别存储不同的数据，其中低实体的存储版本是经过压缩的，而高实体则包含完整的数据信息。接下来，考虑将这两者合并成一个实体类型，通过复制和移转数据来简化设计。这样做的目的是为了简化原型设计过程，并减少存储和内存的开销。

在实践中，低实体将在存储时表现为一个压缩版本，仅包含需要的信息，而高实体将存储完整的详细数据。这种方式避免了在存储时的冗余开销，同时能够保持操作的简便性和高效性。最终目标是使系统更加灵活，避免处理低实体和高实体的二分法，简化开发过程，特别是在进行原型设计时。这种方法有助于减少内存占用，并保持系统的可扩展性和效率。

更新代码以便在低频实体中使用sim_entity

我们不希望看到低频实体出现在这个地方，因此需要去掉这个概念。在完成移植工作之前，我们会讨论这一点。接下来，我们将抓住这个机会，对实体的存储版本进行更新。对于低位置，我们需要更新它，因为这是仅针对低频实体存在的属性，这些实体是我们不希望在这里显示的。

此外，当前的位置将继续改变，但我们会将所有与位置无关的部分进行复制，除存储索引外。这样，我们将在不同的地方进行实体存储，而存储索引只有在需要时才会出现。

最终，我们将把这些数据进行压缩，并将其转化为新的结构。整体流程中，我们将不再关心存储额外的信息，而是聚焦于如何有效地存储和处理实体的核心数据。

设置实体的StorageIndex

我们发现，在处理实体时，存储索引没有正确设置，因此需要确保在添加实体时能够正确处理存储索引，特别是在存储低频实体时。当前，存储索引应该存储到低频实体中，这也是我们之前的错误。为了修正这个问题，我们将在调用添加实体时，将低频实体的信息正确地传递并存储。

接下来，我们还需要处理数据的解压缩步骤，而不仅仅是简单的复制。当前我们正在为实体处理位置存储，但一旦解压缩完成，位置的存储将不再是关键部分。在实际操作中，我们首先获取实体的源数据并复制，然后确保存储索引被正确设置。

通过这些步骤，实体的存储和处理过程将得到优化，避免了错误的存储和不必要的数据重复。最后，所有处理完的数据会传递到下一步操作，确保整个流程的顺利进行，并最终能够精确地更新实体的位置。

将实体相关内容移出game.h

我们需要继续推进，并开始处理实体相关的内容。首先，我们要抓取所需的数据，并查看剩下的部分。接下来，重点在于获取命中的得分点，这是我们关注的核心部分。最终，这些内容可能会被整合到实际的舱室或其他结构中，完成实体的处理和存储。

如何引用实体？

我们需要继续处理实体和模拟区域的问题。首先，我们在系统中存储了所有实体的信息，可能是经过压缩的。这些实体可能在不同的模拟区域之间进行转换，并且它们的位置会发生变化。在转换过程中，我们需要能够保持对实体的引用，并且确保我们可以从低索引转换到高索引。

为了实现这一点，我们需要通过交叉引用来管理不同区域中的实体。这意味着我们可能需要使用哈希表来存储这些引用，将低索引映射到高索引，以便我们能够正确访问实体。

当存储实体时，我们会将其转换为低频索引形式，并确保它可以在系统中持续存在。这样，无论何时需要，我们都可以访问对应的实体，例如像“剑”这样的对象。最终目标是能够顺利地在不同的模拟区域之间管理和访问这些实体。

创建entity_reference

我们可以创建一个小的联合结构，结合低索引和指针，其中指针指向实体的引用。通过这种方式，我们可以在需要时将实体的索引与实体引用结合。当加载这些实体时，引用会被拉入系统中；当它们离开时，引用会转化回索引形式。

这一方案似乎是合适的，它帮助我们在不同的模拟区域之间转换实体引用和索引，使得处理更为灵活。在试验阶段，我们将通过实践来决定这种方法是否可行，并且可以将实体引用按需映射和移除，类似于过去的处理方式。

在EndSim中填充entity_reference

在存储实体时，首先需要检查指针是否为零。如果指针为零，则不需要做任何操作，因为这意味着没有有效的实体引用。如果指针不为零，则会获取指向的实体的存储索引，并将其存储在对应的索引位置。这一操作过程非常简单和直接，不需要复杂的处理。

为了实现这一点，可以通过创建一个函数来处理实体引用的存储。在该函数中，首先检查实体引用指针是否为零；如果是零，索引也设为零；如果指针有效，则将指向的实体的存储索引存储到目标位置。这种方法非常高效，适合在需要转换和持久化实体引用时使用。

在BeginSim中加载entity_reference

当引入实体时，需要考虑哈希表的映射。假设某个实体有来源，若源实体存在，则需要将其映射到对应的索引。我们想要有一个机制，通过索引来获取实体的指针，并能够通过该指针来操作实体。

在实现时，如果引用的指针不为零，就需要进行相应的处理。主要的操作是根据索引获取实体，进而操作实体引用。为了保证引用的有效性，可能还需要进行额外的验证，确保指针指向一个有效的实体。

此外，考虑到哈希表的使用，目标是通过索引来映射到对应的实体，而这是一种简洁的映射方式。这样，我们就可以通过指针和索引的映射，便捷地访问和操作实体。

在更复杂的情况下，可能需要进一步考虑是否需要拉取其他引用的实体，尤其是在模拟区域中，可能涉及到其他实体的引用。这个过程取决于游戏逻辑的复杂度，因此需要根据具体情况做出决策。

总之，当前的目标是建立一个简单的映射机制，从而可以通过索引获取对应的实体指针，并确保引用的有效性，未来可能会根据需求进行更复杂的优化和扩展。

在添加实体时将实体映射存储在哈希表中

每次添加实体时，首先需要为该实体提供一个有效的存储索引。当前的要求是必须为每个实体提供一个有效的存储索引，并且存储索引不能为零。零存储索引不符合逻辑，因为它不代表有效的实体存储位置。

因此，应该断言存储索引总是有效的，并确保在不允许零存储索引的情况下，存储索引始终保持有效。如果将来需要改变这一规则，可以再考虑，但当前不允许这种情况。

接下来，对于每个实体，需要维护一个索引到实体的映射。通过这种方式，每个实体的位置将被准确记录。当访问该实体时，可以通过存储索引来快速获取相应的实体指针。这种映射是通过哈希表实现的，保证了从存储索引到实体指针的高效映射。

这样，当任何其他部分需要访问该实体时，只需查询存储索引，就能获取到该实体的指针，从而完成对实体的操作。这种方式实现了一个简单且有效的映射机制，使得实体管理变得更加清晰和高效。

实体映射哈希表的函数

我们继续编写两个函数：一个函数根据存储索引返回实体，另一个函数通过存储索引获取实体。这两个函数都需要接受相同的区域参数，用来查找对应的实体。第一个函数会根据存储索引返回实体，而第二个函数可能会返回一个指针，用于映射实体。

这些函数的实现是相对简单的，虽然我们可以将其设计成一个更通用的实体映射指针，但目前不确定是否需要这么做。可以在未来根据需要进行调整，代码可以后期提取和修改。

第二个函数不返回任何值，只是负责执行某些操作，如对偏移量进行处理。它本身并不返回具体的实体或指针，只进行偏移等必要的操作。因此，这两个函数的职责明确，一个用于返回实体，另一个用于处理偏移或其他操作。

创建实体映射哈希表

目前我们计划创建一个哈希表，用于快速查找实体。哈希表的大小需要合理设置，以确保能容纳足够的实体，并能够进行高效的查找操作。我们考虑将哈希表大小硬编码，但也意识到这种方法可能存在一些问题，特别是在处理零值时可能出现的问题。我们可能会考虑未来使用树形结构或其他更紧凑的方式来优化查找过程，尤其是在查找操作较少的情况下。

对于哈希表的实现，我们将通过索引直接访问哈希表中的元素，避免复杂的逻辑。尽管目前没有进行特殊的优化，我们也在考虑未来如何进一步改进此部分。

此外，我们还需要一个归零函数来清空哈希表中的内容，目前尚未实现该功能，但这是我们接下来的计划。归零函数对于确保哈希表在不再需要时能够被正确清空是很重要的。

哈希表的内部链接

在哈希表的实现中，考虑了使用内部探查（internal probing）而不是外部链式哈希（external chaining）。内部探查意味着如果一个槽位已被占用，系统将依次寻找下一个空的槽位，而不是将新的元素链到已存在的元素上。这种方法通过在哈希表中顺序地寻找空位来解决冲突。

虽然内部探查在这种情况下是最简单的实现，但为了提高性能，未来可能会考虑使用质数来决定跳跃步长，或者探索其他哈希表优化技术。当前并不关注这些性能优化问题，目标是先实现最基本的功能，之后再根据需要进一步优化哈希表的性能。

实现GetSimEntityFromIndex

上述内容讲解了哈希表的使用与处理过程，涉及索引查找、哈希值计算、探测机制以及如何处理空槽。具体步骤包括：

1. 索引查找：首先根据哈希值查找哈希表中的相应索引，确保返回的结果是有效的。如果索引为零，则表示该槽为空，不可用。

2. 探测机制：采用顺序探测法查找哈希表中的项。若哈希值所在的槽为空，则继续向后查找，直到找到合适的位置或哈希表已满。

3. 偏移量：对哈希值进行偏移，以便查找表中更精确的位置。通过位运算确保查找的槽是有效的，并且避免数组溢出。

4. 处理冲突：如果碰到相同的哈希值（即哈希冲突），则通过探测机制检查并更新值，确保每个条目都能正确存储。

5. 返回结果：找到对应索引后，直接返回该位置的值。如果槽为空，则进行适当的处理（例如返回空指针）。

6. 递归调用：在添加实体时，可能需要递归地从索引中获取对应实体，并处理相关的逻辑。这个过程确保了哈希表在动态更新时能够正确处理每个索引的存储。

7. 优化设计：通过位掩码和幂次方的数组尺寸来优化哈希表的性能，确保数组大小为2的幂，这样有助于提高查找效率和减少冲突的可能性。

这些步骤说明了如何高效地实现哈希表，并通过不同的优化手段提高性能，避免常见的哈希冲突问题。

实现MapStorageIndexToEntity

在这个过程中，首先将一些事情整理好，为了处理某些问题，先把一些内容放在一起。这就像是一个目标的一半，确保在处理数据时做到有序。在存储某个实体时，目的是在做同样的事情，即从存储索引中获取哈希表，这实际上是从存储索引中获取哈希的一种方式。

接下来，需要确保正确地处理存储条目的映射。如果已经存在某些条目，可能不需要做任何修改，或者在某些情况下，根本不关心。如果已经开始存储了相应的条目，可以简单地验证存储索引和条目之间的匹配，确保它们一致，或者如果不一致，进行适当的处理。

然后，在处理过程中，要确保条目可以被正确地存储，可能会涉及更新或者修改相关的比特数据。这个过程的目的是确保能够顺利存储和更新数据，而不出现错误。

接下来，进入哈希表时，创建一个条目并确保存储索引能够正确地映射到相应的数据。当有人询问这个存储索引时，系统能够返回正确的数据，从而继续进行后续的处理。

总的来说，这一过程看起来相对简单，涉及的是对存储条目的初始化和映射验证，确保系统能够正确处理数据存取和更新。

递归加载实体

这段话描述了在处理游戏实体时的一个复杂流程，涉及引用加载、实体映射、递归调用等多个步骤。具体内容可以分为以下几个部分：

1. 引用加载与映射：首先提到需要处理实体引用的加载。如果某个实体引用还未加载，会尝试加载该实体并为其创建哈希值。若该实体已存在，系统就可以直接使用。重点是确保引用的索引有效，防止对尚未加载的实体进行操作。

2. 递归操作：由于某些情况下加载一个实体时可能会引发对其他实体的加载需求，因此出现了递归调用的情形。递归的目的是确保所有需要的实体都能被正确加载和映射。这部分可能会带来一定的复杂性，需要特别注意如何管理递归过程。

3. 实体索引与存储：在处理过程中，实体的索引会被映射到具体的存储单元。这个存储单元保存的是实体的具体信息，一旦一个实体被加载，就会立刻映射到相应的索引上。这样做的目的是为了确保实体在需要时能够被快速访问。

4. 翻译与转换：一旦实体的索引和引用加载完成，还需要将索引转换为指针。这一过程是将旧的参考文献（例如之前的索引）转换成新的指针形式，以便后续操作能够更加高效地使用这些实体。

5. 递归加载与扩展：加载的过程中，可能会发现其他需要加载的实体，因此系统会继续递归调用，直到所有需要的实体都被正确加载并映射。这样做的目的是为了不断扩展模拟的范围，确保模拟过程中的实体是完整且准确的。

总之，这个流程涉及多个关键操作，包括实体引用的加载、实体的索引管理、递归调用的使用以及实体信息的转换等。整体目的是确保实体在模拟过程中能够正确、有效地被加载和使用。

处理编译器错误

在当前的调整中，我们可能遗漏了一些内容，因为同时进行了多项修改。这种情况在复杂的开发过程中是难以避免的。
我们需要检查一些核心逻辑。例如，计算涉及半值、偏移量以及重新调整的比例。当前的实现可能存在一些细节需要进一步优化。
同时，还发现了一些拼写错误，例如错误的箭头符号和引用。这些细微的错误虽然不影响核心逻辑，但清理这些问题有助于代码的可读性和维护性。
此外，对于存储实体引用的部分逻辑，我们需要进一步检查其是否按照预期执行。在当前的结构中，这些问题的根源可能与代码组织不够清晰有关。
接下来，我们会继续对这些问题进行逐一处理，确保每个模块的实现都符合整体逻辑需求。清理这些细节将帮助代码更加简洁高效，并为后续开发提供稳定的基础。
image-905.png

更新摄像机跟随代码

在当前的实现中，我们进行了多个功能的完善和简化。以下是关键的调整和优化：
我们首先定义了一个简化的流程，用于加载和检查实体引用。具体来说，新增了一个通过存储索引检查实体存在性的功能。这个功能通过传递存储索引和区域，直接检查实体是否存在于集合中。如果存在，则直接返回相关的条目信息，而无需额外处理其是否为空。这样实现了更清晰和直观的逻辑。
对于相机跟随实体的功能，我们在逻辑上简化了实现。通过检查相机跟随的实体是否位于相同的区域中，决定是否更新相机的位置。如果不在相同区域，则无需额外处理。这样的优化提升了效率，并且逻辑变得更加直接。
此外，我们还重新审视了一些不必要的函数调用。例如，一些冗余的调用已经被移除，因为其功能已经可以通过更简单的方式实现。相机的设置功能也得到了精简。原本的“设置相机”调用主要用于完成映射操作，但现在这些操作已被整合到新实现的逻辑中。最终，“设置相机”调用被移除，因为其功能已经被新的流程完全取代。
优化过程中还发现了一些额外的代码清理需求，例如删除多余的变量和注释，使代码更加简洁。通过以上的调整，整体逻辑得到了改进，代码更高效且容易维护。
总结而言，我们优化了实体检查与相机跟随逻辑，并移除了不必要的调用与模块，使代码更加简洁、直观，同时提升了运行效率和可读性。

处理编译器错误

我们在这里进行了几个逻辑的调整和优化，主要围绕模拟区域（sim）映射和实体管理展开。

首先，明确了模拟区域（sim）映射的逻辑。这部分的优化目标是让映射的流程更简单有效。例如，通过使用统一的指针处理大部分逻辑，降低了代码复杂性，使许多操作可以直接与模拟区域的指针相关联。这种方式为未来可能的扩展打下了基础，比如在相似的逻辑中添加更多的内容。

对于实体移动的处理，现阶段需要对原有逻辑进行更新和简化。虽然具体细节会在稍后处理，但这部分将极大优化实体的移动方式，从而提高代码的可读性和效率。

在新增实体（如剑）的流程中，我们通过简单的索引机制将其添加到系统中。在这一流程中，当前的需求只是为新增的粗略类型设置相应的属性，逻辑并没有太多复杂性。

此外，明确了低频实体的管理方式。在处理这些实体时，逻辑得到了进一步的优化，通过减少不必要的复杂步骤，使得这部分流程更加直观。

整体来看，此次调整主要集中在以下几个方面：

1. 模拟区域映射的简化：通过统一指针的处理方式，减少了冗余逻辑。
2. 实体移动逻辑的优化：明确需要调整的部分并计划进一步简化操作。
3. 新增实体的流程：通过索引机制直接管理新增实体，减少了不必要的操作。
4. 低频实体的管理：优化了处理逻辑，使其更加清晰和高效。

最终的目标是使代码逻辑更具条理性，同时为未来的扩展提供更好的基础。下一步将集中于实体移动部分的重构与进一步的性能优化。

移动实体代码以适应模拟区域

首先，实体移动的调用被重新设计，将其与模拟区域的逻辑紧密结合。实体的移动操作现在需要直接与模拟区域进行交互，通过区域指针来完成具体操作。实体在被移动时，相关的加速度等属性得到了保留，这些调整使得逻辑更加简洁明了。

其次，为了更好地管理模拟区域内的实体集合，对区域的定义和操作进行了标准化处理。我们明确了模拟区域的统一命名（如“同一区域”），减少了代码中的混淆。同时，相关的操作被设计为在模拟区域内循环处理，以便高效地管理区域中的所有实体。

在代码清理方面，许多过时的逻辑和冗余代码被移除。例如，针对实体的范围检查等旧逻辑被彻底删除，从而减少了复杂性，使代码看起来更加直观和简洁。

关于架构调整的具体优化点包括：

1. 实体高频与低频交互的统一处理：通过简化相关逻辑，减少了高频与低频实体交互时的复杂性。之前与“高”和“低”状态相关的冗余代码被移除。
2. 实体索引的简化：使用统一的索引机制替代了之前的复杂检查逻辑，从而提升了性能并降低了维护成本。
3. 区域内操作的标准化：通过对模拟区域的实体进行循环处理，使得代码更加结构化，未来可以更容易实现空间分区等功能。

此外，还提到了未来可能引入空间分区的可能性，这将进一步优化模拟区域内实体的管理。虽然目前代码在没有分区的情况下仍然可以正常运行，但明确这一方向为后续的性能优化提供了思路。

最后，通过这些优化，代码逐渐演变为更接近理想状态的形式，即不需要显式关注复杂的实体管理逻辑。这样的架构调整不仅减少了新增功能时的认知负担，也为后续开发和维护带来了便利。未来的工作将继续聚焦于完成模拟区域的优化以及实现更高效的架构转变。通过清理与精简，最终目标是实现更加清晰和高效的系统逻辑。

为剩余的模拟区域工作留下备注

首先提到的一个关键点是哈希表的清理。这被认为是十分重要的环节，因为如果没有对哈希表进行清理，可能会导致数据混乱或者性能问题，从而带来系统运行的不稳定性。为了避免潜在的风险，这部分工作被明确标记为优先任务。

其次，对实体状态的管理提出了进一步的改进方向。明确区分“激活”和“非激活”实体的重要性被再次强调。通过更精细的分类，可以实现更高效的资源分配和管理，例如在特定场景中优先处理活跃的实体，同时减少对非活跃实体的性能开销。

为了确保这些重要事项不会被忽视，特别提到在代码中添加了相关的注释或便条，以便在后续开发中保持清晰的思路。这种记录方式可以帮助开发团队在繁忙的工作中快速回顾关键任务，减少遗漏风险。

总体而言，这一部分总结了两方面的改进方向：

1. 哈希表清理：作为核心数据结构的管理，需要始终保持干净，以确保系统稳定。
2. 实体状态分类与管理：进一步优化“激活”和“非激活”实体的逻辑，为系统性能和扩展性提供支持。

你的随机数表有个错误。数字范围有限。

关于随机数表的问题，指出随机数被限制在一定的范围内。然而，实际上并不打算使用这个随机数表，放入代码中的目的是为了避免在早期讨论中深入讲解随机数生成的细节。这个随机数表被当作一个占位符，直到开始进行世界生成的内容时才会真正涉及如何生成随机数。强调了不推荐使用随机数表的方法，因为没有必要这么做，且会在未来讲解如何生成随机数。

能否解释一下你的命名约定，或者背后使用它们的原因？我从未见过类似的风格，它看起来像是倒过来的。

在这段内容中，讨论了命名约定的使用方式，特别是数据类型和变量名的命名习惯。主要提到数据类型通常使用小写字母和下划线，而函数和变量名则使用驼峰命名法。这种命名约定的背后原因是，使用下划线的版本输入起来较慢，因为需要额外的字符，所以通常将它们放在输入频率较低的地方，而更频繁使用的函数和变量则采用驼峰命名法。这种做法并没有特别强烈的感觉或偏好，只是个人的习惯。总体上，命名的关键是确保代码易于理解，不至于造成混淆。

你希望存储的实体像正常实体一样移动，还是模拟它们？就像你提到的，屏幕外的实体在慢速更新时会移动。

讨论了存储实体的更新和模拟方式。计划是让所有实体运行相同的模拟代码，但根据与玩家的距离，更新频率会有所不同。当实体离玩家较远时，它们会更少更新，例如每10帧更新一次，而不是每帧更新。这样做的目的是为了简化代码，避免为每个实体编写两种不同的逻辑。虽然还不清楚这样的方法是否会成功，但希望能够减少bug并提高代码的可维护性。

高频和低频实体的意义是什么？只使用一个是否更合适？

高频实体和低频实体的概念最初是为了解决实体更新频率的问题。高频实体通常是离玩家较近的实体，它们需要频繁更新；低频实体则是远离玩家的实体，更新频率较低。尽管目前实际上只使用相同的数据来表示这两类实体，但这个设计的目的是为将来可能需要区分两种实体类型做准备，尤其是随着游戏发展，可能会出现需要更高效管理实体的情况。

实体可以互相引用吗？需要检查循环引用吗？

在处理实体引用时，不需要检查循环引用。加载实体引用时，如果遇到引用指向自身，系统会在存储索引中找到该实体并标记为已加载，避免重复加载。这样就不会触发无限循环。为了解决可能的循环问题，存储和索引机制被设计成当遇到已存在的实体引用时，可以跳过重复的加载过程，确保不会造成循环，保证系统能够干净地退出并继续运行。这种处理方式能够有效地防止循环引用导致的程序崩溃。

什么时候需要从零开始重写？你有多频繁地把所有东西推倒重来？

当面对代码库时，我们可以根据编程模型的好坏决定是否进行重写。一个良好的编程模型会让我们能够逐步优化和改进现有代码，而不需要从头开始重写。通过不断地改进代码，最终将其转变为更稳定、易于维护的状态。而对于一个糟糕的编程模型，则可能需要重写，因为无论我们做什么，最终都会导致问题堆积，导致代码质量难以提升。

在良好的编程模型下，代码会朝着更好的方向发展。即使有不完美的部分，也能通过逐步改进，使其变得更加稳定。这样的编程模型强调渐进式的改进，代码始终朝着一个稳定且优化的方向移动。而在糟糕的编程模型下，任何尝试都会带来问题，导致难以取得好的结果。这时，我们才需要从头开始，重写代码，但要注意，如果不改变编程模型，重新开始也可能会再次陷入同样的问题。

在开发过程中，我们需要避免陷入这种死循环。代码重写应当是经过深思熟虑的决定，而不是对每个问题的直接反应。通过理性的编程方法，我们能够在现有基础上不断优化，而不是一味的推翻重来。

你对Scrum和敏捷方法有何看法？

我们对敏捷方法和Scrum方法的看法是，尽管对这些方法有所了解，但并没有亲自使用过Scrum，甚至对它的实际操作也仅有模糊的认识。我们知道Scrum的一些基本概念，比如人们如何在开发过程中使用任务板来追踪任务的进度，但并不完全了解其中的细节。至于敏捷方法，我们记得它最初出现在编程领域时，给人的印象是它强调快速和灵活的编程方式，但我们并没有深入研究相关文献，也不能确定这些方法与我们自己理解的编程方式是否一致。我们无法对这些方法作出明确的评价，也不能确定它们是否适用于我们的工作方式。

对于我们正在进行的项目，尽管目前进展顺利，我们也面临着一些挑战，尤其是在模拟和实体管理方面。我们正在尝试新的系统，以应对大规模实体的模拟，探索如何在程序中实现更高效的管理。尽管有些问题尚未解决，但整个过程充满了挑战和乐趣，这让编程保持了趣味性和探索性。

我们喜欢推陈出新，尝试打破现有框架，寻找新的解决方案。虽然系统设计和实体模拟的工作有时会带来意料之外的难题，但这也是我们享受编程的原因之一。每当我们遇到新的挑战，都会激发我们去解决问题并推动技术的进一步发展。

仓库: https://gitee.com/mrxiao_com/2d_game