kelly-cs / fusion-core

Optimizes build order timings for StarCraft 2

Fusion Core

What is Fusion Core?

This is a WIP application meant to optimize an SC2 build order. By supplying a target unit composition, Fusion Core will find the fastest possible solution.

Goals with this project

The goal of this project will be to make getting into Starcraft 2 easier. The minutiae of every little thing to do within the first 2-3 minutes of the game can have extremely detrimental effects on your gameplay, and figuring out optimal solutions is beyond what most players are interested in accomplishing.

While you can look up whatever the current, popular build order is on Spawning Tool, this takes the fun of trying your own ideas out of the game. Fusion Core aims to enable creative, strategy-driven builds without having to lose 500 times in order to figure out how to remove inefficiencies.

Methods

We will be loosely emulating the game environment using data collected on all important variables (such as worker count, saturation, tech tree, and abilities).

There are a couple ways this can be approached.

1) Brute Force

At every game tick, we can attempt all possible game actions by asking the GameState object. While this won't explore EVERY possible permutation because of in-game limits, it will likely be taxing on performance. The goal will be to approach the target unit composition as fast as possible.

2) Income Focus

At every game tick, we can attempt all possible actions that accomplish the target unit composition, while not letting the production of workers stop until a certain amount. This will decrease the range of possibilities to test.

3) Target Focus

At every game tick, if we do not have a current target, we will branch out and attempt all possible actions. If we have an action to do, we try to complete it. Otherwise we wait until we're able to. This should get rid of a lot of the random useless stuff in the Brute Force method, while still preserving the ability to wait (i.e., to wait for production buildings to complete in order to produce army units instead of just making workers instead)

fusion-core's Issues

Add Ability Logic

Abilities like Zerg's "Inject Larvae", terran's "Drop MULE" and Protoss' "Chronoboost" need to be implemented, and have unit tests made for them.

In addition to this, a special ability should be made to handle terran buildings swapping addons later. This will likely be considered a "unit morph", though.

Fix Geyser Timers

An anomaly is taking place that is causing remaining construction time of geysers to be far too low in the second half of results of the simulation. In addition to that, their "being_constructed" flag is set to true before they are built. It seems as if the variables are getting messed with before that branch is simulated.

replace camelCase with this_kind_of_notation

mostly in base.py, my fault

Add Paring Tree Logic

We need tree branches in the simulation to stop automatically when they exceed the speed of an already completed simulation. This can be represented by a global variable which is already set on this branch, in SETTINGS. However, we can't test this until production logic is set up to begin with (and tested) so build orders can be properly assessed.

Create Unit Testing

To accelerate QA, creating a generic unit testing system would be really handy. (Unfortunately, testing most of these things will take a very long time in the current state of simulation)

Merge Reorganized Gamestate w/ new changes in master

Convert all hard-coded timers into Unit classes for simplicity

I implemented some not-so-great timers for handling things such as:

• worker transferring between minerals/gas
• simulating worker travel time before building stuff/expanding

using lists containing timers. Instead, it may be worthwhile to convert these timers into Units directly, and handle timers internally. This appears to be working so far, so it's not quite as urgent as refactoring the Geysers which are broken.

Complete Logic for AttemptAction

Right now the simulation runs very slow due to impossible actions in AttemptAction. My hope is that when these are implemented, the amount of waiting/useless runtime will be cut down enough to have acceptable speed. We may need to make changes to optimize later on.

Add Worker Transfer Between Bases

Add Multithreading

We need to multithread the simulation function to increase throughput. Any optimization we can make is going to help out a ton.

Build Order List Incorrect

Currently the build order at any given tick seems to be incorrect.

At tick 0, if we set a target to building supply, there are outputs that show workers being built instead. All outputs are also identical (so, regardless of target, the output will always reflect something else). I suspect this is something to do with the way I'm passing data around - we may be recursing on referenced data instead of making copies as desired. (Of course, that's not the pythonic way of putting it.)

I utilize the fact that running a function on a passed in parameter like an output list operates directly on the output list already. So, what may be happening, is that passing self.buildOrder around during recursion and eventually doing the .append on it may always be targeting the same thing - the parent.

I'm not sure how to handle this just yet. It could be something else, but I've been trying to find a way to verify that is in fact the problem. Trying to make copies of self.buildOrder into local variables doesn't appear to help, so it could be something else..

Reorganize gamestate.py

Currently gamestate.py is very messy fix.

Finish JSON Config

This one is easy, but tedious as it generally has to be done by hand. Once it is complete, this should be a pretty useful resource even beyond this tool. If you want to complete this partially-done config, simply refer to Liquipedia for the stats, specifically for Legacy of the Void. We can get fancy with HotS too at a later point, or if you're feeling really motivated, you can go ahead and add it yourself.

