Say you make a huge miner creep that has as much WORK as possible on it. To really cram that WORK in there, you sacrifice the MOVE necessary to move even once a tick on roads. Maybe as little as one move per 3 or 4 ticks. You don't want to boost this miner's move because once it's at the site it's not moving ever again, and that only takes a couple hundred ticks. It really seems like it'd be a waste. But! If we could instead boost a creep temporarily, rather than for the life of the creep, this gets to be a lot more efficient.
I propose changing boostCreep(creep, # of parts) to boostCreep(creep, # of parts, # of ticks)
This would also require adding a Creep.body.boostRemaining variable to track this value.
boostCreep would now only use a fraction of the boost compound based on either the # of ticks or the creep's remaining life if the parameter is left empty. Energy usage would remain constant to incentivize going for longer boosts as compared to the shorter ones. The scale would work in steps of 50 with 1450-1500 ticks taking 30 compound and 0-50 taking 1 compound.
poma last edited by poma
Honestly it feels like increasing the game complexity for edge cases. The only cases I can think of that use this mechanic are boosting MOVE parts for creeps that travel to a single destination and boosting CARRY parts for one-way trucks. Can you provide some more examples?
Plus boosting one-off creeps like power haulers maybe... Not the best example tbh because they can be recycled to recover leftover boosts.
SteveTrov last edited by
I have an attack type that I call blitz that would benefit from this feature.
The idea is that I spawn a number (normally 3) large T3 dismantle creeps and do as much damage as possible to the enemy ramparts before they can get defenders out hopefully breaching them.
Once the enemy spawns defenders these creeps are useless
But this feels rather niche, and as o4kapuk said for most usecases its only slightly better than using recycle.
for most usecases its only slightly better than using recycle.
That in lies the problem I suppose. A lot of the functionality here overlaps with recycling.
Honestly it feels like increasing the game complexity for edge cases.
I'd argue it's not really adding complication to the end user's code. The (undefined) default would still boost the creep's parts for its entire lifespan. The new variable on boosted parts likely wouldn't affect anyone adversely, and I think it unlikely many even use the existing boost variables on the individual creep parts. This is just an idea to give us more flexibility for creativity, especially since the devs are actively trying to increase the costs of boosts. Perhaps when power creeps come out (hahahahahahha) then this idea will offer greater usability since they have the potential to legitimize many more niches for creeps.