Open GoogleCodeExporter opened 9 years ago
Time is mainly to speed up computation, since it always simulates to the end.
If final time is set to 120:0 I'll get about 1400 games / second, even if build
completed in say 6 minutes, but if i then decrease final deadline to 7:0 i'll
get over 4000 games / sec. Dynamic deadline could do the trick, like if the
build takes only 6 minutes it would decrease deadline time to speed up
iterations, and if the build is impossible on set deadline it could notify user
and increase deadline, until it can do it.
Original comment by Jussi.Pa...@gmail.com
on 24 Oct 2010 at 12:29
[deleted comment]
The only time the program should say that a build is impossible is when you
add the building times of all the things that are needed. In this example this
would be Spawning Pool(65s)+Lair(80s)+Infestation Pit(50s)+Hive(100s)+Greater
Spire(100s)+Broodlord(34s) = 429 seconds = 7min 9seconds. (Spire and Corrupters
can be built during Infestation Pit, Hive and Greater Spire). This would make
the build possibly if you had enough resources. But since the program tries to
find out if it can get enough resources, it can't just say that its not
possible.
You as a person can clearly see that 20 broodlords in 10 mins can't work. But
the program only knows that if it tries out all possible builds.
So the only thing that should be said to be impossible is 20 Broodlords in
under 7minutes 9seconds.
Original comment by azzur...@gmail.com
on 24 Oct 2010 at 1:18
The solution proposed by Jussi sounds reasonable. Since program always tries to
get best possible time there is no point of setting it explicitly in GUI. The
deadline should be managed internally since it is relevant only for performance
optimization.
Original comment by sergey...@gmail.com
on 24 Oct 2010 at 8:23
[deleted comment]
But it would still need an initial deadline, otherwise the speed at the start
would be slow. Even if there was a dynamic deadline, there should still also be
an option to specify.
Original comment by atb...@gmail.com
on 26 Oct 2010 at 1:05
I'm not sure I agree. Getting rid of the initial deadline seems like a good
step to cleaning up the UI. It's always good to simplify where possible.
I'm sure someone can craft an algorithm given the unit constraints to get a
fairly intelligent initial guess. After it finds a satisfactory build simply
adjust the time down to that. If it doesn't find a build in f(x) seconds then
you can adjust the time upward.
Doesn't sound too difficult actually.
Original comment by brad.han...@gmail.com
on 26 Oct 2010 at 4:02
Even if it is grossly inappropriate, varying the final deadline would be useful.
Not sure of the heuristic to do this. But it'd be nice for making performance
more better.
Original comment by Frit...@gmail.com
on 6 Nov 2010 at 1:05
We could have a user-specified level of effort before it starts to lengthen the
time deadline, but setting this whole idea up is a bit complicated.
In the meantime, I would recommend setting a much higher time limit than normal
for all way points. This slows simulation speed, but often leads to more
efficient searches. This results because it is much easier, from the program's
standpoint, to shorten a satisfactory build than to move from an unsatisfactory
build to a satisfactory one.
Original comment by qwerty10...@gmail.com
on 7 Nov 2010 at 10:41
Original issue reported on code.google.com by
sergey...@gmail.com
on 23 Oct 2010 at 11:21