Creep- Energy
- 50 / 50
- Position
- 20, 20
StructureSpawn- Energy
- 250 / 300
- Free capacity
- 50
- Position
- 21, 20
TICK LAB · V1
用受控的 transfer()、spawnCreep() 与 CPU / Bucket 实验,观察 API 返回值、Intent、预算检查与模型化 Tick 状态之间的区别。
当前包含三个经过约束的实验:Creep.transfer()、StructureSpawn.spawnCreep() 与 Game.cpu CPU / Bucket。每个实验都只开放少量可验证变量,并明确保留未建模边界;结果用于解释已核对的 API / Engine 行为或受控预算计算,不代表 Live shard 证据。
实验 01 / Transfer Energy
把 Creep1 携带的 ENERGY 转移给相邻 Spawn1。
CreepStructureSpawnconst result = creep.transfer(
Game.spawns.Spawn1,
RESOURCE_ENERGY
);不用猜参数。选择典型场景后会立即运行,并把返回码、Intent 与下一状态一起展示。
调整参数,然后运行这个 Tick。
调整参数,然后运行这个 Tick。
实验 02 / Spawn Creep
用一个受控 StructureSpawn.spawnCreep() 调用观察名字、Busy 与 Energy 检查如何决定返回码。
Spawn1 固定为己方、RCL 可用,name 固定为 Worker1,options 固定为空对象,body 只允许三个有效预设,并使用默认 Room energyAvailable。V1 不模拟 energyStructures 分配、directions、dryRun、出口阻塞或多个 Spawn 的竞争。
StructureSpawnSpawn request[WORK, CARRY, MOVE]const result = Game.spawns.Spawn1.spawnCreep(
[WORK, CARRY, MOVE],
"Worker1"
);这些场景同时体现真实检查优先级:名字冲突先于 Busy,Busy 又先于 Energy。
选择场景或调整参数,然后运行这个 Tick。
选择场景或调整参数,然后运行这个 Tick。
实验 03 / CPU Budget
用一个受控 Game.cpu 快照理解 limit、tickLimit、bucket 与 getUsed() 如何共同决定可选任务是否还有安全预算。
本实验固定 Game.cpu.limit = 100 CPU,只改变 bucket、当前已使用 CPU 与一个可选任务的估算成本。tickLimit 按官方文档描述的 bucket 行为建模,上限 500;bucket 上限 10,000。RUN / SKIP 是本地教学守卫的决定,不是 Screeps API 返回码或 Intent。实际任务 CPU 成本仍必须在真实 shard 中测量。
CPU snapshotlocal estimateconst plannedTaskCost = 20; // local estimate
const used = Game.cpu.getUsed();
const headroom = Game.cpu.tickLimit - used;
if (headroom >= plannedTaskCost) {
runOptionalTask();
}这些场景把“补 bucket / 保持 / 花 bucket / 卡在 tickLimit / 主动跳过任务”拆开显示。
选择场景或调整参数,然后运行这个 Tick。
选择场景或调整参数,然后运行这个 Tick。