Odyhibit
commented
1 year ago I would like to have a conversation about the communication array, so we be on the same page,as to which bytes are for which messages. For example bytes 0-4 contain maplocations for creating groups. All bots check those and if they are i. The target area they self-join that group. Then bytes 5-8 contain orders for the groups. "Place anchor", "attack island", "scout map" what ever we need up to 16 commands
Goal: Implement a method/protocol (and a counterpart in a 'read comms' method) that allows a HQ or any other 'authoritative' unit to write to the comms array something that will be interpreted as assigning all units within range x of a position to a group.
Description: To prepare for an attack, it would be useful to assign bots and let them know they are meant to be part of it. While we could do this using botIDs, this is arduous and will consume a lot of bytecode. Instead, we could broadcast a position (12 bits, less if we choose to go with only vision-range precision implementation) and a range value indicating a selection area for the command. Additional information could be transmitted in a second byte including the intended group number value (first ~4 bits) with a set of flags representing what bots in the radius should join the group based on: -bot type (3 bits to cover all mobile bots) -if bot has anchor -whether bots already assigned to that group number but out of range should remain in the group, or drop their group membership -whether bots in range already assigned to another group should drop what they are doing --We could have the groups split by HQ so each HQ gets a specific number to play with. Or even have 'priority levels' such that a higher number is considered more important (and an additional flag showing whether all bots should be willing to switch, or just those already in a lower priority)
Pre/Co-requisites: This will also require the following implementations to be of use: -Bots track the state of their group membership -Bots can read the comms array and interpret it according to the protocol -Bots intelligently and selectively write to the array, leaving room for important info --Another way to handle this is bots could calculate the current round mod(13) or some other number and some rounds would be designated as map updates, others as time for commands, and so on. -How do we get newly spawned bots to hold still long enough for assignment? Maybe we have a rule that a spawned bot checks its spawning base and if that base has resources in excess of X (enough to make a swarm strat possible) then the bot moves up to 4 spaces East (or in direction it was spawned) and waits 3 turns before moving on. That should give the base plenty of time to produce units without having to tie up comms every round.