关键词：RTS 游戏 开发 设计模式 设计方法 开发路线 参数设计 对象 设计思路 策划 数值 数据表
在UE游戏开发中，
你是否想过即时战略游戏的单位的数据存在哪里更好？
是存在坦克自身？随着Spawn生成对象的时候，就生成了；还是单独存在一个汇总表里，用的时候查表？
要考虑灵活使用、易修改、防作弊 、做成单机还是网络游戏。
问题：即时战略游戏开发，战斗单位的参数在对象里还是单独做个数据表里？
简述：
以红色警戒游戏为例，如果将坦克的参数存储在对象中，对象包含该单位的各种属性，如生命值、攻击力、防御力、移动速度等。这种方式方便进行个体化的操作和管理。
另一方面，如果将坦克的参数存在表中，可以更加灵活地处理大量战斗单位的数据，通过索引和遍历列表来快速访问和修改战斗单位的属性。
详细解答
即时战略游戏（RTS）开发中，战斗单位的参数管理是一个关键的设计决策，它会影响到游戏的性能、可维护性以及扩展性。通常，有几种不同的方法可以管理战斗单位的参数：
- 对象属性：
- 小型flash游戏，不联网，单机，测试，原型，demo，毕业设计，使用此方案较多。
将战斗单位的参数作为对象的属性直接存储在对象内部。这种方法的好处是直观且易于理解，方便进行单位特定的逻辑处理。这种方式非常适合小型团队开发维护和插件式管理战斗单位，项目中的各个资产间也相对独立，所以外包协作开发时比较有优势。如果游戏需要高度个性化的战斗单位，并且每个单位都有自己独特的属性和行为，很难用一个表单理清，甚至存在未来可能增加特例型的参数，那么使用对象属性来存储参数的方式更为合适。
- 单独的参数列表或数据库：
- 适用于大、中型主机游戏，可进行50人以内联网对战，且不向玩家开放参数配置。其相比方案1，数据略加安全。
将所有单位的参数存储在一个单独的数据结构中，如列表、字典或数据库表。适合于参数经常需要跨不同单位共享或比较的情况，也便于进行批量操作和数据管理。如果游戏需要处理大量的战斗单位，并且这些单位的属性和行为相对统一，未来对所有单位参数的修改多属于普调式，那么使用列表来存储参数可能更加高效。
- 配置文件：
- 此方案适合单机网络项目、DLC项目均可。大中型单机/局域网/对战平台主机游戏，自娱自乐的发烧友开发，往往喜欢使用此方案。
属于方案2的扩展，使用外部配置文件（如JSON、XML或自定义文件）来存储单位参数。这有助于将游戏逻辑与数据分离，使得参数的修改不需要修改代码，便于维护和更新。此方案相对于方案2区别在于参数是否公开给玩家。由于参数暴露，所以游戏更容易调参和作弊。因此方案3并没有方案2普遍。但此方案常见于兵棋推演和仿真系统项目，在交付给甲方后，甲方可以自行设定参数。
- 数据库：
- 属于方案2的升级版，大型网络游戏，手机或电脑下载客户端的这类游戏使用此方案。
对于大型游戏，需要防止玩家作弊，还要频繁更新信息。所以会将单位参数存储在服务端的数据库中，进行高效的查询和更新操作。这在游戏需要频繁更新和维护时尤其有用。数据主要存在于服务器，通过设置数据验证策略，可以防止玩家作弊。
- 混合方法：
在实际项目情况下，上述方法开发者可能都会用。例如，个性化参数可能存储在对象属性中，而共用的属性则在表中。或特殊单位或简单的单位在对象中，复杂的战斗单位的参数放在表里。
选择哪种方法取决于游戏的具体需求、开发团队的偏好以及游戏的规模。通常，小型游戏或原型可能更倾向于使用对象属性，而大型游戏或需要高度可维护性的游戏可能更倾向于使用外部数据结构或数据库。
问题：即时战略游戏场景中和小地图中都使用了单位、ID、图标、状态、坐标参数构成的数据结构。但是这个数据结构里也存在没有用到的数据，请问我是做成一个复杂的数据结构，给整个游戏使用，还是"按需设计"避免冗余？
答：按需设计