team-remember-to-hydrate / battlecode23-team-remember-to-hydrate

GNU Affero General Public License v3.0
1 stars 0 forks source link

Strategy: Launcher Buddy System #40

Open mklapp2 opened 1 year ago

mklapp2 commented 1 year ago

Goal: Implement a system by which launchers try to pair up when possible to maximize their survivability.

Description: Launchers generally get one attack per turn. If they happen to run into range of 2 enemy launchers in a round (moving towards 1 and then the second gets closer too) then the lone launcher gets 1 attack for every 2 enemy attacks. A 1 on 2 battle with the lone warrior striking first results in the two enemies surviving with one at 8 health. A second attacker encountering this weakened pair and striking first will still lose and leave behind a survivor with 8 health. So under the best conditions of striking first, going alone twice is a losing strategy.

What we want is for launchers to 'pair up' and travel together, but not in a way that interrupts other goals the launchers might have and also not in a way that causes them to be confused about how to travel in any of their 'default' modes.

Implementation: If a launcher has a goal, it focuses on that and ignores the buddy systems. Presumably, the command that gave it the goal will also have caused it to be in a group with a common goal so they have a swarm rather than a buddy. Or the goal need is greater than increasing survivability by pairing up.

If it doesn't have an existing assigned goal (from HQ, an amplifier, or someone else broadcasting to the shared array), it will try to find a partner launcher 'buddy', while otherwise carrying out our 'default' launcher behaviors.

If it sees a potential buddy, it will immediately store that closest friendly launcher's ID as its buddy. If the buddy is not visible on a future turn it will be assumed lost and the buddy set to null again. The launcher will move towards the buddy until they are adjacent. The potential buddy will either have a goal already, or it already has a buddy and is in default mode while not searching for a buddy, or it will also be seeking a buddy passively while doing other default mode behaviors.

If they are both seeking a buddy, we need to make sure that once they pair up by getting adjacent, one takes the leader role and continues in default behavior while the other stays adjacent while also trying to fight enemies in range. To accomplish this, a bot needs to be aware of its buddy's ID (to know if it has a living buddy in sight) and also aware of whether it is a 'leader'.

Leadership determination: If one launcher is already on a mission, or is a leader, or is a follower of a leader, there is no issue since the buddy-seeker will keep trying to get adjacent while attacking enemies in sight, which is basically accomplishes the goal of pairing up. The edge case to handle is if two launchers have no goal and need a buddy and see one another. We don't want them to get stuck in a loop where they try to get adjacent, succeed, then start off on default behavior, then try to get adjacent again. Once a buddy-seeker gets adjacent to its potential buddy, it will keep track of that potential buddy's position. Important: A launcher that is adjacent to its buddy, but doesn't have 'leader' role active, will NOT move (except if an enemy is sighted and movement is needed to target it, dealing with immediate threats is more important than seeking a buddy). If a buddy-seeker observes that its potential buddy hasn't moved since the last round, the buddy-seeker will toggle amLeader to true and go to default behavior (which will result in moving, so the buddy will keep following it). A launcher will keep track of its buddy and retain leader status until it can't see its buddy anymore (should only happen if buddy dies). Since it has leader status, it should skip any buddy-seeking code (except confirming its buddy is alive) since it already has a buddy.

Edge benefits: If launchers in a self-defined buddy-group are seen by other lone launchers, they will make self-forming squads. It will be kind of cool to see this play out and should mean that our launchers generally have the numbers advantage in a fight.

Future Feature: If we confirm HQs can only spawn adjacent, we might add logic that if a launcher group of at least 8 exists, they will go into 'HQ Spawn Block' behavior if they see an enemy HQ. If the self-forming groups get big enough naturally this might be something that happens passively.

Concerns: -Are there some advantages to having more dispersed launchers? They presumably have a higher chance to find carriers that way (or at least more map coverage that makes it hard for enemy carriers and any other units that can't fight). -Maybe there is detrimental behavior caused during default behavior if we have a lot of launchers together. For example, maybe this interferes with logic to let carriers plant an anchor on a completely occupied island (no access to plant the anchor). -Minor concern, launchers will at some point waste a few turns pairing up every time a leader needs to be established.

mklapp2 commented 1 year ago

An update to this: The lecture player had a possibly better way to select a leader based on robot ID.