欢迎光临散文网 会员登陆 & 注册

PLAN-B terraform量化数据分享(2)

2023-05-04 15:38 作者:蜡笔桶  | 我要投稿

量化计算可以帮助我们简化流程避免冗余,它一般分为三个方面:资源产量、建筑数量、物流速度。

在操作上,先根据最终所要达到的终端资源产量反推计算之前每一步的所需产量,再根据每种建筑的年产量计算所需的个数,最后沿途检查物流系统能否保证及时供给。

    细心的同学可能已经发现了,在上一篇专栏中我们只介绍了三步量化的前两步,并没有提及物流,是因为这个游戏的物流系统实在是,呃,非常有特点。

    往好处说,作者刻画了非常多的细节,比如仓库无人机会在确认需要搬运的货物后,从所属仓库的停机坪出发、前往货物所在地、携带货物前往目的地、再回到停机坪充电,每一段路程都有加减速的过程,并且每个无人机都是独立行动;又比如卡车/火车会根据道路拥挤情况(与前车的距离)以及上下货速度(无人机数量/效率)智能调整车速,假如道路足够拥挤(车足够多)的话甚至会卡死整条线路导致车辆全部无法动弹。

    往坏处说,这些细节都会实时影响运输效果并且让你的电脑变卡,给整个物流系统的量化工作带来了非常多的变量。而缺乏量化的物流,就会导致整体规划出现各种莫名其妙的运输瓶颈,从而达不到设计的额定产量(例如上一篇专栏文末所示的情况)。

    本文将通过一些实验数据来对物流系统进行一个粗略的量化。


短程(单个仓库)

首先来看一下仓库,1/2/3级仓库可以覆盖距离自身1/2/3格内的范围,并带有1/2/4个无人机。

本游戏的物流核心就是仓库的无人机,它的行为逻辑可以分为三类:

    1.入库,从仓库出发,将供应端的资源搬到所属仓库储存

    2.出库,将所属仓库的库存资源搬到需求端,再回到仓库

    3.直飞,从仓库出发,将供应端的资源直接搬到需求端,再回到仓库

我们可以通过构建一些特殊的布局,来测定不同情况下无人机的运输量。

游戏中共有几十种直飞路径,精确到每一种情况的量化既难以完成也没有意义,我们的目标是得到一个泛用且稳妥的运输量下限,为此可以先做一些简化,减少不同的讨论情况。

直飞VS入库出库

注意到大部分情况下直飞时无人机路径是一个三角形,这比先入库再出库的两次折返路程更短,也更节约时间。因为我们需要的是运输量下限,假如只看出入库,则仅需考虑5种情况,即下图红圈中的5个位置。

废物处理厂代表供应端、供给中心代表需求端,图中列出了所有不重复的无人机路径

在测试过程中发现,除了测试所针对的距离差别外,以下因素对运输量也有较大影响:

帧率越高,运输量会随之下降

游戏进行速度越高,运输量也会随之下降

这就导致,虽然每个样例的测试本身除了时间消耗外没什么难度,但在不同的测试环境下往往会得到相去甚远的测试结果,可见制作组是真的很想劝退玩家的微观管理(法国人:差不多得嘞)。建议大家不要太过在意具体的数值精度,有个数量级的概念、再横向比较一下数量关系就好。有能力有想法的同学也可以在此基础上另行测试。

测试样例

如上图所示,我们构建了一个3级→2级→1级→3级的结构,泵站产出的水会逐步向右运输。其中左侧的3级仓库负责塞满2级仓库,右侧的3级仓库负责将1级仓库收到的水集装箱平均放置,而2级→1级的运输过程是我们关心的实验目标,由且仅由2级仓库完成。

测试持续进行,每隔150天(半年)暂停记录右侧1级与3级(合计40个)仓库的库存,多次测量并处理后就可以得到2格距离上无人机的年运输量。

通过改变仓库距离和布局,我们就可以得到所需的5个位置的运输量。在这个过程中,由于1级仓库无法构建单方运输、3级仓库会和两端的辅助仓库互动干扰测试流程,因此设计了如下几种不同的结构类型。

测试用例一览,运输方向均为从左至右,白色仓库代表无人机未出动

