mgerdes / battlecode2015 Goto Github PK

On a match 3177 the SafeBug method seemed to navigate within range of the HQ. I may be calculating the upgraded distance incorrectly. Maybe there is another mistake...

There are many examples of this in the matches. We are swarming... then one drone dies and we retreat. Then one drone spawns and we go back. On larger maps this wastes a lot of time. We need a more fluid system that can have many things happening at the same time. We can be pestering, attacking, building tanks, etc. all at the same time.

In a stalemate situation, we need to build some handwash stations!

There's problems with the bug when players run into each other. They think the robot is like part of some bigger obstacle or something and try and trace around that obstacle, even if their in the middle of nowhere and the other robot is no longer near them. In MarkyMark I hacked a simple solution that ends the "following wall" thing if they have no actual obstacles around them. It kind of works but I'm not sure you'll like it.

Also I changed how bug is initialized. It has one init method that just takes in the robots RobotController at the beginning of the game and then this is never called again. Then when you actually want to bug somewhere you call a method called like startBugTo(MapLocation destination) to actually start the bug. I think this is slightly better but I don't know.

I enhanced the Bug class to avoid certain structures. It is accessed with methods like getSafeDirection...

Currently all of my bots are using this method, and it is very bytecode intensive!

We should have two methods or two classes to split up safe bugging and non safe bugging. I lean towards two classes, but I am not sure which division method would be better.

I imagine that Drones would use safeBugging when they are swarming the enemy, but the would use regular bugging when are doing fortify. Miners and Beavers would never use the safe mode.

I'm not sure what the best solution is for this.

I am thinking of a broadcasted value that would be the radius around the HQ where beavers and miners would be. Defenders could patrol this radius with my circle bug.

When sensing a terrain tile, we can only get OFF_MAP if it is within sensor radius. Otherwise, we are getting UNKNOWN.

This creates problems for CircleNav as it is impossible to go somewhere off the map. The Bug algorithm was updated to switch directions on the wall, so if a bot is circling it just goes back and forth on the wall... The CircleNav deals with this by checking if the robot is close to the wall. If it is, we go back to the "starting" rotation. This seems like a hack to me 👎

A more elegant solution would be to have data about the edges of the map. It would be a change that would go beyond the CircleNav class, but the data would be helpful for other algorithms as well.

I hope that we could find the closest edges to our HQ and then reflect with the enemyHQ to deduce the map size. There are probably other solutions too. Since this is a larger change, I will not start it now.

Micro all of the things

Drones are taking on three miners when they are alone, and they are dying. We need them to back off and wait until more drones come.

It may help for them to broadcast that they have spotted an enemy. Other drones could follow this signal instead of the normal navigation.

If we have enough miners in a small enough area, they form a solid line, and no one can through.

This makes it hard to move units, and it lowers the effective mining rate, because a bunch of miners get stuck.

Currently, we go tile by tile and stop if a tile is unknown. Instead, we need to keep going until we run out of bytecodes. We can go back on another pass to get the tiles that we skipped.

Examine options for dividing this among robots if it is happening too slowly.

We have talked about this a bit. We may want to determine a location that is close to the HQ and all of the towers. It is easy to figure out a path from that point to all of the towers, because we can do that on our side and we know the opponent's structures will have the same layout.

This would allow us to do one main path that would connect the two bases, and we could have smaller paths that would go from those points to the HQ. This is just an idea though...

The real issue is how we will handle the cases when we have unknown squares. I have a scout robot, but it is hard to guarantee exactly when the entire map will be known. We need to have the bot fail gracefully and fall back to other navigation.

If a job is added but can't be done because dependencies are not met, then make sure dependencies are built.

See match 8378, pile
https://github.com/mgerdes/Battlecode2015/blob/master/replays/save/Designed%20by%20Committee%208378.rms

We had launchers early, but we were trying to attack the enemy tower closest to us. This was very difficult to path to, so our launchers never go out.

We will block ourselves in and suffocate!

Robots can broadcast if they see an enemy near the HQ. Then the HQ can blow them away with the splashes.

There are situations when we have a lot of miners but all of the drones die. Then when the drones are spawned, they fly one at a time to the perimeter edge, effectively killing themselves.

See match 8378, voracious https://github.com/mgerdes/Battlecode2015/blob/master/replays/save/Designed%20by%20Committee%208378.rms

We did not fend off the commander rush because of soldier positioning and pathing. Our soldiers try to stay a certain distance away from the HQ, depending on how far away the miners are. The soldiers ended up in a corner, and when they saw the distress signal, they could not path to the enemy commander.

When do we need to build defense? Is this a map with a tower wall that will block rushes?

Do we see any enemies headed out way? Do we see any enemies being built?

On some tourney matches, we built 20 soldiers for no reason. If we know there is a tower wall, let's go straight to the big guns.

Currently, Miners and Soldiers will broadcast distress signals if they see an enemy.

Let's have towers broadcast distress signals, so we get earlier warning.

Many teams have a lower limit on the Ore that the miners mine. Currently we do not. If we implement this, we may mine ore faster.

There were many maps in the seeding tournament that had very little ore. On these maps, we should spawn fewer miners and adjust the minimum ore mining threshold.

Beavers is more than happy to build buildings all around it, and then it is blocked in.

Also, beavers will build a building in a 1-width passage 👎

All buildings, except for HQ and Tower, simply spawn a specific type of robot so just have one class for all these to spawn. I don't think they'll ever need to do something specific.

The drones wait until they have sufficient numbers, they they barge straight down the middle of the map. In a lot of matches, there were enemy drones that were unprotected on the edges. Picking these off is very valuable.

My idea is that we will constantly have some number of drones "pestering" the enemy. They can do a swam early but have very defensive micro. They can also sweet the edges of the map and destroy miners that are not protected.

We are getting owned in some matches