Hi Josef,

> ... I think that we do not need to ensure that the stone cannot land 
> diagonally 
> by small epsilon, since ingo defined it s.t. it cannot. 

Exactly. "Frisbee Go Simulation" is not meant a realistic simuilation of
true Frisbee Go, but as an abstract testbed for a Go variant with random 

> Having small epsilon as you suggest makes any attempts at writing a 
> specialized 
> frisbee-go code not really fruitful, since the displacement is quite rare; so 
> realistically, with small epsilon, no-one would probably bother to do 
> anything 
> different than to run current programs unchanged.

Right. In particular, the idea is to play on 9x9 board in the Olympiad 2016.

> ... Moreover, larger epsilons change the game's dynamic s.t. it is easier to 
> live 
> and harder to kill (hypothesis). Another thing is that the MCTS might work 
> much 
> better with this setting (since random playouts are much more true).

I want to challenge this. From other games with random elements (for instance
"EinStein wurfelt nicht") it is known that specialized algorithms are much
better than simple adaptions of MCTS. 

> ingo: One note for rules (you should add) is that when players throw stone 
> to a location where the probability of landing on a valid location is exactly 
> zero (all 5 positions are stones or invalid) this counts as a pass 
> (otw, the loosing party might play the "non-voluntary pass" moves and make 
> the game infinite. (sorry if I overlooked someone mentioning this already) ...

SUch problems were the reason for my original formulation: not differentiating
between intended and unintended passes. Stop of phase 1 after two consecutive
passes. Completion of the game in normal Go mode in phase 2.

By the way. Michael Hartisch (from the Ulf Lorenz group at Siegen U) proposed
to have in the Olympiad one "Frisbee Go Simulation" participant which is a
normal Go bot. This bot will likely not win a medal, but its performance may
show how different (and difficult) Frisbee Go Simulation is from normal Go.

Regards, Ingo.
Computer-go mailing list

Reply via email to