对于多实例 设计思路 仅供参考
大概流程:
玩家加入服务器之后 -> 进入空岛生存模式 -> 发起创建岛屿指令 -> 第一时间将会与空岛管理中枢创建通信 -> 智能匹配对比之下比较空闲的服务器 -> 最后成功完成整个流程
优势与弊端
-
优势
-
- 当某个空岛服务器宕机，只会影响那个宕机服务器中的玩家，而不会扩大影响至全部玩家。
-
- 用多个服务器分摊压力，远比单端要不断尝试各种优化压缩游戏内容从而影响玩家体验好得多的多。这样可以形成健康的游戏环境。
-
- 如果当玩家激增到达一个阈值，可以上调空岛服务器数量完成应对。而无须排队。
-
- 因为是多服务器架构这意味着，我们可以尽量减少关于红石机器上的限制。（只是尽量，很多比较大型的机器仍支持性不太友好。)
-
弊端
-
- 繁琐性大幅度上升，如果是单服务器架构只需要更新一个就可以完全应用，但是多服务器架构每次变更、更新等...都要花上更多的时间。
-
- 功能上来看，很多功能并不支持该架构，所以我们要花费更多的时间完成功能上的更新，或者寻找平替。
-
- 连通性，我们一直想确保即使在多服务器框架下也让玩家保持联通，而不是像分一区二区来彻底隔离。即使我们不断在完美连通目标追寻，但是可能总有一点点遗漏。
- 为保证连通性，我们已实现: 玩家数据互通 聊天信息互通... 基本涉及功能上的都互通了，如果你发现有的没有请及时联系我们，感谢！
-
- 成本问题，因为在此框架需要多个实例来实现，这意味着我们的花费可能会更高。
-
总结
- 从长远看，多服务器实例框架确实是最优解。麻烦是麻烦点，但是从某种程度来说这样可以提升游戏体验一个等级。
关于游戏内经济系统
- 我们尽量不过多干扰游戏经济，尽量以玩家互相交易的形式来形成构建良好的经济系统。