Strategy: Carrier Conveyor Belt

[mklapp2]

Goal: Implement a method by which a carrier that is blocked (by other friendly bots) from returning resources to the base will check for other carriers closer to the base that have an empty inventory and transfer the resources to them instead.

Benefits:

• Saves movement
• Prevents some gridlock scenarios (many carriers near base, base has single entry path) **<--needed for any map having a base with a skinny 1 cell wide tunnel entrance.
• Might be more efficient than trying to walk the resource in itself

Considerations:

• Is there a disadvantage to interrupting / suddenly burdening the outgoing carriers?
• Does our current carrier implementation have good compatibility with this? Do carriers, before they move/act, check what they are carrying and use that to determine their behavior (whether to grab/plant anchor, mine resources, transfer resources, and where they plan to move next)?
• Will this interfere with our Group Assignment implementation plans? We could set it to not ever try giving resources to an assigned unit. Or one with group assignment priority above a certain threshold.

Future Implementations: Can form carrier conveyor belts from the mines (or to islands). A chain of carriers may move mass faster since they don't have the 'overloaded' movement debuff. Unrealistic Implementation: In a perfect world, they would arrange in turn order such that in a single round a full load could be transferred from mine to HQ.

Related Ideas: Moving Anchors out from a gridlocked HQ could work similarly.

[mklapp2]

@1NF053C You might want to look this one over since you are working on a lot of carrier logic.

[Odyhibit]

Is there a disadvantage to interrupting / suddenly burdening the outgoing carriers? Doesn't seems so. Just increases the action cooldown on transferring bot. Would require bots to check if they are full, and change state. Mine do that already. It's how they know to head to a HQ.

Does our current carrier implementation have good compatibility with this? yeah, it should be fairly straightforward

Do carriers, before they move/act, check what they are carrying and use that to determine their behavior (whether to grab/plant anchor, mine resources, transfer resources, and where they plan to move next)? Mine check if they are full, and choose their birth location as the next destination. Having a few more options controlled through a limited number of states should be ok.

Will this interfere with our Group Assignment implementation plans? Don't think so. States for the carriers should have a priority, and anchor delivery carriers should not have a goal of getting to a HQ. Being in an attack group means the carrier is not resource gathering and the code you propose should be in the RESOURCE state.

I was imagining a scenario where a line of carriers pass the resource back to the headquarters without moving. Just draw, then pass down the line like an old time water bucket line. I would need to figure out the action point cost for that stuff to see if it would really be cost effective though. If it takes one turn to draw 2, then one turn to pass 2, we would be getting 1 per turn. But like a pipeline it would be steady, and could be augmented with 2-3 at the well end, passing to the line of carriers. Would cause some navigation headaches for other bots.

[mklapp2]

To address navigation headaches, the conveyor belt / bucket line could stagger themselves like checkers pieces so they are all diagonally within transferring reach but other units can move through the diagonal gaps. This would not fix the concern if we have maps with narrow 'tunnels', but that is also the kind of map that really benefits from units passing resources when blocked.

[1NF053C]

Scratch notes for self:

---

One such feature is getting carriers that are carrying resources to a location first check if there is an adjacent carrier in that direction that it could pass the resources to. This helps them more quickly move resources by taking less steps and we could experiment with triggering it when the carrier is 100% full or at 50% to see if it makes deliveries more timely or efficient. I think once a critical carrier mass is reached this will allow for much faster 'water brigade' style resource passing. Similarly, it can be done with anchors. https://github.com/team-remember-to-hydrate/battlecode23-team-remember-to-hydrate/issues/18

Another feature that @Odyhibit has mentioned but I didn't see on the issues board is giving carriers some logic to handle feeding/upgrading a nearby resource well. The conditions that might trigger this behavior could include some combination of having enough nearby friendly units, the round number being high enough, and the bot location being centered on the well. An upgraded well allows 3X the extraction rate, which would be very useful for our closest wells.

---

Odyhibit: I wonder if we could use a leapfrog method move resources? Like @OmicronOmega | mklapp2 mentioned above about passing resources to a closer carrier, then once empty the first carrier moves 2 spaces. Now carrier 1 is one space ahead of carrier 2. Then repeat. We could effectively move one full carrier worth of resources 2 spaces per turn instead of 1 space per 2 turns. I will have to do the math to see how much of a benefit that would be, but it would increase our early game resources.

OmicronOmega | mklapp2: I forgot about how they can potentially move twice when 'empty'. Great idea!

--

The one piece that might be particularly pertinent to carrier strategy is this (edit: 7:15 AM post): https://discord.com/channels/1051994161546526811/1051994161546526818/1065288388502093874 I think it can be implemented as a separate feature (new feature branch) once the Carrier Conveyor Belt is implemented. It would be more relevant where we don't have many carriers present, probably for 2 carriers to pass an anchor but also possibly useful in the early game.

One suggestion for Carrier Conveyor would be to start passing resources as soon as half-capacity is reached. I don't have documentation in front of me, but I think passing too often ties up turns that could have been spent drawing more from a well, and passing too late (full capacity) might hinder early game (or fresh start after an enemy attacks) since the carriers will all want to wait until they are full and then the passing has no effect if there are only 2 or 3 of them since they are all full.

[1NF053C]

After checking robot controller implementation, it turns out that resources nor anchors can be transferred between carriers - I'll close this issue for now - if battlecode receives an update that allows this to happen then I'll be ready to implement that is for sure!

Here is a feature spec that can be worked from if carriers ever gain the ability to transfer resources/anchors: carrier-conveyor-belt1.docx