OCC: Planet Civilization · 整体玩法方案 v1

状态：方案已部分实装。本文档保留为设计意图的记录。 代码里当前跑着什么，以 玩法系统现状 为准；方案与现状的差距见 未完成清单。 日期：2026-10-14（方案）/ 2026-10-15（实装状态复核） 配套文档：背包与物品系统方案-v1（物品分类 / 容器 / 使用交互 / 掉落）、 系统架构、接口与协议 基线：现有「OCC 星球漫游」原型（Three.js 0.184 + Node，双星球：苗圃 R520/320×160、 焦土 R820/500×250，50 台 NPC（其中 24 台精英）、世界 Boss「天罗」、Mech + paper planes、 科技树 + 基地建造 + 物流，多人同步） ⚠️ 本文档 §4.3 的「积分商城」已不存在（积分系统 2026-10-15 整体下线），该节已重写为科技树的独立说明。

---

0. 一句话

把现在的"一个大战场"拆成两颗星球：战场星负责打（多人 / 高风险 / 出科技材料）， 家园星负责造（私人 / 和平 / 出产能），两颗星球用一个科技树锁在一起 —— 想升级，必须去战场拿材料；想打得更狠，必须回家园把产能建起来。

三个关键词：双星球分域 · 无人机物流（无传送带）· 战场材料驱动科技树。

---

1. 世界结构：双星球体系

1.1 两颗星球定义

命名只是占位，老大有更好的一换即可（WORLD_CONFIG.worlds.battle.name / .home.name）。

1.2 关键设计决策：家园星 = "同 seed 的私有分片"

三个候选实现，推荐 C：

推荐 C 的理由：

• 地形是纯数学函数（terrain-field.js）→ 客户端自己算，服务端 不需要为每个分片跑世界，只存"玩家在自己分片里的建筑"。
• 同一套地形 = 一套最优布局可以分享、可以做教学、可以后续做"家园评分榜"。
• 服务端成本 ≈ 只多了存档分区 + 1Hz 结算。这是本方案里性价比最高的一个决策。

1.3 往返机制：星门

• 去战场：家园星上有「星门」建筑（落地即送 1 座，不可拆）→ 交互 → 加载战场 → 出现在战场着陆区（可自选 3 个固定着陆点，避免落地即被打）。
• 回家园：任何位置可打开「召回」（冷却 30s，脱战 5s 内可用）。战斗中不可召回 —— 保留战场的紧张感。
• 战场被击毁：在家园星重生（改动现有逻辑，现状是战场随机点重生）。

理由：死亡惩罚从"丢进度"变成"丢一趟时间和身上的货"，更符合"家"的设定，也更不劝退。

• 携带：去战场时带什么？—— 由背包承担（详见 背包与物品系统方案-v1）：
• 出发前从基地仓库把弹药 / 修理包 / 要放的建筑装进背包
• 战场打到的资源与掉落进背包，回到家园再转入总库
• 背包有格数上限 → 构成"打多久 / 打多深"的决策
• 被击毁 = 背包随机掉落一半（掉在战场原地成为可拾取物，2 分钟后消失）

这样"战场材料"就有了真实的重量和风险，而不只是一个计数器。

---

2. 资源体系

2.1 资源清单

中间产物（冶炼 / 加工）：铜锭、铁锭、锡锭、钢板、电路板、机械部件、能源单元。

2.2 为什么战场必须有自己的资源

需求里说"解锁科技需要去战场获取材料"—— 要让它成为硬门槛而不是可选加速：

• 家园星的所有矿都能自产 → 玩家可以永远不来战场，循环就断了。
• 所以：战场专属资源决定科技树上限，主星材料只决定"进度快慢"。
• 同时战场也放少量低级矿（铜/铁）：让新玩家第一次去战场就有正反馈，不是空手而归。

2.3 矿脉生成（新增 resource-field.js）

与 terrain-field.js 同构的纯函数模块，浏览器与 Node 共用（两端必须一致，这是硬约束）。

输入：(seed, 单位方向 dir)
输出：{ kind: 'copper'|'iron'|'tin'|'oil'|'stone', richness: 1..3, amount: 储量 }

实现：
  n_kind  = fbm3(dir × freq_kind + offset_kind)      // 每种矿独立的噪声层
  mask    = n_kind > threshold_kind                   // 阈值化 → 矿带（不是均匀撒点）
  海拔偏好：铜=丘陵(0.35~0.7)、铁=中海拔(0.3~0.65)、锡=高山(>0.7)、
            石油=低地且平坦(<0.25 且坡度小)、石头=全地形
  richness = map(n_kind, threshold, 1.0, 1, 3)        // 富集度 1~3
  amount   = base(kind) × richness × (1 ± 0.3)        // 储量，采完进入再生倒计时

