管理变化的设计师数据和变化的球员数据的方法
我有一个在线游戏，玩家可以通过某种方式塑造世界-例如。Ultima Online的房屋，您可以在其中直接在世界地图的某些部分上建造房屋。这些变化应作为持久世界的一部分随着时间的流逝而持久。 同时，设计团队正在添加新内容并修改旧内容，以改善和扩展新玩家的游戏。他们将首先在测试期间在开发服务器上执行此操作，然后再将其工作与实时服务器上播放器的“工作”合并。 假设我们解决了游戏设计问题-例如。玩家只能在指定区域内建造游戏，因此他们永远不会与设计者进行地理上的冲突- 处理新数据或安排数据结构的最佳方法是什么，以避免在将新设计者数据与新玩家数据合并时发生冲突？ 示例1：玩家制作了一种新的物品，然后游戏为其分配了ID 123456。该项目的实例全部回溯到123456。现在想象游戏设计师有一个类似的系统，而设计师创建了一个新项目，编号也为123456。如何避免这种情况？ 示例2：某人制作了一个流行的mod，可以为您的所有龙赋予法国口音。它包括一个带有新对象的脚本assignFrenchAccent，他们使用该脚本将新的语音资产分配给每个龙对象。但是，您将部署具有相同名称的对象的“拿破仑与史矛革” DLC-如何在没有很多客户服务问题的情况下做到这一点？ 我想到了以下策略： 您可以使用2个单独的文件/目录/数据库，但是读取操作非常复杂。“显示所有项目”必须在设计器DB上执行一次读取，在播放器DB上执行一次读取（并且仍然必须以某种方式区分这两个）。 您可以在一个商店中使用2个不同的名称空间，例如。使用字符串作为主键，并以“ DESIGN：”或“ PLAYER：”作为前缀，但是创建这些名称空间可能并非易事，并且依赖关系不清楚。（例如，在RDBMS中，您可能无法有效地将字符串用作主键。您可以使用整数并将低于某个数字（例如1百万）的所有主键分配为设计器数据，而高于该数字的所有主键则分配为玩家数据。但是该信息对于RDBMS是不可见的，并且外键链接将跨越“分隔线”，这意味着所有工具和脚本都需要明确地解决它。） 您始终可以实时处理同一个共享数据库，但是性能可能很差，损坏播放器数据的风险可能会增加。它也不会扩展到在具有不同世界数据的多于一台服务器上运行的游戏。 ...还有其他想法吗？ 在我看来，尽管这主要是在线游戏的问题，但这些概念也可能适用于改装，即社区在开发人员修补其游戏的同时创建mod。是否有任何策略可以用来减少新补丁发布时模块破解的机会？ 我也将其标记为“版本控制”，因为在一个层面上这就是-需要合并的2个数据开发分支。也许某些见解可能来自该方向。 编辑-上面添加了一些示例以帮助阐明问题。我开始认为这个问题实际上是命名空间问题之一，可以通过组合键在商店中实现。至少，这简化了合并策略。但是可能还有其他我看不到的选择。