BL2 Bot Player

Discuss about Blockout II from Jean-Luc, post your feature requests etc.
jlp_38
Posts: 264
Joined: Tue Jun 26, 2007 9:09 am

Re:BL2 Bot Player

Post by jlp_38 »

The eval on sf gives in 3x3x18 BASIC: (100000 runs)

delta
depth proba
-2 => 0.0418949
-1 => 0.244233
0 => 0.399776
1 => 0.300517
2 => 0.0133477
3 => 0.000231464 (3 lines)

(If i well understood?)
Lieven
Posts: 55
Joined: Sun Aug 05, 2007 6:31 am

Re:BL2 Bot Player

Post by Lieven »

I am sorry, I probably wasn\'t clear enough.

What I really want would to be these probabilities, but than as a function of depth. (so as a table) So for instance, at freedepth=4: what are the probabilities that the next move freedepth is >2, is =2 or is <2.

So per depth, 3 probabilities.

The values you list, if I understand correctly, are integrated over all depths. But what I am interested in, is if these probabilities are depth dependent. They surely are not in the beginning, but perhaps when D>=3 they are. Which would be great news. I expect the table to look something like:

D P0 P1 P2
0 | 0 0.5 0.5
1 | 0.3 0.3 0.4
2 | 0.3 0.3 0.4
3 | 0.3 0.3 0.4
4 | 0.3 0.3 0.4
5 | 0.3 0.3 0.4
6 | 0.3 0.3 0.4
7
8
...

ofcourse the values will be different, but it is my hope that for instance row 5 and 6 are approx equal. (in which case we can speed up the calculation of the average drastically)
jlp_38
Posts: 264
Joined: Tue Jun 26, 2007 9:09 am

Re:BL2 Bot Player

Post by jlp_38 »

OK, I\'m still not really sure ???
Does this values seems correct ?

Code: Select all

        +1        0         -1
 0 => 0.997972 0.0020284(flush) 0
 1 => 0.70599  0.290383         0.00362643
 2 => 0.245376 0.482922         0.271702
 3 => 0.143269 0.345767         0.510964
 4 => 0.117185 0.343548         0.539267
 5 => 0.132959 0.355181         0.51186
 6 => 0.10041  0.372951         0.526639
 7 => 0.111111 0.333333         0.555556
 8 => 0.047619 0.380952         0.571429
 9 => 0        0                1
<br><br>Post edited by: jlp_38, at: 2008/02/16 23:28
Lieven
Posts: 55
Joined: Sun Aug 05, 2007 6:31 am

Re:BL2 Bot Player

Post by Lieven »

Yes that looks almost good (I think). However, the first line puzzles me a bit

0 => 0.997972 0.0020284(flush) 0

(I was also wrong in my previous post) With an empty pit, the only thing that can happen is that freedepth decreases so

Code: Select all

      +  0  -
 0 => 1  0  0 
With a pit that has only \"blue\" blocks, we should have something like

Code: Select all

      +     0          - 
 1 => 0.499  0.499  0.02   (flush)
if am not mistaken.

Also, are you sure about the columns? I would naturally think that the \"0\" column gives the highest probability, but perhaps I am mistaken.

That said, this looks very good:

4 => 0.117185 0.343548 0.539267
5 => 0.132959 0.355181 0.51186
6 => 0.10041 0.372951 0.526639
7 => 0.111111 0.333333 0.555556

Over how many runs was that? The error is larger for higher D, but after enough runs, they should all approx equal out. In which case we could very accurately estimate the 3x3x18 average cubes based on the 3x3x8.<br><br>Post edited by: Lieven, at: 2008/02/16 23:52
jlp_38
Posts: 264
Joined: Tue Jun 26, 2007 9:09 am

Re:BL2 Bot Player

Post by jlp_38 »

OK, still not sure ???

Result on: 250000 Blocks

Code: Select all

         -1          0       +1
 0 => 0            0       1
 1 => 0.015544(F1) 0.29102 0.69344
 2 => 0.30593      0.48459 0.20948
 3 => 0.53528      0.35007 0.11464
 4 => 0.55347      0.33784 0.10869
 5 => 0.53897      0.3546  0.10643
 6 => 0.50594      0.35799 0.13607
 7 => 0.49448      0.37569 0.12983
 8 => 0.43846      0.42308 0.13846
 9 => 0.6          0.28571 0.11429
10 => 0.63636      0.36364 0
Lieven
Posts: 55
Joined: Sun Aug 05, 2007 6:31 am

Re:BL2 Bot Player

Post by Lieven »

Thanks a lot, this looks great!

1 => 0.015544(F1) 0.29102 0.69344
2 => 0.30593 0.48459 0.20948
3 => 0.53528 0.35007 0.11464

