Q30: KBEngine 的 Space 是什么？与物理空间划分有什么区别？

核心结论

Space 更适合理解成“逻辑空间容器”，而不是“自动等价于地图物理分区”。

它可以表示：

• 一张地图
• 一个副本实例
• 一个房间
• 一个逻辑场景容器

所以讨论 Space 时，首先要把“逻辑空间”与“底层物理分区或 Cell 切分”分开。

一、Space 到底是什么

更准确地说，Space 是服务端用来承载一组实体和空间逻辑的抽象容器。

它通常负责：

• 容纳场景内实体
• 承接 AOI 与空间关系
• 关联地图、导航或场景脚本语义

它强调的是“同一逻辑场景中的实体组织方式”。

二、为什么它不等于物理划分

很多人容易把它理解成：

• 一个 Space 就是一台 CellApp
• 一个 Space 天然被均匀切成几个物理区块

这种理解过于粗糙。

更准确的区别是：

• Space 是逻辑概念
• 物理划分是运行时为了负载和扩展做的实现策略

也就是说，同一个逻辑 Space 可能被多个节点协同承载；也可能一个节点上同时存在多个 Space。

三、Space 更像“场景容器”而不是“地图切片”

例如：

• 主城是一个 Space
• 某个副本实例是另一个 Space
• 一个战场房间也可以是一个 Space

它们的共同点不是面积大小，而是：

• 实体属于同一逻辑场景
• 有自己的生命周期
• 有自己的规则和脚本上下文

四、物理空间划分解决的是另外一个问题

物理划分通常更关注：

• 负载均衡
• 多节点承载
• 热点区域拆分
• 邻区迁移

这属于运行时扩展和调度层问题，不是 Space 概念本身。

所以更合理的理解是：

• Space 定义“这个世界逻辑上是什么”
• 分区机制定义“这个世界运行时怎么被拆开承载”

五、为什么把这两个概念混在一起会出问题

如果把 Space 直接等同于物理分区，会导致后续设计很容易混乱：

• 地图逻辑和部署策略耦合
• 副本实例难以抽象
• 动态迁移边界不好表达
• 多 Space 共存时概念失真

六、工程上更实用的理解方式

可以把 Space 看成一层稳定的业务抽象：

• 对玩法层，它代表一个场景语义边界
• 对运行时，它只是承载对象，底下是否切区由调度系统决定

这能让上层玩法和底层部署更好解耦。

七、常见误区

1. Space 就是地图坐标分块

不准确。分块是承载策略，Space 是逻辑容器。

2. 一个 CellApp 只能有一个 Space

未必。是否如此取决于具体实现和资源分配策略。

3. 副本和房间不算 Space

恰恰相反，它们通常非常适合用 Space 这类逻辑容器来承载。

参考资料

• KBEngine 架构资料中的 Space 概念说明