散点 vs 矿带：用阈值化的噪声层形成成片的矿带，而不是均匀撒点 —— 这直接决定了"基地往哪儿建"的策略性， 也是《戴森球计划》的地图乐趣来源。

可视化：矿带在地表要有可辨识的表现（地面色斑 + 矿石堆模型 + 扫描后的地图高亮）， 玩家不能靠猜。

2.4 采集方式（两阶段）

手动采集只用于开局前 5 分钟（积累第一桶金），之后全面交给自动化 —— 这也是《戴森球》的节奏。

---

3. 基地建设

3.1 建造模式

参考《戴森球计划》的"网格 + 幽灵预览 + 拖拽"，但不做地形改造（关键简化）：

建造载体：v1 玩家开着机甲亲自到现场放（建造模式下调出俯视视角）； v2 引入建造无人机（在星门/指挥中心下单，无人机自己飞去施工，玩家不用跑腿）—— 这就是"无人机替代传送带"之外的第二个无人机用法，也让基地可以远程扩张。

3.2 建筑清单（按科技阶段分层）

T0 · 落地即送

T1 · 开采与初加工 | 采矿机 | 3×3 | 放在矿脉上自动采集（需能源）；不同矿种需要对应钻头等级 | | 伐木机 | 3×3 | 自动伐木 | | 冶炼厂 | 4×4 | 矿石 → 锭（按配方，可切换） | | 石料厂 | 4×4 | 石头 → 建材块 | | 炼油厂 | 4×4 | 石油 → 塑料 / 能源燃料 |

T2 · 物流与能源 | 物流站 | 5×5 | 无人机起降点：有货槽，可设为"供给 / 需求 / 存储"，无人机自动配平供需 | | 能源核心 | 4×4 | 烧石油/生物质 → 能源（稳定输出） | | 太阳能板 | 4×4 | 白天产能源（接入现有昼夜系统 SUN_PERIOD = 300s） | | 电池组 | 3×3 | 储能缓冲（把白天的电留到夜里） | | 无人机组装厂 | 4×4 | 造无人机（消耗材料），补充损耗 |

T3 · 制造与机动 | 装配机 | 4×4 | 锭 → 部件（多配方，可排产队列） | | 机库 | 6×6 | 机甲改造 / 换色 / 回血 / 换装（把现有积分商城的部分能力搬到基地，见 §4.3） | | 载具工厂 | 6×6 | 造地面运输载具（大容量、慢速，做干线运输） | | 星门·二级 | 6×6 | 减少召回冷却、提升背包携带上限 |

T4 · 高阶 | 研究所 | 5×5 | 消耗战场材料解锁科技（也可在指挥中心做，研究所加速） | | 轨道平台 | 8×8 | 全面提升无人机运力 / 航程 / 数量 | | 防御塔 | 3×3 | 家园防御（仅在引入家园 PVE 时才需要，见 §9 拍板点 5） |

3.3 能源：推荐「全局能源池」（不做布线电网）

《戴森球计划》的核心张力之一是"电够不够"。完全去掉会丢味道，原样搬来会引入布线地狱。折中方案：

• 能源是一个全局池（存在指挥中心），不做"覆盖半径 / 电缆连线"。
• 能源建筑（能源核心 / 太阳能板）产出；电池组缓冲；
• 耗能建筑（采矿机 / 冶炼厂 / 装配机 / 物流站）按运转时间扣能源。
• 能源不足 → 全局降速（按缺口比例把生产效率打折），而不是随机停机。

表现：HUD 上一条能源条变红 + 建筑上方闪黄灯。

• 太阳能与昼夜绑定：现有 SUN_PERIOD = 300s 一圈 → 白天满发、夜里归零。

于是"要不要配电池"变成一个真实的小决策，而不用画一根线。

好处：保留了"该造多少发电"的规划乐趣，砍掉了电网拓扑的全部复杂度。 如果想更极简（v1 完全不做能源），也是可行的 —— 但生产效率就没有第二个可调旋钮了，见 §9 拍板点 4。

3.4 🔴 无人机物流（替代传送带）—— 本方案的核心机制

不做传送带，也不做皮带式寻路。用「物流站 + 自动供需匹配」。

模型

物流站 A（供给槽：铜矿）          物流站 B（需求槽：铜矿）
        │                                    ▲
        └──────── 无人机自动派单 ────────────┘

• 每个物流站有若干槽位，玩家给每个槽位设：供给 / 需求 / 存储，并绑定一种物品。
• 服务端每 1 秒 结算一次：

1. 收集所有"需求槽未满 + 有库存可拿"的供需对；
2. 按距离/优先级排序派单，扣掉供给站库存，生成一条运输任务（含预计到达时间）；
3. 到达时间到 → 入账到需求站（结算式，不逐架模拟物理）。

