The Goal
Rather than have bots randomly/blindly working their way around the map it would be super useful for the bots, and the team as a whole, if they could see the overview of the entire map as we do. The goal here would be to take a snapshot of the map and give that to each of your individual bots.
The Method
You start out with scouts that roam the map as quickly as possible. Their mission is to find the edges. Learn the size of the map. Record knowledge of everything they see and encode it into the broadcasting channel.
They don't need to worry about being covert because they will move everywhere and quickly. As long as they don't draw the opponent towards the base of troops you are building up, they won't cause any damage.
One useful trick here is you can quickly detect if the map is mirrored horizontally, vertically or rotationally. As soon as you see something, you know that there should be the same something in one of a few specific places. If you don't find a matching mirrored item you can quickly narrow down the type of map. As soon as you pinpoint the type of map, then you know that every time you learn one thing you actually have learned two things because the same thing is now in another known location as well.
Map Reduction
Keeping precise information of a very detailed map, even a small map, would use a lot of space in your broadcasting channels and take a lot of bytecode to both read and write. The solution to this is to reduce the data you store, to generalize information into segments with a much lower overall resolution than the actual map.
Some maps will be small and some large, but the data you store can be kept in a standard size. Pick something that is easy for you to translate into an encoded message in your broadcasting channels. Maybe the snapshot you keep is of a 20 x 20 map for example. If you happen to be on a 100 x 100 map then each 1 x 1 spot on the snapshot would represent a 5 x 5 sector on the actual map. If you found yourself on a much smaller map you would still use the 20 x 20 snapshot, or whatever size you choose, only that now each 1 x 1 of the snapshot would represent the general data of a smaller area in the real map.
You may want a much smaller snapshot, this all depends how much you can keep up with and how much time you want to spend interacting with it. Even if the map is not square, like the "Line of Fire" map, you will still keep the standard snapshot size.
Map History
This snapshot won't always be kept up with and won't always be live. That saves you a ton of processing power that you can apply to other tasks. The key here is that you store a generalized snapshot of the world and slowly update small pieces of it as desired over time.
You won't be tracking full movements of the enemy and keeping them live in the map. However; in general you will know where they are (or have recently been actually) in relation to you. It would likely be too expensive to keep up with fine grained information but the general knowledge could set you far ahead of the opponent.
When the match begins you will quickly learn the size of the map and where you are on it. You will learn things like how dense the map is with trees and be able to set strategies based off of this information.
Applying Knowledge
This low quality view of the generalized map can be used to make high level decisions. It can guide your strategy and can make difficult tasks like path finding much more efficient and effective.
Knowing that you are on a map which is almost all trees vs being on one that has almost no trees could influence your strategy. Bots won't have to blindly head off in a direction, they can first check for map density or danger factors.
Pushing The Envelope
You can take this idea as far as you like. If you really wanted to get crazy with it you could build some cheap bots like scouts and sacrifice them for processing power. Meaning maybe you want to let them use unlimited bytecode while they camp out in a relatively safe zone. They can spend several clocks working out larger problems like path finding. Slowly storing off the information as they go so if they die another can spawn and finish where they left off.
I say sacrifice because they are not going to be concerned with their own bytecode limit but push through it to solve a larger task for the team to use. Knowing full well that they will likely die before finishing. Maybe it would be smart to have some bots protecting them.
They could store their results in this snapshot, like general way-points. This way your individual bots won't need to rework these problems. They can simply refer to the way-points like a lookup table so if they find themselves in a certain area and they want to do a certain type of task, it will tell them which area to head towards next to accomplish that.
As far as path finding goes, you could detect edges within the view, the snapshot, to quickly make decisions about when it is best to go around an area instead of trying to dig through it.
They could store their results in this snapshot, like general way-points. This way your individual bots won't need to rework these problems. They can simply refer to the way-points like a lookup table so if they find themselves in a certain area and they want to do a certain type of task, it will tell them which area to head towards next to accomplish that.
As far as path finding goes, you could detect edges within the view, the snapshot, to quickly make decisions about when it is best to go around an area instead of trying to dig through it.
Of course you could use your archon for all that processing but likely those are doing much more important tasks and you don't want them to bog down with bytecode limitations.