Basically, I think the three first lines are enough, and the remaining lines are equal to the third (theoretically).
One comment: In your table, the 9th and 10th row should have higher + factors (if the game ends, that is a +)

I ran a simulation based uniquely on these parameters, but couldn\'t quite get the average cube count correct. Perhaps the table has to be expanded with +2 and -2; but shouldn\'t make a big difference. I try again tomorrow.

But if that works (it really should) and if these first three lines converge quickly, say after 100 runs, then such a simulation might be a real time saver. (at least in indicating whether a certain evaluation is better/worse than another). Come to think of it, the + value alone would be enough to indicate how good a certain evaluation is. So all depends on how fast the third line converges!

Hopefully, I am explaining this properly. If not please tell me.


Lieven
jlp_38
Posts: 264
Joined: Tue Jun 26, 2007 9:09 am

Re:BL2 Bot Player

Post by jlp_38 »

One comment: In your table, the 9th and 10th row should have higher + factors (if the game ends, that is a +)


I ran the simu in 3x3x18 in only 1 game so no game ending.

Thanks again ;)
Really hope that the values will converge quickly.

What about the error on these values ?
For instance i see that the +1 column seems to converge
to ~0.11 but after 250000 block, it seems to still have
an error of ~0.01...
jlp_38
Posts: 264
Joined: Tue Jun 26, 2007 9:09 am

Re:BL2 Bot Player

Post by jlp_38 »

I was thinking to something. I think your suggestion to
use this limit for qualifying an evaluation is cool :)
I think if infinite play is possible (in FLAT may be ??)
this value should reach 0 ? Am i wrong.
So we can use this as a quality factor :

0% (for lim=1)-> Wrooooooong :s_nerv:
100% (for lim=0)-> Perfect :s_easy:

I\'m tired, going to sleep...

Image<br><br>Post edited by: jlp_38, at: 2008/02/17 02:40
Lieven
Posts: 55
Joined: Sun Aug 05, 2007 6:31 am

Re:BL2 Bot Player

Post by Lieven »

Thanks for all the info. I am a bit surprised about the small convergence. Just for fun, if you have time could you run it again on a larger number, say 2.500.000 blocks? I am just curious to see the results.

Perhaps this method tries to extract too much detailed information from one run. A similar idea, but perhaps with quicker convergence is counting the average time spend on depth=3 or 4. Say one evaluation run spends 1/100 of the time on depth 4, but another spends 1/110 on depth 4, then the second evaluation is clearly better. (is less prone to climbing up, or can resolve holes quicker). It would be great if we can devise a test which accurately establishes whether one evaluation is better than another in say 1 min.

Here is an idea for the parameter scanning (I used something similar recently for my work and it worked quite well).

Say you have an array of 5 parameters par[5]. Chose the parameters all 1. Define a multiplier=10.

Then a for loop over all the parameters. First multiply the first parameter by 10. If it is better, keep this parameter, if not keep the original. Then divide the first parameter by 10, and keep if better. Then move on to the next parameter, first multiplying and comparing, then dividing and comparing, then move on to the next parameter etc.. At the end of the for loop, look if any of the parameters changed. If yes, redo the whole loop. At the end of this process, the parameters are accurate upto a factor 10. Then change multiplier=sqrt(multiplier)=3.16 and repeat. At the end of the loop you put again multiplier=sqrt(multiplier)=1.77 and repeat. After about 8 loops, the accuracy of the parameters is within 1%. The advantage of this approach is no 5 nested for loops and no required knowledge of starting parameters. The downside is that potentially the program can get stuck in a local maximum (but I found that this is rather rare).
jlp_38
Posts: 264
Joined: Tue Jun 26, 2007 9:09 am

Re:BL2 Bot Player

Post by jlp_38 »

Hi Lieven,

Thanks for your idea :) The problem with params scanning
is that we need a reliable estimation of the average.
And it seems to be hard to get this value !
You have also to consider that the \"death zone\" optimization
is freedepth dependent so it creates an error on the avg.

1000028 block gives:
(seed reseted every 10000 block with a GetTickCount(), to avoid
possible linear congruential randomizer artefacts)

Code: Select all

        -D       0      +D     Hits
 0 => 0.00000 0.00000 1.00000 (4397)
 1 => 0.01559 0.29211 0.69230 (212902)
 2 => 0.30526 0.48332 0.21141 (472361)
 3 => 0.53393 0.35149 0.11458 (224306)
 4 => 0.55172 0.33752 0.11076 (62751)
 5 => 0.52766 0.34892 0.12342 (16448)
 6 => 0.51807 0.34725 0.13468 (4648)
 7 => 0.52467 0.32946 0.14586 (1378)
 8 => 0.49780 0.36784 0.13436 (454)
 9 => 0.41753 0.38144 0.20103 (194)