• 客户端只负责把任务表现成一架无人机的飞行（大圆弧 + 缓动曲线），

从 A 站起飞、飞向 B 站、降落消失。逻辑与表现完全解耦。

为什么这么设计（重要）

结算式 + 视觉代理 = 零寻路、天然并行、可低成本扩到几百条航线，同时画面依然好看。

数值（首版）

玩家看到的自动化链路（M3 验收标准）

铜矿脉 →[采矿机] 铜矿 →[无人机]→ 物流站 →[无人机]→ 冶炼厂 → 铜锭 →[无人机]→ 储物仓

玩家只需要摆建筑、设供需，剩下全自动。这就是"基地活起来了"的那一刻 —— 也是本作的核心爽点。

---

4. 科技树

4.1 分层结构

两条并行支线：生产线（家园）与 战场线（打怪）。

生产线
[根 · 基础工程]
 ├─ T1 采掘 ─── T2 石化
 ├─ T1 冶金 ─┐
 ├─ T1 电力 ─┴─ T2 物流 ─── T3 装配 ─── T4 轨道平台
 └─ T1 建材

战场线（与生产线并行，互有交叉解锁）
[战场分析] ─ [武器校准] ─ [装甲强化] ─ [机甲超载]
                    └──── [Boss 情报]（雷达显示 Boss 位置 / 弱点提示）

4.2 成本结构：战场材料是硬门槛

每项科技的成本 = 主星材料（量）+ 战场材料（硬门槛）：

产出速率对照（保证"每次出击都有进展"）：

⇒ 一笔设计：T1/T2 科技 ≈ 一次 10 分钟左右的战场出击就能解锁， T3/T4 需要多次出击 + Boss。这样短周期有反馈，长周期有目标。

4.3 与「战场补给」的边界（原「积分商城」，已于 2026-10-15 下线）

现状变更：原方案设想"积分商城负责战场即时补给，科技树负责长期成长，两者不交叉"。 2026-10-15 积分系统整体下线，商城随之移除（/api/shop/buy 已删、返 404）。 因此这条边界问题不复存在——战场上的一切成长都归科技树。

取代关系：

• 原商城的 weapon / speed / hull / drone 四个等级线，由科技树的 wpn1~5 / spd1~5 / hull1~5 / drn1~5 四条五级改造线承接。
• 老存档里的 profile.upgrades 字段冻结保留、继续生效（一个字都不能删），与科技树效果叠加；wallet.derived 就是这两源之和。
• 玩家战绩字段改为 kills（不含 NPC，NPC 击杀记在 stats.npcKills）。
• "修理"由服务端自修复回血（脱战 2 秒后按 regen 速率恢复）取代，不再需要买修理包。

命名问题（原方案担心的混淆）已自然消解：商城下线后场上只剩物流无人机， 而科技树 drn* 提升的是环绕攻击无人机的数量，两者在不同界面出现，不再需要改名。

---

5. 核心循环

5.1 双循环

┌──────────── 家园星「苗圃」（私人 · 生产） ────────────┐
│                                                      │
│  采集 → 建造 → 产能 ↑ → 冶炼/装配 → 装备与部件       │
│                            │                         │
│                      缺「结晶 / 合金」               │
│                            ▼                         │
└────────────────────── 星门 ──────────────────────────┘
                             │
┌────────────────────────────▼─────────────────────────┐
│              战场星「焦土」（多人 · 战斗）            │
│                                                      │
│  打精英坦克 / 打 Boss / 抢矿 / 玩家遭遇战             │
│        → 掉落结晶 · 合金（进货运仓）                  │
└────────────────────────────┬─────────────────────────┘
                             │ 活着回来
                             ▼
                      家园：研究所解锁科技
                             │
                             └──→ 新建筑 / 效率乘数 / 机甲强化 → 回去打更狠的目标

5.2 三条时间轴

5.3 新手前 30 分钟（节奏设计）

0:29 那一刻是整个作品的"啊哈时刻" —— 玩家第一次完整体验到 "打 → 拿 → 造 → 更强"的循环。整个新手引导都应该保这一条线不被打断。

---

6. 技术落地方案

详细实现留到下一步；这里只给架构级判断与风险点。

6.1 服务端：多世界抽象（P0）

现状：server/server.js（1190 行）是单世界假设，广播全量发。

改造：

server/world.js（新增）
  class World { id, type:'battle'|'home', seed, ownerId, config, players:Set, runtime }
  worlds = Map<worldId, World>
    'battle'          → 单例，跑现有 100ms tick（NPC + Boss）
    'home:<userId>'   → 每个在线玩家一个，不跑实体 tick（关键）

