Zerg Build Order optimizer. - Page 56

On December 17 2010 00:45 falstag wrote:
When are the toss and terran versions coming out, you claim they are now in the advance stages, any ETA?

On April 15 2011 23:42 Reithan wrote:
I'm not a professional programmer on this level, but I am an amateur one, and I program things for ecommerce and some web applications professional (not not, but I have). Why would using a genetic algorithm like this be better than something akin to a A-Star like pathfinding algorithm, treating each build option as a 'path' to a certain goal state?

On April 18 2011 18:50 kmh wrote:


A* is not an algorithm suitable for these kinds of optimization problems, at all. The goal here is to find the build that satisfies the requirements in the shortest time possible, without any knowledge of what the landscape might look like. In path-finding, you know the entire graph describing your territory before you set off to find the shortest path. It is not even remotely the same thing.

On April 19 2011 02:47 Reithan wrote:
Alright, then the continuation of that question would be, given that you CAN solve this as a pathing problem, if A* is not suitable because it's not efficient enough, what algorithms would be?

Genetic Algorithms seem like a fairly inelegant and brute-force approach to this problem.

On April 19 2011 03:05 Bumblebees wrote:
If you simply wanted to know the fastest way to get X, a simple DFS should be able to do any build in a matter of seconds on even a mediocre machine. Nothing more complicated is really needed. All you need to do is generate the absolute necessary building and worker count then traverse the tree to find shortcuts (very simply, cut or add workers). This was discussed and tested (i.e. programmed incompletely) in the EC chat on IRC many months ago. Someone had a program that did just zerglings (queens, drones and overlords) which could find the fastest route to X zerglings in less than a few milliseconds

Honestly, build order optimizers are fairly useless when it comes down to actual gameplay. The motivation to pursue this stuff is really minimal even among those who you may consider interested in it.

On April 07 2011 09:28 trumansc wrote:
I don't know if anyone else has brought this up but I've been messing around with this program, it's amazing by the way keep up the good work, however there is one slight problem where the program is unable to take into account the whole "feel" of economy and timing. I realise this is just one of the drawbacks of the genetic algorithm but I believe the simplest way to fix this would be to allow the input of some arbitrary waypoint independent of the program that could be a forced starting point. For example often the program makes a 10 overlord, I know for a fact that 9 overlord is the best economy opener as has been detailed on this forum before, also often the program makes both a 9 and 10 overlord because presumably there are spare minerals. If you could force the program to start with say a 9 overlord, 13 pool and then let it take over from there I think people could use the program with alot more finesse that may save time instead of brute forcing through another 1 million games. I do not know either the complications of the math or the programming but if this feature could be added I think the program would work a bit better, also a mineral gas and larva setting would be great. thank you

On April 24 2011 11:34 FrostedMiniWeet wrote:
9 Overlord is only better than 10 overlord if you put down your pool or hatch after 13 or so. If you go 9 overlord and then do an early pool at or less than 12, then 10 overlord would have been better. I won't explain why this is at it is clear to anybody with basic understanding of mathematics.