-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Strategy: Carrier Conveyor Belt #18
Comments
@1NF053C You might want to look this one over since you are working on a lot of carrier logic. |
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? 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. |
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. |
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. 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): 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. |
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: |
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:
Considerations:
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.
The text was updated successfully, but these errors were encountered: