Strategy: Internal Map Representation

[mklapp2]

Goal: Implement a MVP implementation of a bot's internal map

Description: There are lots of things a bot could do more optimally if it only knew the map layout. Things such as navigating, precomputing fast routes between adjacent 1/16ths of the map, noting what parts of the map are reachable by movement or actions (due to walls/storms), and just knowing what direction to go to reach the nearest island are all made optimal if a unit has an internal map model.

That said, a lot of things are possible without a map, just by having the units 'told' what location to go to and for what reason. So in some ways we might be better served by focusing on how to meet these goals without a map and save map reliance only for things that a map is truly needed for (such as optimal long-distance pathfinding).

The minimal implementation will be to formally create a standard (open to change) that is capable of fully representing a base map (not mobile units).

Future Implementation Goals might include:

• tracking key mobile units (anchors)
• re-implementation to reduce memory usage, bytecode usage during use, or communication cost to establish

[Odyhibit]

I will be implementing the map part, it will be a 60 x 60 array of bytes. Java will interpret the bytes as -127 through 128. So we can use them as is, or simply add 127 and use 0-255. That should be plenty of information to describe a map square. This is important for movement even if we do not communicate map info between bots.

[mklapp2]

That sounds good to me. If you didn't watch today's video on communication and pathfinding, you definitely should do so before starting on this. I know you are very comfortable with bit shifting / bit packing so some of it will be review for you, but I have to think there are things they will discuss that will either be directly useful or spark useful ideas.

[Odyhibit]

Their method was the same way I did it. There might be a way to pack a little more data in there. I am playing around with using the extra padding on numbers. 2**16 is 64 so 64x64=4096 available numbers. The largest map is 60x60=3600, so there are some spare numbers in there. Not spare bits, but there might be a way to use those extra numbers. Especially if we detect the map size, and adjust the useable addresses. Probably just start with static padding it will probably be enough.