RTS游戏小地图数据更新机制：汇报式 vs 查找式
RTS游戏小地图数据更新机制：汇报式 vs 查找式
在即时战略（RTS）游戏中，小地图是玩家获取战场信息的重要工具。它不仅需要实时显示敌我双方的单位位置，还要处理大量的数据更新。那么，这些数据是如何更新的呢？本文将探讨两种常见的小地图数据更新方式：自下而上的汇报式和自上而下的查找式。
前言
你是否想过类似红色警戒的战略小地图的要素是采用何种方式更新数据的。大量数据实时更新，考虑频率，运行效率，开发中如何选型？
正题
请问：小地图采用 自下而上的汇报式 还是 自上而下的查找式？
答：首选第一种方式，自下而上的汇报式。
在游戏设计中，小地图的位置更新机制可以采用不同的方法，具体取决于游戏的架构和设计需求。以下是两种常见的更新策略：
自下而上的汇报式（Bottom-up Reporting）:
在这种方法中，游戏世界中的各个实体（如玩家、敌人、重要物品等）负责监控自己的位置，并定期将这些信息发送给小地图系统。
每个实体都有一个汇报机制，当它们的位置发生变化时，它们会主动通知小地图。这种方法的优点是，小地图系统不需要主动去查找过滤每个实体的位置，从而减少了中央处理的负担。代码更加高效，没有查找式的性能瓶颈。如果RTS游戏采用ECS组件系统开发，则非常适合此方式。
这与真实战场前线士兵定时汇报战况是一样的。士兵向上汇报。除非紧急情况，忙碌的指挥官才会主动询问。自上而下的便利搜索式（Top-down Searching）:
在这种方法中，小地图系统定期扫描游戏世界，查找需要显示在小地图上的实体。
小地图系统充当中央权威，它知道哪些实体应该被跟踪，并负责获取它们的位置信息。
这种方法的优点是，游戏逻辑可以保持简单，因为实体本身不需要知道它们是否应该更新小地图。
但是，这种方法可能会增加小地图系统的负担，因为它需要定期查询所有相关实体的位置。如果更新频率快，则小地图的负担将非常大，性能也会有瓶颈。
请问：采用汇报式，汇报给谁？HUD/UMG小地图组件/Player Controller/GameMode/GameState？
坦克Actor下挂在小地图专用Component，将位置信息直接发给Player的UMG的小地图
● 做一个Minimap Component挂给Actor；
● Component中，通过接口找到小地图UMG组件，直接发给UMG；
● 接口不用数组，接口使用单个对象，数据结构：（AActor* Actor，int state，Vector2D Location2D）；
● 可调节发送频率如0.1s，无位移则不发送；
● UMG小地图中，做一个map映射，使用Actor为Key，不推荐使用ID为Key，装入map；
● 小地图自上而下定时2秒巡检一次所有Actor是否存在，如果不存在则删除UI图标；
● 删除的for循环使用倒叙模式。
附篇： 常见的游戏小地图有两种
第一人称 如下图GTA游戏，玩家在小地图中心。有叫雷达小地图，导航小地图，视角地图，环境地图。。。都是一个东西。一般射击类游戏喜欢这个。
第三人称 如下图红色警戒 展平的游戏全图地图，有叫世界地图，卫星地图。。。该地图要面临大量频繁的位置更新。