|
Hi all,
Sorry for the lack of updates, but work has been progressing. I've just submitted a new version with support for waypoints, buildings, and the warpgate research. I've also made quite a few other various tweaks and adjustments to various parts of the algorithm, I think part of which means it will be more likely to take warpgate research of its own accord.
There was a crash that a few people noticed and PM'd me about (thanks for that!) and I think I've fixed it now, so if you notice any more crashes please let me know.
Next on the agenda will be to implement the rest of the upgrades.
Please keep the feedback coming, and hopefully the future updates can happen a bit more regularly.
- Carbon
Edit: Figured I should probably provide a link to the download page 
http://code.google.com/p/scbuildorder/downloads/list
|
Nice, cant wait to try it out when I get home!
|
Nice upgrades! Keep up the good work.
Support for upgrades would be nice. The current build lacks a Forge and cannons.
Could a priority system be integrated? I.e. that certain buildings/units/upgrades have priority over others. E.g. you want to throw down a early cannon for defense while teching.
|
On November 13 2010 20:22 Barook wrote:
Could a priority system be integrated? I.e. that certain buildings/units/upgrades have priority over others. E.g. you want to throw down a early cannon for defense while teching.
You can do that with waypoints. After I've put cannons in (just an oversight) you could have Waypoint 1 as 1 cannon by 300s, then have the Target as what you actually want to get.
|
Great work ! V2 seems to work smooth.
Suggestions :
- Display of the result seem to be refreshed on every evolution even though the current result is still the best one
- Maybe it would be useful to display when was the last time a better result was found ?
- (already discussed) being able current economy rate indeed would be a major improvement
i just try a simple thing :
* 2 DT's + warp gate VS 2DTs + warp gate + 20 probes and with a 6 second difference turns out you can have your 4 probes
|
Thanks a lot, I am closely following the progress of this tool and can't believe you already made an update As I recently switched to protoss, it helps.
Keep up the good work.
|
On November 13 2010 20:30 Tekelve wrote:
- Display of the result seem to be refreshed on every evolution even though the current result is still the best one
Atm it's updated with a timer that runs once a second. I'll make a change for the next version so that it only updates the display if it actually changes.
- Maybe it would be useful to display when was the last time a better result was found ?
Yep, that's fairly easy to do - would combine it with the above change.
- (already discussed) being able current economy rate indeed would be a major improvement
i just try a simple thing :
* 2 DT's + warp gate VS 2DTs + warp gate + 20 probes and with a 6 second difference turns out you can have your 4 probes
Yeah, I've noticed similar things, even to huge differences where you can double your probes for only 5s longer. Unfortunately it's not easy to describe how much of a trade off you want to make - is it worth it for 5s? How about 10s? 20s? I'm continually tweaking the fitness calculator though, and I think my original version actually did this a lot better, although the new one handles waypoints in a decent way, so I'll have to work on a combination of the two. Also I need to work out how to force it to consider building more probes - if you request just 5 stalkers atm it'll give you a BO within ~5:15, but if you tell it to get 16 probes too it brings it down to ~4:45. Plenty more to do, just gonna take time
|
|
|
Damn 
Just running it myself, looks like there's a memory leak - memory usage is just climbing... Will try to fix this one tonight.
|
This thing is amazing, I wish they had one for Starcraft 1, hats off to you.
|
On November 13 2010 20:39 CarbonTwelve wrote:Yeah, I've noticed similar things, even to huge differences where you can double your probes for only 5s longer. Unfortunately it's not easy to describe how much of a trade off you want to make - is it worth it for 5s? How about 10s? 20s? I'm continually tweaking the fitness calculator though, and I think my original version actually did this a lot better, although the new one handles waypoints in a decent way, so I'll have to work on a combination of the two. Also I need to work out how to force it to consider building more probes - if you request just 5 stalkers atm it'll give you a BO within ~5:15, but if you tell it to get 16 probes too it brings it down to ~4:45. Plenty more to do, just gonna take time
Would it be possible for the program to note that a slight variation in build for more of X is possible, and suggest it as an alternative? So if it notices that you can get many more probes for 5 more seconds, it offers it as a point of comparison and option to optimize for that instead?
Or perhaps instead, what about an option of "always build probes", or "always build probes until X probes reached"? That should be pretty easy to implement I would think, and would emulate the way a standard, non-all-in build would want to play to begin with. Setting an arbitrary probe count number by an arbitrary time count number sort of emulates this methodology, but I think a simple option for this sort of production would be much more intuitive.
Suggestions aside, I really like the improvements you made in version 2 - its much more intuitive and has a much cleaner output. Great work so far!
|
Thanks for the update, keep up the good work.
For some reason though, it sometimes tells me to get 3 Assimilators off 1 Nexus.
EDIT: Oh, and an option for constant probe production would be really nice too
|
Ok, looks like the latest crash isn't a memory leak as such, just that because of a combination of the fitness function changes and adding a duplication mutator it means the chromosomes just keep growing and growing (especially after it's already settled on an optimal build). I'll have to adjust the fitness function again. New release shortly......
Edit: Ok, done, v2.1 released: http://code.google.com/p/scbuildorder/downloads/list
|
On November 13 2010 08:01 CarbonTwelve wrote:Show nested quote +On November 13 2010 01:58 Morfildur wrote:
I wonder if i could code this in C# myself and how fast it would be (definatly faster than java from my experience with both languages), time to read into the theory. Obviously you're welcome to try, and it's always good having someone redesign something as you might find reasons for doing things in a different way that I can then incorporate into my code. Honestly though, I doubt you'll get anywhere near the speed that my app achieves, basically because of the lack of control over memory allocations in C# and garbage collection just getting in the way.
Thats an argument i hear from all C/C++ programmers, but as a long time C programmer i can say that the difference is actually far smaller for C# than someone might expect (i was always bringing this argument, too, until i tested it myself after getting enough C# experience to get good benchmarks). I think that rumor exists mostly because of Javas poor implementation of memory management.
Ofc .NET still has portability issues, but well, which SC2 player plays it with wine on Linux/BSD anyways?
Anyways, very good work so far, i really appreciate this program.
Any news on a terran version? As a random player i need new builds for all races
|
On November 13 2010 21:39 Morfildur wrote:
Thats an argument i hear from all C/C++ programmers, but as a long time C programmer i can say that the difference is actually far smaller for C# than someone might expect (i was always bringing this argument, too, until i tested it myself after getting enough C# experience to get good benchmarks). I think that rumor exists mostly because of Javas poor implementation of memory management.
Well, I'm speaking from my personal experience of implementing solvers (A*, depth searches, etc.) in C#, but again, I'd be happy to be proven wrong
I guess there isn't as much dynamic allocation in this system, so with some tricky object management & pooling you might be able to get away with it, but given the build orders are dynamic I still don't think you'll get close to the speed of C++. I'd expect somewhere half way between my app and Lomilar's.
Any news on a terran version? As a random player i need new builds for all races
Terran will probably be a little ways down the track. I need to get the basic Protoss features all completed and make sure everything is stable, then probably get the GUI sorted out a bit more and do the Zerg GUI (given the algorithm is done for Zerg), and then I can start working on Terran.
|
On November 13 2010 21:35 CarbonTwelve wrote:Ok, looks like the latest crash isn't a memory leak as such, just that because of a combination of the fitness function changes and adding a duplication mutator it means the chromosomes just keep growing and growing (especially after it's already settled on an optimal build). I'll have to adjust the fitness function again. New release shortly...... Edit: Ok, done, v2.1 released: http://code.google.com/p/scbuildorder/downloads/list
Thanks, that was fast. Could you keep all versions available?
|
On November 13 2010 21:59 Dionyseus wrote:
Thanks, that was fast. Could you keep all versions available?
They're all there, just I marked the older ones as deprecated. If you want to see them still you can by going to downloads, changing the search combo from 'Current downloads' to 'All downloads', then hit search.
|
On November 13 2010 22:01 CarbonTwelve wrote:Show nested quote +On November 13 2010 21:59 Dionyseus wrote:
Thanks, that was fast. Could you keep all versions available? They're all there, just I marked the older ones as deprecated. If you want to see them still you can by going to downloads, changing the search combo from 'Current downloads' to 'All downloads', then hit search.
Thanks.
Noticed a possible issue in the newest release. The default time for the target tab is 1500, but in settings it's at 1200, dunno if that would cause a problem.
btw the gui is looking so much better now than in the first version, nice job
|
On November 13 2010 20:58 MalVortex wrote:Show nested quote +On November 13 2010 20:39 CarbonTwelve wrote:Yeah, I've noticed similar things, even to huge differences where you can double your probes for only 5s longer. Unfortunately it's not easy to describe how much of a trade off you want to make - is it worth it for 5s? How about 10s? 20s? I'm continually tweaking the fitness calculator though, and I think my original version actually did this a lot better, although the new one handles waypoints in a decent way, so I'll have to work on a combination of the two. Also I need to work out how to force it to consider building more probes - if you request just 5 stalkers atm it'll give you a BO within ~5:15, but if you tell it to get 16 probes too it brings it down to ~4:45. Plenty more to do, just gonna take time Would it be possible for the program to note that a slight variation in build for more of X is possible, and suggest it as an alternative? So if it notices that you can get many more probes for 5 more seconds, it offers it as a point of comparison and option to optimize for that instead? Or perhaps instead, what about an option of "always build probes", or "always build probes until X probes reached"? That should be pretty easy to implement I would think, and would emulate the way a standard, non-all-in build would want to play to begin with. Setting an arbitrary probe count number by an arbitrary time count number sort of emulates this methodology, but I think a simple option for this sort of production would be much more intuitive.
I guess the simple way is to create several objectives with resources focus that would maybe lead to interesting results like :
- reach mineral (and/or gas) saturation on X bases
- like MalVortex said constantly build probes until X (n° of probes reached, expand happens, ...)
Then i don't know if it is easy to include in the score (my AI classes are quite old !) but you could include a custom weight on "main objectives" to help get your main goal (basically time or ecom).
For example :
- 1st waypoint 1 stalker / 1 sentry with 75% weight on econ
- 2nd waypoint 2 zealots/2 stalkers/1 obs/1immortal with 25% weight on econ
The other aspect and obviously a lot harder is finding build on standard settings with very similar result on one aspect (time) but better result on another (econ).
Here are some thoughts about that :
- a manual way : keep a top 10 results list and extract indicators based the best build (delta in econ wealth / time) so that a human can choose based on is knowledge
- a 2nd pass algorithm that would take the top X results from genetics and sort/compare them to determine which is the best regarding those slight difference.
Then on how to determine which trade off is good or not :
* maybe you can first calculate your own weight for time and econ : for example having a 30s time difference in a 4min build if far more important than in a 10min build
* another would be to do a simulation on how the game evolve from there : since your second pass is on a smaller result set you could run a heavier simulation
For example : from you result set you can determine if a build has a better economy than the best result
- If that's the case see how long it would take to have the same economy for the best build versus this one. Then with the first delta found and that new calculation on many "good builds" i guess you can find which one is the better trade off.
- With that you can also give a 3 result set : best time / best econ / best average.
- If the second has lesser economy we can discard it obviously
|
On November 13 2010 22:03 Dionyseus wrote:
Noticed a possible issue in the newest release. The default time for the target tab is 1500, but in settings it's at 1200, dunno if that would cause a problem.
Nah, doesn't cause an issue. I should probably explain the differences. The limit in the settings is a hard limit - it'll just stop processing games once it gets to that time, however, if there is a waypoint time set higher then the settings limit will be extended internally. The time limits set on the waypoints act like soft limits - it'll try and get the build order under that time, but if it doesn't it'll keep processing the game until it achieves the current waypoint. This way it'll at least find a solution so that later evolutions can improve it to get it under the time limit.
btw the gui is looking so much better now than in the first version, nice job
Thanks
|
|
|
|
|
|
EPT
