As the code generates Supply Structure, they're built in a haphazard manner, which leads to random and at times clumped regions of supply structures. Is there a way to arrange these structures in a geometric manner w.r.t the townhall?

When we start up StarCraft II from Python, we get a "blue square" in the middle of the screen. I believe that we should have seen an outline of the map that we're about to load.

Maybe this is because we should have downloaded all of the maps? I only downloaded 2017 Season 1.

So both the enemy bot and player bot can be defined in several ways. In the case we want the enemy bot to use a DNN or a rule-based procedure, it should handle it the same way it is handled when we're running a regular player bot.

Need to be able to detect gas/mineral depletion to factor that into the maximum possible number of workers we should have.

Currently, the scout simply goes through a list of coordinates to look for an enemy. We could use bitonic tour to guide the scout more efficiently from place to place.

Also, if we require that the scout "shows" more of the map for us, we could do a "reverse" bitonic tour where we simply have it go to the next location that's furthest away from it so that we can see more of the map.

It's difficult to keep a worker-scout moving as a scout due to the method distribute_workers() affecting it at a moment's notice. It'd be nice to exclude it from the list of workers that are employed in that function and/or "cloak" it programmatically so that distribute_workers() doesn't notice it. That's the only way I could see us being able to use a worker-scout

Title says it all. Even though our scout is going to every single potential hotspot, it takes time before we find a new enemy unit/building. I'm guessing this is due to the fact that we

1. Only have 1 scout
2. Enemy's cloaking some of its units

I'm not sure how to remedy this. Should we have an "enemy-scout" and a "home-scout" and split the map in half, thus splitting the expansion areas as well? So one would take the first N/2 expansion areas that are closest to the enemy's base and keep looking over there. This is slightly more complicated and I'd rather see how players would normally deal with this (which is probably by looking at "hotspots" that the enemy's more likely to use.

Until we figure this out, we'll stick with playing against the computer in Medium difficulty.

It's not enough to make sure that the worker scout is not gathering, we need to also make sure that it is not doing "anything that will hinder its objective".

Try to check every once in a while what the worker scout's "orders" are and see if they align to what we requested it to do (either by name or by something else). That way, if we notice that it's veering off course, we can force it to play the objective.

If we've reached full capacity (or about to reach full capacity), stop building anymore supply building, combat buildings, or combat units.

When plotting intel, we need to make sure we plot in this order:

1. Townhalls
2. Gathering/Scouting structures
3. Gathering/Scouting units
4. Combat structures
5. Combat units

Doing it in this order makes sure that we see the right kind of information every time and since combat units/structures are more prominent, the model builder will have more info to work with.

During the coroutine build_assimlators() in core/protoss.py, For some reason several Probes are sent to craete a geyser at the same resource position.

Perhaps it's worth checking if a worker has already been tasked to go to that position. If so, then they should ignore the command to build a geyser at that particular vespene resource.

It's an issue similar to the vespene gas buildings.

The scout gets close to enemy territory and can die from time to time. It is advisable to increase the distance it needs to be from its target to be considered "good". Code has been added to tell whether a scout has died and increment the distance away from target based on that.

What about obstacle avoidance? If the scout has gotten close to an enemy, it should try to get away from it but still go to the target. This is starting to become a pathfinding problem. I'm unsure if we want to do that or not.

When I'm under attack and lose a nexus, apparently the computer thought it'd be a good idea to build 3 of them...I don't know why.

I specifically demanded that it only produced 3 at most. This is concerning

I can't figure out how to extract Point2d value from a UnitOrder that a worker has received. This problem led to several workers being tasked to "pend the build of an Assimilator"...ended up having to make another class attribute to keep track of pre-pending builds

in the gather_intel() function, we kind of expect that the map given to us will always be a 176x200x3. In the case where this changes in the future, do we want to make this new size evident in the model generator? If so, how do we propagate that?

Rather, should we just always expect it to be 176x200x3 and always double check and make sure that our intel has the right dimensions? If so, then it'd be best to add a class to utils.py, check in gather_intel(), and pass these dimensions into the model generator function.

We need to ignore cloaked units.