Scoring Rules
- Created Thursday, March 17th 2016 @ 20:46:28
Hi,
Most all points scored in a game of Go come from controlled territory. Whereas the scoring implemented here appears to be stones played + stones captured.
Compare with the typical scoring method (from http://senseis.xmp.net/?Scoring):
Territory Scoring
In territory scoring, your score is:
- the number of empty points only your stones surround
- minus empty points surrounded in seki (depending on the rule set)
- minus the number of your stones that have been killed (whether captured during the game, or removed from the board as dead stones at the end of the game)[2]
Here's an example: http://senseis.xmp.net/?JapaneseCountingExample
- Updated Thursday, March 17th 2016 @ 20:49:34
Note that these are non-trivial to calculate:
- whether an empty point is controlled by a player
- whether an empty point belongs to a shape in seki (http://senseis.xmp.net/?Seki)
- whether a stone is considered a "dead stone" (http://senseis.xmp.net/?DeadStones)
- Created Friday, March 18th 2016 @ 23:07:26
They do give points for areas surrounded, but apparently just a single opponent stone seems to "ruin" an area.
Theoretically this scoring system should start to get closer to the real go scoring if the games were allowed to run for long enough, as dead shapes would naturally be removed in the process (and thus scored the same as in actual rules of go). But as the game is abruptly stopped in just 300 moves (real go games are often longer!) the scoring doesn't get even a full "first pass" in approximating the value of territory. So as for now, this "variation" of go throws away a lot of the strategic depth of go.
Maybe the devs are worried that existing (open source) go bots would be used (or would dominate) in the competition. But I think they shouldn't be worried, as the restriction on time nevertheless forces players to come up with creative search optimizations, giving custom bots an edge.
I am both a go player and a programmer, and I would love to participate in the contest, but if the ratio between board size and amount of moves (or the scoring system) is not made more sensible, this variation is too random to my liking. I do like the full 19x19 board, but for maximum of 300 moves something like 13x13 would be more interesting. (I still rather hope we get more moves!)
- Created Saturday, March 19th 2016 @ 05:11:47
For computer Go, I am certain that Area scoring is correct:
http://senseis.xmp.net/?AreaScoring
Computer Go programs should expect to capture every enemy stone in their territory, to make the scoring completely unambiguous. Using Area scoring, there is no cost to the player who places stones inside their own territory to capture enemy pieces (unlike the case when using Territory scoring). The engine can assume that all stones on the board are alive, and counting the score automatically becomes trivial.
Using this system, however, it is necessary to increase the round limit. Computer Go games counted in this manner will often require dozens of extra moves, making the game much longer than a game between humans using Territory scoring (which is why most humans use the latter, preferring not to waste time at the end).
I think at this stage, while most bots are making random (occasionally illegal) moves, the round limit is fine (in fact it would be reasonable to run games on 9x9 boards to make them shorter still). In the long run I agree with previous posts, I would like to see bots play on 19x19 boards (and perhaps other sizes as well) and with the turn limit increased to something like (width * height * 1.5).
- Created Saturday, March 19th 2016 @ 20:12:10
Hint: GNU Go, a.k.a. gnugo, has a command to score any position. It would be easy for the server programmers at theaigames.com to just defer the scoring to gnugo.
-Inge, a former gnugo programmer
- Created Sunday, March 20th 2016 @ 02:49:17
Ingwa's suggestion might solve another problem: what happens when one bot continues making legal moves for as long as it can? Using a naive implementation of area scoring, one or more areas is likely to be nullified when the round limit is reached, simply because there wasn't time to capture all of the dead stones.
This seems to point toward removing the turn limit entirely, or using some sort of smart scoring method (like the one implemented in gnugo).
- Created Sunday, March 20th 2016 @ 06:04:45
I think - main problem is in long waiting of game playing. Two engines can play cooperative very long time, capturing their groups and playing on it's place.
Yes, limitation adds new strategy to Go - eating dead group on time. It will not be game of Go. But i don't know any alternative to limitation (i hope that it is). Expert scoring like GnuGo can't help us if we don't limit moves - games are still very long.
- Created Sunday, March 20th 2016 @ 09:14:39
May be let it be long? Lets reduce move time limit from 500ms to 100 ms and allow the game ends naturally? I hope that top bots will passing much earlier, when scores can't change anymore.
JoroseCreated Sunday, March 20th 2016 @ 11:35:03I propose instead of a hard move limit, limit the number of captures, ie add a win condition that if you capture a certain number of stones you win! Aside from that Tromp-Taylor scoring seems more appropriate than Gnugo scoring which is often flawed.