add map height/width to constants

[halitechallenge]

add map height/width to constants

[YoavRamon]

game_map instance (from game.game_map) has height and width values

[snaar]

Sure, but it's inconvenient. For example if you want to do any sort of normalization outside of game_map class, you have to pass height and width around. It's a lot nicer to have them as constants since they don't change during the game anyway.

[anuzis]

height and width are not constants, though. They are configuration parameters which change depending on the size of the map. Indeed it would be inconvenient to pass them around everywhere. A good solution is passing them once and storing them as class attributes in whichever class handles your AI decisions.

e.g. My implementation has a HiveAI class which gets initialized with the GameMap and stores HiveAI.map_width and HiveAI.map_height so the values are easily accessible to any ShipAI (or anything else) relating to where decisions are made which may want to know width and height.

[snaar]

We already have max_turns in constants. That also depends on size of the map.

Storing height/width locally is fine, but then would you really double the size of position objects so that they can have height/width along with x/y so that positions can self-normalize? Seems a bit excessive.

[anuzis]

Good point on precedent with max_turns, and having height and width in constants is likely higher utility to have easily accessible.

Agreed height/width shouldn't be duplicated in every Position instance (instantiation of which is already in my bot's top 5 time consuming activities via cProfile since Positions are used so often). Adding a normalization method to positions would also be convenient.

It might even be nice to normalize Position instances automatically at the time they're instantiated, since why would anyone ever prefer a non-normalized Position? Only downside is the extra processing, and Python devs are already at a relative disadvantage there.

[coreylowman]

i was just running into issues about this... since hash and eq for positions aren't released yet, i've been extracting the x and y into tuples and using those tuples in dicts and sets instead. but because positions aren't normalized automatically, that wasn't working as intended (and causing timeouts) because to the tuple hashing algorithm (0, 0) is different than (32, 32) (even though in a 32x32 map they are the same).

additionally the hash and eq methods won't even work as implemented currently because of the positions not being normalized, and they won't work unless normalization is automatically done.

[coreylowman]

Actually isn't equality broken for all starter kits since normalization isn't done automatically in any of them?

>>> Position(0, 0) == Position(32, 32)
False
>>> game_map.normalize(Position(0, 0)) == game_map.normalize(Position(32, 32))
True

Isn't that a huge issue? Path planning depends hugely on skipping already checked positions. if people aren't using normalized positions then their path planning is doing a huge amount of extra work.

[snaar]

Python has work-around pushed via #176