The only requirement is to stay generally within the current format - that is to say, I need to be able to reference any given object by ["unitname"]["attribute"]. If you decide to work on a different expansion for me, I would also be okay with the format ["expansion"]["unitname"]["attribute"]. You'll get a lot of cookies if you do. c:

Refactor Base.py

Base.py is considerably out of form with the rest of the app right now, and has mixed responsibilities.

Base represents the main townhall building for each race, the hatchery, command center, or nexus. In addition to that, it also retains a record of how many workers it has, calculates income, and handles some logic regarding moving workers around.

The way that geysers are implemented should be redone, and we should try to simplify this file as much as possible to make it more readable.

Add Sequential Build Order Optimization

To give our app the best chance of running quickly to start, we will consider this option of build order optimization first.

That is to say, we will optimize orders in the order that the target unit composition was provided.
Example:
GOAL: [ "marine", "marine", "marauder"]

This BO optimization method will prioritize the fastest way to create the first unit in the list at any given time.

We will add more intricate versions after this one for greater customization.

Resources Not Being Spent

Despite logic existing to deduct resources when making workers, it appears that's not happening. Additionally, it seems like income is not being affected down the line either.

I am wondering if this is due to how data is being handled in this class, especially when doing the recursion. We're taking 50 minerals from self.minerals, which doesn't seem to make much sense. This issue may be somewhat related to the other issue with build orders at this time.

Correction. It appears to be being spent at exactly the tick that it is initiated, but all subsequent ticks revert to the previous mineral amount.

https://imgur.com/a/bBx1mhO

Handle Morphed Unit Logic

We need to implement a system that deals with morphed units, such as banelings. Right now the required tech tree is calculated solely based on what buildings/techs are required for a unit. in the units.ini config, we added a "requires" for zerglings in the Banelings entry, but no logic exists to handle this. We will likely have to make some kind of class for units that takes this into account?

Add Production Handling

Currently there is no system to handle the production of units or structures. However, a system has been created to handle the adding/removal of workers from the mineral line in order to build structures.

This could be done with some kind of class, but the biggest issue is going to come from Terran and Protoss production. We will need to account for producing units through different buildings, and factor in the quantity of such buildings. It might be wise to just shove this off to a new class.

Protoss are going to need a way to interact with the Base class, since it has the Chrono boost ability. This ability will be vital for build orders, and it needs to be accessible to all buildings. Therefore, the Base class will likely need a permanent reference to some sort of list of production/tech facilities.

Zerg will be really easy - just subtracting larvae from the bases and adding the units to some sort of queue after confirming the required tech is achieved.

REVIEW POTENTIAL OFF BY 1 ERRORS

okay, I've been a little imprecise about how my timers, and ticking, have been applied. I think it is going to be functionally OK, but a super minor thing would be to review anywhere there's a + or - 1 for anomalies later on.

Introduce File and Stream Logging Into Repo

https://docs.python.org/3/howto/logging.html

Currently repo utilizes print to keep track of data during runs.

Logging is a more efficient cleaner solution.

Update and Create readme, gitignore and requirements.txt

Disable Targeting of Impossible Actions (Geyser)

In this state, the program is setting targets for impossible actions and adding additional, unnecessary runtime. Example being:
after being sent to build 2 geysers with no more possible to build, the program will still set it as a target despite never being able to do it again (until expanding).

Finish Mineral/Gas Transfer Logic

The logic for transferring workers between minerals and gas is incomplete. We need to finish it up and ensure that:

• construction time is accurate
• workers are distributed between them in the most efficient manner (always send workers to a geyser with 1 or 0 workers on it already, for maximum return, before sending it to one with 2 in it already.). Inversely, workers are always pulled away from the most saturated geyser before pulling from lesser saturated geysers to minimize the effect on gas income.
  1 worker = 60
  2 workers = 120
  3 workers = ~160
• workers cannot be sent to a geyser that is still under construction
• you cannot build additional geysers if all geysers are constructed, or are under construction. -- logic needed for this

This logic needs to be added to the appropriate functions.

Add Expanding Logic

The tool requires the expansion logic to be finished.

In order to expand, the required amount of minerals must exist (depending on race), the time to travel to the expansion must be factored in (this variable exists in the config already), and then a new Base object must be created with the "Underconstruction" bool set to True. This base will have to be appended to the list of Bases in the GameState object in order to be processed appropriately.

The base should only be accessible to making Workers or collecting income once it is done constructing. The timer for construction already exists in the Base class.

Change small lists [0,0] to Tuples

Minor code enhancement, changing random lists for functions like getIncomeThisTick from returning lists of len 2, to just tuples that are more readable.

Clean Up Code

Some (or a lot) of the code is pretty messy. In the interest of getting a solution as fast as possible, I've been a little messy about some things. If you find any code that is objectively ugly, please feel free to push any changes.