search

mannyzhou5 / evolutionchamber

Automatically exported from code.google.com/p/evolutionchamber
0 stars 0 forks source link

Vary deadline based on actual build #58

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. Run the program with goal of 20 broodlords in 10 mins

What is the expected output? 
An error that the goal is unreachable due to time constrains.

What do you see instead?
Unreachable goal Spire

What version of the product are you using? On what operating system?
0015

Please provide any additional information below.
The possible solution can be to remove option to set the time goal

Original issue reported on code.google.com by sergey...@gmail.com on 23 Oct 2010 at 11:21

GoogleCodeExporter commented 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

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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