10 => 0.39423 0.41346 0.19231 (104)
11 => 0.70968 0.16129 0.12903 (31)
12 => 0.19355 0.58065 0.22581 (31)
13 => 0.50000 0.37500 0.12500 (16)
14 => 0.60000 0.40000 0.00000 (5)
15 => 1.00000 0.00000 0.00000 (2)
Lieven
Posts: 55
Joined: Sun Aug 05, 2007 6:31 am

Re:BL2 Bot Player

Post by Lieven »

Thanks a lot for this data, I will have to think about what they mean :)

You write: The problem with params scanning is that we need a reliable estimation of the average.

I don\'t think this is necessary, all that we need to know for param evaluation is whether a certain evaluation is better than another. For this we could for instance use from

4 => 0.55172 0.33752 0.11076 (62751)

the value X=0.11076 (the lower the better) or the the value Y=62751/1000000 (the lower the better). Of course this would only be useful if any of these values actually converge faster than the brute force average A.

One word about the param scanning, in my proposed scheme, I would consider a certain set of parameters better if it performs at least 2.5% better. As to avoid the influence of luck.
jlp_38
Posts: 264
Joined: Tue Jun 26, 2007 9:09 am

Re:BL2 Bot Player

Post by jlp_38 »

A plot that can help... 1000000 blocks

Image

Code: Select all

        -D       0      +D     Hits
 0 => 0.00000 0.00000 1.00000 (4431)
 1 => 0.01573 0.29172 0.69255 (214309)
 2 => 0.30542 0.48503 0.20955 (475039)
 3 => 0.53722 0.35010 0.11268 (222585)
 4 => 0.55501 0.33825 0.10674 (61357)
 5 => 0.52704 0.35172 0.12124 (15663)
 6 => 0.51455 0.35216 0.13329 (4569)
 7 => 0.51265 0.34129 0.14606 (1383)
 8 => 0.52402 0.35808 0.11790 (458)
 9 => 0.47059 0.38235 0.14706 (136)
10 => 0.44444 0.33333 0.22222 (45)
11 => 0.47619 0.47619 0.04762 (21)
12 => 0.50000 0.50000 0.00000 (4)
Lieven
Posts: 55
Joined: Sun Aug 05, 2007 6:31 am

Re:BL2 Bot Player

Post by Lieven »

Thanks for the plot, doesn\'t look terribly good :/

A last attempt: Summing the last number of the first three rows of your two tests, we get

689660 (/1000000)
693779 (/1000000)

or a variability of 0.05%. I think this is pretty good. Perhaps this value could give as an indication? Say when this value from one evaluation to another is higher than 0.1% than the evaluation with the higher number is better.

Would be pretty quick (1000000 blocks on my comp takes about 1 min).

Can you check two evaluations which are say 50 blocks apart in average and see how much different these numbers are?

If this doesn\'t work out, well I guess it was worth a shot!

PS. Thanks for trying all my weird non-working ideas :)<br><br>Post edited by: Lieven, at: 2008/02/17 17:53
jlp_38
Posts: 264
Joined: Tue Jun 26, 2007 9:09 am

Re:BL2 Bot Player

Post by jlp_38 »

Would be pretty quick (1000000 blocks on my comp takes about 1 min).

Are you sure ? Seems quite fast....
Did you count block or cube ?
jlp_38
Posts: 264
Joined: Tue Jun 26, 2007 9:09 am

Re:BL2 Bot Player

Post by jlp_38 »

An other attempt on 4000000 blocks.
I\'m going to compare the 2 evals....

Image

Code: Select all

        -D       0      +D     Hits
 0 => 0.00000 0.00000 1.00000 (18233)
 1 => 0.01638 0.29070 0.69292 (855626)
 2 => 0.30591 0.48413 0.20996 (1895268)
 3 => 0.53421 0.35197 0.11382 (894021)
 4 => 0.55392 0.33774 0.10834 (247584)
 5 => 0.52807 0.35064 0.12130 (63844)
 6 => 0.52299 0.35164 0.12537 (18010)
 7 => 0.52399 0.34939 0.12662 (5315)
 8 => 0.53595 0.34510 0.11895 (1530)
 9 => 0.55189 0.34434 0.10377 (424)
10 => 0.54839 0.29032 0.16129 (93)
11 => 0.52941 0.23529 0.23529 (34)
12 => 0.66667 0.33333 0.00000 (18)
13 => 1.00000 0.00000 0.00000 (1)
<br><br>Post edited by: jlp_38, at: 2008/02/17 18:46
Post Reply