UAlberta Bug List - Hegberg/Picayune_Porter GitHub Wiki

Witnessed Bugs in UAlbertaBot (UAB)

What follows is a list of bugs and potentially intentional but sub-optimal AI behaviours noted while working with UAlbertaBot. It is our hope that these critiques can serve as potential points of improvement for future versions of the bot, or as suggestions for new groups to tackle in subsequent terms of the course. It is understood that it may not be beneficial to implement all the changes suggested. While we realize that a number of very talented individuals are building their academic careers upon this bot, open-mindedness and internal documentation of bugs can only serve to advance the careers of UAlbertaBot’s creators. Such a document would also serve to help future students of the course, when trying to debug their own extensions of UAlbertaBot.

All of the bugs / concerns listed below were witnessed in-game with Brood Wars 1.16.1, and UAB was built using the most recent commit of UAB code to GitHub (as of 11/08/2016).


Crashes

  • UAB will cause an infinite non-responsive state from Starcraft when started on certain vanilla maps.

Causes of Stalls

  • Every so often the AI queues more building add-ons than actual buildings which can fit that add on, causing a lock up.
  • When mineral cluster 1 is near exhaustion, UAB creates a number of new workers. One of these workers establishes a new Command Center. The remaining workers remain idle until the new CC is complete.
  • These workers should either boost construction speed of the new Command Center (by being assigned to the incomplete building) or gather resources.
  • When mineral cluster 1 is exhausted, workers who were harvesting minerals are left idle, not reassigned to the new CC near the new mineral cluster 2, nor to local gas refineries.
  • When mineral clusters 1 and 2 are exhausted, all Workers are left idle.
  • This bug does not happen in every game, and is difficult to reproduce

Combat AI

  • Offensive units individually charge an enemy base instead of grouping, which is very costly to their combat effectiveness.
  • It is understood that individual units are useful for harassing enemy workers, but groups of 2 - 4 would do more damage at minimal loss in output speed.
  • When outnumbered and when no backup is available, ranged units will flee. Enemy units give chase. The result of this is that an opposing force gets drawn all the way to UAB’s base. This frees enemy AI from finding UAB’s base first, which gives them a substantial time advantage.
  • Would it be better to draw enemy units as far away from UAB’s base as possible?

Build Logic

  • If a worker dies while a building is under construction, a new one is never assigned.
  • Bunkers and other defensive buildings are not built near base entrances, but placed as any other building.
  • SCVs with undeposited minerals are used for scouting and building without depositing the minerals first.
  • SCVs lost to an enemy attack are not replenished.
  • Build order seems to look only three nodes ahead. For example, say UAB has a ready barracks and minerals. In it’s build order is [...“SCV”, “SCV”, “SCV”, “SCV”, “Marine”...]. The Marine will not be built until after the first SCV is built.
  • Build Oder eventually stalls on building a Machine shop, nothing gets built as a result of the machine shop never getting built

Build Order

  • Adding the queue of goliaths and buildings onto the end of the build queue each time it empties causes large amounts of lag until the new queue is created first instance is at 8 min 48 secs if build order not interrupted *At 20 something minutes machine shop isn't built, stops all production *At 5 40 to 6 mins game lags out do to build order refill *At 7 50 error for BOSSmanger that clears queued buildings and units

Research Logic

  • Witnessed cases where a research goal was added to goals, completed, and then the research goal was added to the goal list a second time.
  • UAB will not pursue multiple research tasks at the same time. For example, the Flash build we are looking at uses two Armories instead of one to double the number of parallel research upgrades. UAB only pursues one research upgrade at a time, regardless of availability of parallel openings.