1. 本册用途#
这一册管什么:城市独立时钟(仅自由模式)、线路恒定产出三层模型(容量 → 时段权重 → 日修正)。
这一册不管什么:农田与作物池——它是第五类固定设施,已独立为 TRANS-06(本册旧 §4/§5 已移出);时间系统本身的 Tick 机制(见 SYS-10)与存档(见 TECH-04)。
2. 档期与优先级#
| 项目 | 内容 |
|---|---|
| 档期 | P1 |
| 被谁依赖 | TRANS-01~04 · TRANS-06 · SYS-10 · SYS-06 |
| 上游依据 | 既有分册迁入 |
本文定位:本文是《SKYLINE CHRONICLE》文档体系的独立分册(v1.1:原第 9 份,因《平行世界规格》删除而顺位前移)。主文档(《完整设计方案》《城市与地区设计规格》《技术架构文档》《战役剧情与章表》《主菜单与首屏 UI 规格》)中只保留指示与描述,完整规则以本文为准。本文与既有分册(铁路 / 航空 / 旅游 / 工业 / 天气 / 地铁 / 身份模式)并列,不替代其中任何一份——线路的资产与建设规则仍在各自分册,本文只定义时间与产出这一层。
① 时间不同步:玩家在多个城市之间切换时,非当前城市的时间怎么算;
② 线路产出:跨城线路(航线 / 长途巴士 / 船线 / 客运与货运铁路)在玩家不在场时产出什么、产出多少、怎么分时段;
③ 农田与作物:新增的固定式产粮设施如何与既有的交通节点、资源地体系衔接,以及作物总量控制。
3. 规格与清单#
本册的核心玩法规则。原分册的机制部分全部迁入本节。
定位与档期#
| 项 | 内容 |
|---|---|
| 文档性质 | 独立分册(第 9 份)。定义跨城时间模型与线路产出模型两层规则 |
| 适用模式 | 仅 S13 自由模式。战役模式的时间规则不受本文影响(见 §2.3) |
| 档期 | §2 时间模型属 P2(多城市玩法的前置);§3 线路产出分两部分——客运四档时段属 P2,货运长期恒定属 P3(随工业资料片交付) |
| 与工业资料片的关系 | 农田与作物池(§4 / §5)属 P3 工业资料片;本文只固定理论框架,具体数值在数值期确定(见 §4.2 注) |
| 否决的旧口径 | 原「城市切换时全局时间同步前进」的隐含假设,自本文起仅对战役模式成立 |
城市独立时钟(自由模式)#
总纲:自由模式下,每一座城市都是一个独立个体,拥有自己的一套时间体系。任一时刻只有一个城市处于「激活」状态(即玩家当前所在的城市),其余城市处于「冻结」状态。
2.1 冻结 / 激活模型
| 状态 | 该城市内发生什么 | 说明 |
|---|---|---|
| 激活 (玩家所在城) | 完整运行:L1 实时(人 / 电梯 / 施工)、L2 日结(租约 / 财务 / 损耗 / 事件)、L3 战略(报表 / 估值 / 周期) | 同一时刻只有一座城市处于此状态 |
| 冻结 (其余城市) | 楼内运营全部停摆:不再推进日结、不触发租约事件、不老化、不重算估值、不产生投诉 但线路产出照常累计(见 §2.2) | 冻结不等于「世界静止」——在途的东西还在走 |
因为两者的归属不同。楼内运营依赖玩家的决策上下文(要不要续租、要不要维修),冻结它是为了避免在没有玩家的情况下替玩家做决定;而跨城线路是一条已经建成的通道,它的产出是通道的物理属性——只要两端城市存在、线路还在运营,客流与货运就会持续发生,与玩家是否观看无关。
这条区分是本模型的核心设计:它让「离开一座城」既有代价(楼内不再替你赚钱),又有收益(线路仍在替你产出),从而让多城市经营成为一个真实的取舍,而不是简单的「越多越好」。
2.2 切换时的补算
城市 A 的冻结按真实经过时长计(1:1,不封顶)。玩家从城市 B 切回城市 A 时,对 A 执行一次补算:
冻结时长 Δt = 切换时刻 − 离开时刻 (真实游戏时长,不封顶) 线路产出 = Σ(每条线路的时段产出 × 对应的时段数 × 日历修正) 楼内运营 = 不补算(从离开时刻的状态原样继续) 补算范围 仅限:线路带来的客流 / 货运 / 收入 不补算范围 租约到期、设备损耗、结构老化、估值变化、事件链
① 补算必须可解释:切换回城市时,玩家必须看到一张「离开期间发生了什么」清单(各线路贡献多少客流 / 货运 / 收入),而不是一个凭空多出来的数字。没有这张清单,补给会被当成 bug。
② 补算不得触发决策:补算只结算结果,绝不代表玩家做出任何选择。凡需要玩家拍板的事项(续租 / 大修 / 政策变更),一律挂起到玩家回到该城后再问。
与快进模式的关系:补算复用「快进模式」的离线推演能力(见《设计方案》§3 双轨时间)。补算不是把城市 A 完整模拟一遍,而是只跑线路产出的解析解——时段权重与日历修正是封闭公式,不需要逐日 tick。这是补算能做到 O(线路数) 而非 O(天数) 的原因。
2.3 与战役模式的边界
| 模式 | 时间规则 | 理由 |
|---|---|---|
| 战役(26 章) | 单一全局时间轴,不冻结。三城往返时时间同步前进 | 剧情叙述依赖一致的时间线(「同一年,三座城市」);冻结会让章节推进失去参照 |
| 自由模式 | 每城独立时钟,非当前城冻结(本文规则) | 多城市经营的核心玩法需要「离开」成为一个真实选择 |
两者不共用一套时间实现,但共用同一个 GameClock 抽象——战役传入「全局时钟」,自由模式传入「多实例时钟」。见《技术架构文档》§8。
线路恒定产出模型#
总纲:跨城线路的产出是时间段恒定的——同一条线路、同一个时段,每一份产出都相等,不随机的。
3.1 三层结构:容量 → 时段 → 日历
| 层 | 名称 | 作用 | 归属 |
|---|---|---|---|
| L1 | 线路容量 line_capacity | 该线路一天能运送的总量上限(人数 / 吨数)。由载体决定:航班座位数 × 班次、列车编组 × 车次、船舶吨位、巴士班次 | 各分册(航空 / 铁路 / 地铁 / 旅游) |
| L2 | 时段权重 period_weight | 把日总量分配到四个时段(早 / 中 / 晚 / 凌晨),四档权重之和 = 1.0 | 本文(§3.2) |
| L3 | 日历修正 day_modifier | 在时段结果之上再做增益或削减(工作日 / 休息日 / 节假日) | 本文(§3.3) |
线路容量是上限,四档时段是分配权重。即:时段不改变总量,只改变总量的分布形状。一条日容量 1000 人的航线,不会因为「早高峰」变成 1500 人——它只是把 1000 人里的 400 人放在早档、150 人放在凌晨档。
这条口径不破坏既有 capacity 语义:跨城物流与工业分册已建立的「三条通道复用交通节点 capacity」规则完全保留,本文只是在它上面加了一个时间维度的分配器。
3.2 四档时段的分配权重
| 时段 | 覆盖 | 客运默认权重 | 典型特征 |
|---|---|---|---|
| 早 | 06:00–12:00 | 0.35 | 通勤与商务出行高峰;机场 / 火车站最拥挤 |
| 中 | 12:00–18:00 | 0.25 | 平稳;以商务回程与中短途为主 |
| 晚 | 18:00–24:00 | 0.30 | 旅游与休闲出行高峰;酒店入住集中 |
| 凌晨 | 00:00–06:00 | 0.10 | 低但非零;红眼航班、夜间货运、夜班通勤 |
权重为客运默认值,总和 = 1.00。各线路可按载体与城市特性套用不同权重组(如旅游线路的「晚」档更高、货运线路以「凌晨」为主),但任一时段权重不得为 0——恒定的含义是「每档都有确定值」,不是「某些档可以没有」。
权重的作用方式:
某时段客流 = 线路日容量 × 该时段权重 × 当日历修正
例:日容量 1000 人的航线,工作日
早档 = 1000 × 0.35 = 350
中档 = 1000 × 0.25 = 250
晚档 = 1000 × 0.30 = 300
凌晨 = 1000 × 0.10 = 100
合计 = 1000 ✔ 等于容量
3.3 工作日 / 休息日 / 节假日修正
日历修正是在四档时段结果之上的额外一层增益或削减:
| 日类型 | 客运修正 | 货运修正 | 说明 |
|---|---|---|---|
| 工作日 | 1.00(基准) | 1.00(基准) | 早 / 中档偏高,晚档偏低 |
| 休息日 | 0.85(净削减) | 0.70 | 通勤客流消失;但旅游与服务类线路可能反而上升(见下) |
| 节假日 | 1.25(净增益) | 0.60 | 旅游线路可到 1.6+;商务线路降至 0.5 以下 |
同一座城市里,「商务通勤线」与「旅游观光线」在休息日的走向相反。因此修正系数不作为全局开关,而是挂在线路档案上:
line.day_modifier = {
"workday": { "morning": 1.00, "noon": 1.00, "evening": 1.00, "night": 1.00 },
"weekend": { "morning": 0.70, "noon": 0.90, "evening": 1.10, "night": 0.95 },
"holiday": { "morning": 0.80, "noon": 1.20, "evening": 1.45, "night": 1.10 },
}
# 上例为「旅游观光线」;商务通勤线在 weekend 的 morning 会降到 0.5 以下
这带来一个直接的经营结论:一座城市若同时拥有商务线与旅游线,它的客流曲线会自我对冲——休息日商务线亏、旅游线赚。这让「线路组合」成为一项真实的策略,而非单纯的叠加。
3.4 货运:长期恒定
| 维度 | 客运 | 货运 |
|---|---|---|
| 时间粒度 | 四档时段(早 / 中 / 晚 / 凌晨) | 不做时段切分 |
| 产出形态 | 分时客流 | 长期恒定:按日 / 按周结算的稳定吞吐 |
| 波动 | 受日历修正影响明显 | 受日历影响较小(0.6–1.0);受产能与合同影响大 |
| 档期 | P2 | P3(随工业资料片) |
为什么货运不做时段:货物流的调度粒度是班次 / 合同,不是「早中晚」。给货运强加四档时段,只会增加数值噪音而不产生任何有意义的决策。
货运的确定性来自合同:长期恒定不等于免费稳定——货运吞吐由长期供货合同锁定(见《工业与供应链规格》§7),合同期内恒定,到期需重谈。这保留了「稳定」的经营价值,同时保留了「重谈」的博弈空间。
4. 数据字段#
本册的数据结构与字段说明。
数据字段#
// 城市时钟(自由模式)
CityClock {
city_id : String
state : "active" | "frozen"
last_left_at : Timestamp // 离开时刻
accumulated_ticks : Int // 仅线路产出的累计 tick
}
// 线路产出档案
LineOutput {
line_id : String
line_type : "passenger" | "freight"
line_capacity : Float // 日总量上限(来自各交通分册)
period_weight : { // 四档权重,和 = 1.0
morning : Float, noon : Float, evening : Float, night : Float
}
day_modifier : { // 日历修正,按线路性质取值
workday : { ... }, weekend : { ... }, holiday : { ... }
}
in_transit : Bool // 冻结期间仍为 true
}
// 农田(第五类固定设施)
Farm {
city_id : String
tile_id : String // 归属「资源用地(农地)」
crop_subset : [String] // 3–5 种,来自全球 12 种池
yield_bonus : Float // 由城市特性决定(数值期待定)
is_fixed : true // 固定设施,不可自由选址
}
5. 边界与不做的#
不做城市之间的实时并发(任一时刻只有一城激活,其余冻结);不做线路的逐班次仿真;不做战役模式的跨城(战役是单一全局时间轴)
完整的「不管什么」见第 1 节;相邻系统的职责划分见第 7 节。 本节是防止分册无边界膨胀的关键——任何新需求如果落在这三条里,一律拒绝。
6. 相邻系统接口#
与哪些册交互、以什么方式、谁向谁提供数据。
架构边界#
| # | 边界 | 说明 |
|---|---|---|
| ① | 补算是解析解,不是重放 | 冻结期间的城市不做逐日 tick 重放。线路产出用封闭公式直接算出,复杂度 O(线路数)。这是防止「切回城市时卡顿 30 秒」的关键 |
| ② | 时段权重归本文,容量归交通分册 | 本文不重新定义 capacity;各交通分册的容量算法完全不变。本文只提供时间维度的分配器 |
| ③ | 冻结不得触发决策 | 补算只结算结果。需要玩家拍板的事项一律挂起到返回该城 |
| ④ | 农田不进交通网络 | 农田产出直接进本地市场,不占用跨城运力 |
| ⑤ | 作物池全局唯一 | 12 种上限在项目级生效,任何新增作物都挤占其他城的名额。修改需走版本流程 |
| ⑥ | 与战役时间轴隔离 | 本文规则仅对自由模式生效;战役模式仍为单一全局时间轴 |
与主文档的接口#
| 本文内容 | 对接文档 |
|---|---|
| 城市独立时钟 / 补算 | 《完整设计方案》§3 核心循环(三层时间)、《技术架构文档》§8 架构边界 |
线路容量 capacity | 《铁路与线路规划规格》、《航空公司规格》、《旅游公司规格》、《自建地铁规格》 |
| 跨城物流通道 | 《工业与供应链规格》§7 跨城物流与商品价格 |
| 农田地块归属 | 《城市与地区设计规格》§7 地块类型(资源用地 · 农地)、§7.6 固定设施 |
| 作物 → 配方 | 《工业与供应链规格》§4 配方、§5 资源地 |
| 补算清单 UI | 《主菜单与首屏 UI 设计规格》 |