SCFusion - WoL, HotS & LotV Build Order Optimizer - Page 13

On November 17 2010 07:26 quillian wrote:
Awesome! I've been waiting for someone to make one for protoss. Is there any way to get it compiled for mac? if you haven't done it yourself I might be able to suggest a way, if the source is pure c++.

On November 17 2010 08:58 Aneon wrote:
What does the "Mutation Rate" variable do? Is there a point in increasing/decreasing it if we want more experimental builds? Or will it always reach the same end result?

On November 17 2010 10:27 lowlypawn wrote:
I really like how this program is evolving. Overall I still like Evolution Chamber's layout a little better and it has some features that should be implemented like:

* "Running for" and "Last updated" time

* I also prefer the output of EC and how you can view "simple", "detailed" and "copy to clipboard". I haven't used the YABOT feature but that sounds like a really useful feature.

Lastly I thought the program was too bright on the eyes so I decided to hack it and make the UI closer to my liking


+ Show Spoiler +

Uploaded with ImageShack.us
+ Show Spoiler +

On November 17 2010 11:28 CarbonTwelve wrote:


The mutation rate is something that affects the underlying GA. The way that works is that after it breeds new build orders, it goes through every single command and does a random roll to see if it should mutate it, and it does this for each mutation operator (insert, duplicate, delete, mutate, random swap, immediate swap, move). A higher mutation rate means that each command is more likely to mutate at each step.

The benefits of having a higher mutation rate is that it comes up with different builds a lot more quickly, so usually this helps out early on because it tests out things more regularly. However, when you get to much later evolutions it has already tested out most combinations and will likely only get benefits from small changes, in which case a lower mutation rate is probably better.

I'm playing around with the mutation rates and how they're used at the moment, so things might change with the next version.

On November 17 2010 13:13 PJA wrote:
It's pretty normal in algorithms to find maxima/minima of unknown functions to basically have a variable similar to your mutation rate decrease at some rate while you are doing the search. You've probably already thought of that, though.

Some other similar ideas could be gotten from algorithms such as: http://en.wikipedia.org/wiki/Simulated_annealing. Basically, you could take some build order, make random changes, see if it is faster. If faster, take that build order for the next step in the process and continue. If slower, take that build order for the next step with some probability that drops off as a function of how much slower it is. This way you won't get stuck at some local minimum when there could possibly be a much faster build order.

On November 16 2010 19:53 jabaes wrote:
Bugs

carriers have 120sec build time and
mothership has 180sec

chronoboosting them all throughout their build time will result to them being built at 80secs(carrier) and 120secs(mothership)

the program finishes the carrier and mothership at both 50secs.

On November 16 2010 19:57 Barook wrote:

Mothership build-time is actually 160 seconds.

On November 17 2010 15:02 Amui wrote:
One of the functions that I feel would be VERY useful is fastest way to get X while also being able to delay it until a stalker comes out. Otherwise any competent player will know exactly what is going on because it is impossible to kill workers with zealot's. Sure I can get 9 blink stalkers before 7 min, but it also tells me to do some things including throwing down a TC right after cyber core, while the scout is most likely still in my base. Especially with the way that protoss macro and warpgates work, throwing down 2 gates at the same time 10 seconds later is almost the same as throwing a gate up then another 10 seconds later, but if in those 10 seconds, you can chase the scout out, it is very very worth it. While a computer can do the 3 warpgates on 3 timers perfectly, it is better for a human to have 3 warpgates synced up simply be able to have one timer to count.

On November 17 2010 14:44 FurySparks wrote:
So I've been reading throughout this thread and Fitness is a term that appeared often. What exactly does fitness represent in this simulator? I'm under the impression that higher fitness is better, so how exactly would i go about altering builds to increase the fitness?

Also, this tool is really cool, thanks for sharing this with the community (:

On November 17 2010 14:45 30to1 wrote:
After getting pretty good at getting decent results out of it. The main weakness seems to be short term losses for longer term gains. Funny, because creationists use this argument against evolution all the time (annoying). For instance, I have a waypoint that contains 12 zealots / 6 stalker / 2 sentry and 4 warpgates. The warpgate conversion is very close to the end of the list, despite it chronoboosting out two zealots ~20 seconds earlier (note this is not researching warpgate - this is the actual conversion to warpgate).

I'm on game 823million and the longer term value of warpgate is just not being realized over the shorter term value of build unit.

This makes sense, all else being equal the its very hard without 'mutation' for it to stumble into the value, it needs to try replace a single unit build action, with a convert to warp gate AND a unit build action subsequently - if it is just a one step comparison, build unit will always be better.

Same problem I think in it determining how to build refineries. After something like 500,000,000 - it avoided taking a second refinery until very late, despite clearly failing because of lack of gas. It makes sense in the short term again i guess - since building the refinery alone may not count towards goal - you need a combination of three things to happen to move it closer to goal: build refinery, assign worker, build unit - then and only then may you eventually improve fitness.

I've looked over the code on this guy and evolution chamber - and I sort of think that a much more finite state approach may be better for this kind of problem rather than GA - almost exactly how most chess engines work.

What are your thoughts on taking a more 'absolute' approach and just brute forcing every possibility in a directed manner (throwing in some heuristics for quicker useful results)? The hardest part I can think of would be optimizing out 'transpositions' into identical state from different branches.

Maybe I'll write the terran version -- but I really hate friggin terran :D

*edit - if you think the GA approach would really yield better results - what are your thoughts on the strengths and weaknesses of your/EC's approach to fitness (I believe yours was almost identical to ECs - but I did a pretty loose read of the code for both - and I'm not that strong with either language).

On November 17 2010 15:02 Amui wrote:
One of the functions that I feel would be VERY useful is fastest way to get X while also being able to delay it until a stalker comes out. Otherwise any competent player will know exactly what is going on because it is impossible to kill workers with zealot's. Sure I can get 9 blink stalkers before 7 min, but it also tells me to do some things including throwing down a TC right after cyber core, while the scout is most likely still in my base. Especially with the way that protoss macro and warpgates work, throwing down 2 gates at the same time 10 seconds later is almost the same as throwing a gate up then another 10 seconds later, but if in those 10 seconds, you can chase the scout out, it is very very worth it. While a computer can do the 3 warpgates on 3 timers perfectly, it is better for a human to have 3 warpgates synced up simply be able to have one timer to count.

On November 17 2010 16:01 jabaes wrote:
ah right, but still 50sec is still off, i think it should be 106secs?

On November 17 2010 10:27 lowlypawn wrote:
But the SPEED of this over EC simply can't be beat. The difference between Java vs C++ is amazing.