将我们关心的5个位置按距离命名,分别为一格、偏两格、两格、偏三格与三格,在本文截稿时共测取以下这些数据(在同一个地点、5倍速+60帧的环境下),表格中为测量得到的年运输量除以参与测试的无人机数量得到的每架无人机平均运输量:

每架无人机平均年运输量

来分析一些数量关系并进行一些推测

  • 入库的运输量比出库少大约20%,同时出入库的结果接近两者之和

    按比例推测一格距离的入库量在154左右,出库量在192左右

  • (直线)直飞虽然路程上两倍于入库,但运输量非常接近

    因为测试选取的直线构造是所有直飞路径中路程最远的,推测其他直飞运输量均在此之上

  • 偏两格、两格、偏三格、三格的(直线)直飞运输量乘以运输距离(偏两格按√3、偏三格按√7估算),乘积分别为163、172、174、174

    一格、偏两格、两格的出入库运输量乘以运输距离,乘积分别为171、194、200

    大胆猜测,运输量与距离成反比,但由于无人机存在加减速过程导致一格与偏两格的距离上平均速度较低从而影响运输量。

有用的信息暂时就这么多,如果对大家有什么启发或者说有什么进一步的发现也欢迎给我留言反馈。


中短程(多个仓库联动)

每个仓库的无人机会试图在覆盖范围内所有同种类仓库间进行库存均分,这在之前的单仓库测试布局里已经有所体现。均分意味着无人机们会从(覆盖范围内)库存最多的仓库往库存最少的仓库进行搬运,为了避免来回搬运,只有两个仓库的库存差不小于2时无人机才会行动。

如果将多个仓库排成一串,且两端存在稳定的库存差(一端有供应/需求),资源会在仓库间稳定地转运,从供应端流向需求端。因为库存差为1时资源不会搬运,因此仓库的实际库存上限会随转运次数递减,最远可以转运39

