【心得】如何最佳化地图性能(下)

自Minecraft发行以来，玩家和开发人员与性能之间的爱恨情仇从未停止，诸如Optifine等最佳化模块如雨后春笋般冒出，1.15更被官方定位为修复错误和改善性能的更新。本文将接续上一篇介绍Cloud Wolf「如何最佳化你的数据报」影片的文章，继续介绍我个人撰写并最佳化数据报时的部分心得。

以下一一说明：

每一个实体都会对应到一个通用唯一辨识码(Universally Unique Identifier)，缩写为UUID，像我自己的UUID就是59c1027b-5559-4e6a-91e4-2b8b949656ce。这不是什么秘密，namemc.com上都能找到。

Minecraft会将游戏内的所有实体创建哈希表(hash map)，并由UUID作为关键(key)。每当一个@e被运行，实际上都在走访(traverse)整张表，确认实体是否符合@e内的条件。

然而，若是使用UUID指定实体，等于直接指定哈希表的关键，整体运行效率会快非常多。

举例，假设事先在某处召唤了一个标记后，要在该标记的位置放置一块石头，利用目标选择器的写法就是：

然而，这样的写法却会走访世界上的所有标记，确认其带有place_stone的tag后，再放置石头。

(事实上这样的写法可以加上limit=1最佳化，不过这部分等到第2点再提。)

如果改用UUID，那么指令将变为：

等于直接指定该实体，而不用经过tag的检测。

UUID的写法非常简单，{UUID:[I; <整数1>, <整数2>, <整数3>, <整数4>]}，其中每个整数在经过10进位转16进位后，依序对应了UUID字符串中的8个字，例如{UUID:[I; 2, 8, 15, 24]}，产生出的实体将会是：00000002-0000-0008-0000-000f00000036

另外要注意，如果对象是玩家，那么在一些指令(scoreboard、tag等)上，ID和UUID的结果将会不同，这时推荐使用execute as UUID run scoreboard players set @s …，这样就和使用ID一样了。

数据源：Reddit

刚才说到，如果不使用UUID指定，则游戏将会走访所有的实体确认数据，那么有没有办法减少走访的长度？

答案是有的，那就是在目标选择器条件内加上limit=1，例如像@e[type=marker,tag=place_stone,limit=1]，这样一来，一旦游戏走访到一个实体，就会停止走访。这个技巧其中一个非常实用的场合，就是使用execute if entity确认是否存在某个特定实体。

如果可以使用假玩家保存分数，就不要使用实体。一来，若要在同一个计分板上纪录大量分数，那么势必要召唤大量实体，即使是标记，也在一点一滴地增加游戏的负荷。二来，如果大量的计分板皆使用同一个实体进行计分，则容易发生混乱，也有可能冲突。最后，使用实体就有机会需要进行走访，那又回到了在目标选择器条件上最佳化的问题。

如果可以使用进度(advancement)侦测玩家的行为，那么就不要使用计分板。使用计分板的坏处是需要额外写指令侦测玩家的分数变动，并且每一个条件都需要一个目标侦测。

例如侦测玩家吃下苹果、面包或胡萝卜，若是使用计分板就必须创建三个目标，并撰写三行指令侦测其中一个达成，最后重置所有分数。

事先创立：

连闪侦测：

运行函数：

非常地不方便。

幸好，进度有提供consume_item，让用户不需使用三个侦测、三个重置，而可以用一个侦测、一个重置达成：

而在函数内，只需简单的使用advancement revoke即可重置：

进度没有root、没有parent、甚至没有display都是有效的，是可以正常运行的。我个人的习惯是在数据报的advancements文件夹内再开一个commands文件夹，以和其他会显示给玩家看的自定义进度区隔。

有关进度：Wiki

进度生成器：Misode advancement generator

以上，终于把下篇打完啦。最近因为在忙专题的关系都没有时间打完这篇文章，让大家久等了。

我个人觉得写数据报不能不做最佳化，尤其是在官方已经有提供一些很好用的工具，例如标记、述词等。在更新越来越多、Minecraft内容越来越庞大的情况下，地图和数据报创作者能做的就是尽量最佳化地图或数据报的性能。

最后呢，由于圣诞节快要到了，因此放上一张圣诞惠惠镇楼，也预祝各位新年快乐。

谢谢大家。