Discussion: long-range logistics revamp



  • @artch Thanks for the feedback and your thoughts on why.



  • Some rough numbers from me. There's a few unaccounted for factors, but I think it's mostly fair.

    Right now on shard 2 I'm:

    • Harvesting 181 remote sources across 108 rooms.
    • Spending 406 energy/tick on haulers for this
    • Spending 50 CPU/tick on haulers for this

    With 3 warp containers per room I think I could replace this with 289 warp containers and 108 "edge bounce" creeps each of which would probably be ~0.2 energy/tick and ~0.1 CPU/tick. Could spent more energy and less CPU, not sure what the optimal ratio is. Removing a container at each source (saving 0.5 energy/tick) and with 1 energy/tick upkeep on warp containers replacing with warp containers would save me ~40 CPU, ~200 energy/tick and a lot of spawn time.

    With 2 warp containers per room the simplest implementation would just be to halve my haulers in 2+ source rooms. Lets assume they're all 2 source rooms. That'd mean the replacement would save me ~20 CPU, and ~100 energy/tick. Now I can do better than this simple system in some rooms by placing warp containers between the sources and using one to feed two sources, but that's complicated to reason about.

    I think the above shows that 1 energy/tick upkeep won't cut it. I also think that 2 energy/tick upkeep with 3 per room won't cut it either. 2 energy/tick with 2 per room would start to be alright, but still a little cheap IMO (in my case, saves 20 CPU, costs 100 energy, without any optimisation.. that's a pretty good ratio IMO).

    I'm starting to reach 2.5->3 energy/tick as my price point. I quite like the idea of two warp containers/room as it makes solutions a lot less obvious, so I think I'd probably go with 3 energy/tick at 2 per room. Maybe a discount in highway rooms (back to 1 energy/tick)?



  • @artch Just curious why are creep haulers not a solution? Perhaps with some buffs to carry, uhm store, size. Increase battery to energy ratio, etc. Increase carry boost percentages.If the warp containers are going to sit somewhere in between, why would anyone use them? They will end up like tunnels barely getting any use due to being so expensive and CPU heavy. Needing to work with resource convoys or as an enemy trying to intercept them would add much more interesting dimensions to a siege then a 'pipe' system you can pummel anywhere at any time.

    👍


  • @tun9an0 I also thought about creep convoys with energy to help sieged colony. But depedning on the terrain your path will go through attacking squad or not. In first case it is very hard to keep haulers alive, sure there can be healers and attacking creeps or towers can heal them... But what if attacker just have more creeps and will intercept haulers easily



  • @u-238 said in Discussion: long-range logistics revamp:

    @tun9an0 I also thought about creep convoys with energy to help sieged colony. But depedning on the terrain your path will go through attacking squad or not. In first case it is very hard to keep haulers alive, sure there can be healers and attacking creeps or towers can heal them... But what if attacker just have more creeps and will intercept haulers easily

    The purpose of blockading a room is to prevent resource from going in. Otherwise while the attacker is spending a lot of resource attacking, the defender can just spam repairers. I think a good way to help the sieged room is to send a relief squad from another room with some energy/battery.

    However, currently this way is not quite efficient since creep carry capacity is too low. If we buff carry boosts to the level of harvest boosts, we will have an interesting way to help out a sieged room.

    👍

  • Dev Team

    @TuN9aN0

    Just curious why are creep haulers not a solution?

    It's a solution, but very complicated solution, hard to code. Few will be able to use it successfully as a real solution in their case. We need something inbetween easy terminals and super complicated creep hauling.


  • Dev Team

    Regarding remote mining: what if warp containers can't be constructed within X tiles from a source? (Due to energy interference it creates in the continuum.)



  • Would need to be a fair distance to have much impact i think, adding a few carry parts to a miner to move 2 steps out to deposit would be pretty easy way to handle warp containers a few steps away from the source. Would probably see a miner/hauler hybrid of sorts if the distance gets a little bigger, which would be kinda cool i guess.



  • I think the amount of warp containers in owned rooms needs to be higher than 2. You would want one at a central location, near your terminal/storage and that leaves just one at a room edge for connecting to other "networks" and makes it so you cant also use the warp container for other things like split bases, mineral harvesting, controller upgrading etc, sort of limits your options a bit with only 2 in my opinion. Maybe 3 for owned rooms and 2 for other rooms makes more sense.



  • Having to "man" the warp containers to cross room borders also feels a bit awkward. You would need to have a creep standing on the room borders and bounce between rooms, doing withdraws and transfers between them, sort of like a bucket brigade type system. Any way to make warp containers on room edges connect to each others without making it too OP?



  • @geir1983 said in Discussion: long-range logistics revamp:

    I think the amount of warp containers in owned rooms needs to be higher than 2. You would want one at a central location, near your terminal/storage and that leaves just one at a room edge for connecting to other "networks" and makes it so you cant also use the warp container for other things like split bases, mineral harvesting, controller upgrading etc, sort of limits your options a bit with only 2 in my opinion. Maybe 3 for owned rooms and 2 for other rooms makes more sense.

    You still have links though, and the last leg could also be creep based. I guess one issue I have right now is that I don't really see myself using these for anything other than making remoting more efficient. Especially if they're 2+ energy/tick each.



  • @geir1983 @artch How about a random amount of warp containers per room, between 1-3 that is a randomly assigned number so it gives each room an unique feel.

    👎


  • could the usage of warp containers be linked to how often and how strong invaders show up ?

    in a way that the more often / bigger volume / more warp containers are built in room (up to 3) the more attracted (and bigger) invaders are ? also as a bonus, it might attract the steal-invaders that would not attack, just try to take away resources from closest warp container

    in room without warp containers, there would be no breaking change, and for players wanting to utilize them (in remote rooms or claimed ones) there would be a drawback of more frequent / stronger invaders (should be a minor drawback for high RCL rooms)



  • Invaders are too closely tied to strongholds for that to be any sort of balancing mechanism.


  • Dev Team

    @gadjung Actually, this brings another idea: what if every Creep.harvest operation in the room decreases decay timer of all warp containers in the room? To the point it is still profitable, but much less profitable than using creep haulers?

    This will provide additional balancing mechanic that we can adjust for remote mining, but it doesn't affect use cases of "warp containers network" for transfer purposes only, even when this network is inside a sector, not just in highway rooms.



  • @artch Also this will affect network parts if it lies through remote harvesting rooms. Maybe in some situations there will no alternative paths other then through remote mining rooms. Maybe make it so if warp container is near the source this effect applies. Gradually like at distance <= 5 max decay to distance 20-15 low or zero effect. Or strict if distance <= 20-15 100% decay effect.

    👍

  • AYCE

    I think the idea, in general, is great of having an alternative to creep only or terminal only resource transport. There are a few things that seem a bit awkward though like warp containers not connecting to neighboring rooms.

    As an alternative proposal I would suggest:

    • 1 Warp Container per room.
    • Warp Container Transfer Range of 1 Room
    • 100k Build Cost
    • Internal Capacity of 5k
    • Decay cycle runs every 1000 ticks and does 500k damage. Requires repair
    • Transfer Damage = resourceAmount * 5;

    New Functions:

    • WarpContainer.repairFromInternalStore(amount: 500) // heals 25000 hitpoints
    • Creep.opperateStructure(WarpContainer, {transferTarget: room, resource: energy, amount: 5000})

    Decay Cycle That Decays on Timer 1000 Ticks Does Damage to Structure Can be Healed with a function. WarpContainer.repairFromInternalStore() at a rate of 50 units per energy. Or a creep can use a regular style repair for 100 repair points. I think the cost should be 5 energy units per tick equivalent. There should also be damage done during the transfer function.

    Needs Creep to call a function to transfer resources. Range 1. This means that if you let an enemy player near it they can transfer out the resources forcing you to defend the warp container from enemies. This solves the issues around ownership.

    If a player executes a transfer it becomes "reserved" by that player. If another player transfers it becomes neutral. This makes it similar to reserving controllers currently.

    👍


  • @atanner I love the idea, since it solves a lot of problems we have at the moment. However, I think this "reservation system" can have problems when different players try to issue conflicting commands, and ownership can be simply flipped when a player issue two commands in a row.

    I think the reservation system can be the same as controller reservation, and the warp container does not decay when it is reserved, since a claim creep is already necessary to maintain warp containers, and a creep is not necessary to operate the warp container, making warp containers easier to use.



  • @atanner like the idea

    only thing i'd be hesitant with "reservation", in my opinion there should be no reserved for X ticks etc

    One thing that could be also viable is to scale decay damage with how much stuff is in container - depending whether devs intent would be to push towards more or less often transfers

    In case 2 or more creeps try to transfer - i'd say the one with more WORK parts (or just bigger one) should take priority if both have same size/WORK amount, then can be age (priority for older one for example), distance/etc

    @artch @U-238 did not do enough remote mining to have opinion how it might impact the economics of Creep.harvest decreasing decay timer



  • I like both ideas of putting a minimum range from sources and decaying the containers from a harvest action. @U-238's idea of allowing the warp-containers to be closer but increasing cost seems like a good one (more remote mining options the better). I think the decay should be based on energy harvested from the action rather than the action/intent itself otherwise supersizing the harvesters could bypass much of the problem.

    Even cooler if we get a new visualization in the client to "show" the sources reacting with the warp-containers when a source is harvested.