• 广播必须按 world 过滤：现有 relayState() / npcMove / bossMove / kill / wallet

都要加 worldId 判定。这是最容易漏、后果最严重的改动（否则家园位置会串到战场）。

• 家园世界不需要逐帧 tick。只跑一个全局 1Hz 的"基地结算"循环，遍历所有"有玩家在线的 home world"：

采矿产出、冶炼进度、物流派单、能源收支。 50 个在线玩家的家园 ≈ 50 次 1Hz 轻量结算，成本可忽略。

• 战场 tick 与基地结算分帧错开（不同 setInterval 相位），避免同帧挤在一起来个延迟尖刺。

6.2 存档结构扩展（server/store.js）

user.worlds = {
  home: {
    seed: 20261012,
    slotIndex: 0,                        // 同 seed 下的分片号
    tech: { unlocked: ['t1_mining'], points: {} },
    inventory: { copper: 0, iron: 0, ... },
    energy: { stored: 120, capacity: 500 },
    buildings: [
      { id, type:'smelter', lat, lon, yaw, level:1,
        storage:{...}, io:[{mode:'demand', item:'copper_ore', cap:50}] }
    ],                                   // 上限 400 个，超出拒绝
    stats: { minedTotal:{}, craftedTotal:{}, playSeconds }
  }
};
user.bag       = { size, slots[], quick[], equip{} };  // 随身背包（跨星球跟随）
user.storage   = { slots: [] };                        // 家园基地仓库
user.location  = { worldId:'home:u123', lat, lon, alt };

⚠️ 注意：

• 建筑数组是新增的最大存档负担。400 × 约 200 字节 ≈ 80KB/玩家，18 个玩家 ≈ 1.4MB，可接受；

但仍要走现有的 markDirty() + 异步原子写（10s 节流），不要每次放置建筑都同步写盘。

• 老存档迁移：新增字段一律读取时补默认值（沿用 characterSet 那套兼容做法），不要求老玩家重来。

6.3 客户端：世界切换（工作量最大的一块）

现状：public/src/main.js 2080 行，是单世界单例装配。

改造思路：

把"装配一个世界"抽成 createWorldRuntime(config) → runtime
                          disposeWorld(runtime)
切星球 = disposeWorld(旧的) + createWorldRuntime(新的) + 加载遮罩

• 不要试图让两颗星球同时驻留在显存里：仅植被一项就有 10.2 万实例，

两个世界同时存在会直接把显存和 draw call 打爆。切换即销毁（跨星球是低频操作，一次加载几秒可接受）。

• 家园星可复用的部分：planet / terrain / physics / player / mecha / orbit-camera / hud / styles。
• 家园星不加载：npc.js / elite-tank.js / world-boss.js / boss-fx.js。
• 家园星新增：build.js（建造模式）/ resource-nodes.js（矿脉可视化）/ logistics.js（物流站 + 无人机表现）/ base-ui.js（库存 / 能源 / 科技树面板）。
• ⚠️ dispose 容易漏：GLB 几何/材质/贴图、InstancedMesh 的 instanceMatrix、

事件监听、每帧 requestAnimationFrame 注册的回调。建议写一个 runtime.dispose() 清单式实现 + 用 renderer.info 前后对比做断言（切星球 3 次后 draw call / geometries / textures 不增长）。

6.4 确定性（硬约束）

• resource-field.js：纯函数，两端共用，与 terrain-field.js 同样式。
• 采矿机放在哪个矿脉上、矿脉是否耗尽 —— 服务端是权威，客户端计算只做表现。
• ⚠️ 沿用现有教训：任何影响生成顺序的改动都必须清 _data/state.json 里对应的 worlds 数据。

6.5 性能预算

建筑的做法与 NPC 一致：同类型合并 InstancedMesh， 每栋楼的"库存/进度"状态不进 mesh，走 UI 与悬浮标签（这与现有 NPC 实例化是同一套经验）。

6.6 新增美术资产预告（下一步细化）

⚠️ 沿用既有约定：模型一律走 tools/glb_optimize.mjs 优化管线（有实测收益：9.64MB → 0.57MB）， 并向 deploy/prod/push.sh 的资产瘦身排除清单里加新目录（清单是硬编码的，容易漏）。

---

7. 分期里程碑

规模判断要诚实：M1~M4 加起来是"从玩具原型到一款作品"的跃迁，不是几个补丁。 结果上跃迁已经完成（M1~M4 均已落地），剩下的块头是 M5 打磨与若干方案内未接完的细节。 逐条差距以 未完成清单 为准，本节只给里程碑级别的结论。

---

8. 风险与取舍

---

9. 等老大拍板的 7 个点

---

10. 复述需求对照（确认没跑偏）