Starcraft AI blog

Steamhammer inherits from UAlbertaBot the use of waypoint navigation in 2 narrow cases, for moving the scouting worker around the edge of the enemy base, and for moving the transport around the edge of the map when dropping. The 2 implementations are completely separate.

Today I am fixing yesterday’s bug related to drop. Following my minimum energy trajectory, I naturally clean up any code that I work on. The drop navigation turns out to be extravagantly overcomplex; I imagine it was copy-pasted from the scout navigation with minimal changes, even though following the map edge is a far easier problem. In cleaning it up, while keeping the same general plan I am eliminating 1 persistent data structure (dropping _waypoints and keeping _mapEdgeVertices which I will rename to _waypoints) and 2 temporary data structures used unnecessarily to find the edge of the map. You seriously don’t need complex calculations to lay waypoints around the edge of the map. I decided to keep the overall waypoint plan because it provides flexibility for future uses, even though the flexibility isn’t needed now.

Back when I first worked on drop, I treated this code as a black box and touched it as little as possible while marveling at its opacity. Now it is becoming much shorter (and incidentally faster), and getting commented so it will be understandable. I also intend to decide accurately which direction to take around the edge. Steamhammer too often takes the long way around.

Waypoints seem like a good navigation tool whenever you want to plan movement several steps in advance. If you figure out a safe path to get an overlord to a good observation post, or to route vultures around the sunken to reach the mineral line from the far side, then you can represent the path as a sequence of waypoints. Executing the plan seems easy. I guess if you’ve moving a substantial ground army, you probably don’t want to send all units to a single point, but I can see ways to work with that (either plan ahead with “way zones” or react on the fly to keep to safe locations within some tolerance). Of course the plan may run into difficulties so that you have to replan, but that is always true.

If you sometimes plan only one step ahead, then you don’t need waypoints—but you can still use them. Waypoints seem like a general purpose representation of paths from A to B.

I’ve noticed the duplicated waypoint code before, between scouting and dropping, and thought of factoring it out into a waypoint class for wider use. I may do that. It would be part of the solution to the other and bigger bug, getting stuck on map obstacles.

Do people have opinions?