举例而言,假设有一排仓库,每个仓库仅能覆盖到前后相邻仓库,且仅有首个仓库的覆盖范围内存在供应端(并称其为最大距离仓库链)。为它们依次编号(记为#1、#2、#3……)则:

#1可以储存到40个上限

#2与#3可经由#2的搬运,达到39个上限(此时与40仅相差1,#2不会继续搬运)

#4与#5可经由#4的搬运,达到38个上限

以此类推

#78与#79可经由#78的搬运,达到1个上限

#80无法获得资源

最终库存稳定(没有无人机继续搬运)的情形如下图所示

2级(最大距离)仓库链,左上角的#80为0库存

1级仓库有点特殊,测试表明它在直线排列时不会执行直飞操作,最远只能运送到#40

直线型1级仓库链,在#10、#20、#30、#40旁放置空白仓库以方便计数

但若存在夹角,仍能执行直飞,在足够曲折的路径下依然可以运送到#79

折线型1级仓库链,同样放置空白仓库以方便计数

在此基础上,若#2~#80(直线型1级仓库为#2~#41)覆盖范围内存在任意需求端(供应中心/工厂类建筑/起点车站等),无人机从仓库搬运资源满足需求的过程就会破坏仓库链的稳定状态,构成转运所需的库存差。于是从供应端到需求端的沿途仓库会稳定单向地运输资源,起到类似传送带的效果。

原则上,2/3级仓库链可以在相距最远162/243格的供应/需求端之间运输物资,但运输能力会随链条长度增加而下降。需求端在#20以内时,仓库链上所有无人机可以同时运转。对更远的需求端,仓库链无法全程维持转运所需库存差,因此无人机会轮流工作,降低整体运输量。

以2级仓库构成的最大距离仓库链举例,不同位置的需求端对应年运输量分别为:

#20以内约为267

#30约为236

#40约为199

#50约为156

#60约为108

#70约为82

#80约为36

密铺的仓库链可看作多个最大距离仓库链并联,但会有一定程度的内耗(本可以由A到B一步到位的运输变为A到C再到B的两步),实测密铺2级仓库链#20以内的运输量在360左右,显著小于267×2。

此外,仓库链中还存在无法被搬走的下限库存,例如你的需求端挂在#10,则#10与#9的库存可以被#10的无人机搬空,#8与#7库存为1时不会被搬走,#6与#5库存为2时不会被搬走,以此类推。当你构建仓库链时产出会优先填充这部分库存,仓库链越长这部分库存也越多,例如#30的需求端需要210的下限库存,意味着你搭建完30个仓库之后得过个大半年资源才能运到需求端。

结合以上两点,不建议使用长度大于#20(2级仓库40格/3级仓库60格)的仓库链,更远距离建议选择道路运输。


长程(道路运输)

道路运输包括公路(卡车)与铁路(火车),作为物流系统的一环似乎并不难量化,因为它们自带运输量统计。但值得一提的是,面板运输量的数字后面带有(最大),表明它是一个上限值,并不代表实际运输量。

往运输线路里塞1000辆车并不能真的获得面板所示的上万运输量

我们首先看一看这个数据是怎么计算的,然后介绍影响实际运输量的两个瓶颈因素。

根据常识推测,(单辆卡车的)年运输量与每次运输耗时成反比,若耗时以天为单位计,则两者乘积即为每年的天数300.

调整面板卡车数量可知总运输量与其成正比,卡车数量越多,平均单车运输量精度越高。

建立不同距离的运输线路,分别测量1000辆车时的面板运输上限,可得以下数据:

1000辆车的总运输量为整数,意味着单车运输量精度在千分位

可见耗时随距离变化的差值非常均匀,这表明面板运输量的计算逻辑非常简单,即:

总运输量=300/(路程耗时+固定耗时)*车辆数

其中路程耗时与路程成正比,固定耗时用于上下货以及加减速阶段,单位均为天。

上面的例子中,由于运输距离极短,1000辆车具有上万的面板运输量。实际情况又如何呢?

车辆数瓶颈

在同一条运输线路里的车需要排队,并会根据跟车距离调整车速。当数量过多时,会因为车速过低反而降低实际运输量,极端情况下甚至会寸步难行。

经过测试,面板总运输量到450左右时,等待上货的空车会从起点排到终点,影响终点下货。

面板总运输量达到700左右,等待卸货的卡车会从终点排到起点,于是运输线路会全线卡死。

车辆数瓶颈与运输距离无关,后者只影响堵路/卡死所需的卡车数量。

上下货瓶颈

卡车的运输量也受限于起/终点负责上货/卸货的仓库,这里可能存在一个“抢单”环节:当卡车到达起点时,起点需要一定的时间为其匹配某一仓库的某台无人机,两者确立联系后卡车起步且无人机起飞,下一辆卡车待其出发后经历一个短暂的加减速过程到达起点等待匹配。

如果无人机的供货路程较远,还会出现这种追车现象

“抢单”环节与排队候车两部分所消耗的时间就会导致,明明有冗余的车在排队,也有冗余的无人机在待机,但运输量就是上不去,存在一个软上限。并且这个软上限还会根据游戏速度以及帧率而变化,倍速越高、帧率越高,运输上限越低。

在60帧的环境下,1/3/5倍速的公路实际运输上限大约在300/180/150左右。


火车的情况稍有不同,由于一辆火车有30个仓位,当火车头到达起点时,起点会为其匹配30架次的无人机运输,期间火车会缓慢前行,直至仓位塞满或车尾离开起点后开始加速。因此,火车的上下货瓶颈更多地体现在无人机的运输效率上。

注意到火车面板运输量是定值,不随仓库距离/数量改变,说明在计算面板值时所用的过站时间也是定值,若实际过站时间短于这个值,则实际运输量会高于面板值,此时面板上的(最大)名不副实。

火车的上货机制会带来比卡车更过分的追车效果

通过在起终点附近放置不少于8个3级仓库,确保同时满足30架次的无人机运输从而尽量减少火车低速过站的时间,1/3/5倍速的铁路实际运输上限大约在每年54/51/43车,即1620/1530/1290左右。

本文由于测试数据非常费时且相当枯燥,从开题到结题拖了有近两个月,收尾也略有些仓促。

感谢大家看到这里,希望能对大家的游戏体验有所帮助。

PLAN-B terraform量化数据分享(2)的评论 (共 条)

分享到微博请遵守国家法律