I would like to participate 
3 Likes
You’re actually being pessimistic here, because each stones occupies less that 5 points: since an empty intersection is allowed to be adjacent to more than one stone, it’s allowed for two of these 5-point blocks to overlap a bit.
The probability of not having a collision, when generating 105 random numbers uniformly and independently from a range of 169 numbers, is about 0.00000000000001. (This with the approximate formula e^(-n²/d) from Wikipedia: Birthday problem to approximate the probability of a collision when generating n random numbers in a range of d numbers).
Anyway, as antonTobi stated above there is no reason to prefer “exactly uniform” and it’s possible/likely that the program is already exactly uniform anyway.
Good point! I had not thought of that. So, then it seems to me even more likely that a program can reasonably generate a board looping over possible starting points and rejecting them until it finds an acceptable one.
Regarding your calculation, I have no idea about the math behind the problem. You seem to know more about this stuff than I do so I defer to your judgment.
Sorry I hijacked the thread a bit with probability considerations. The messages of joining players have been a bit buried.
Current list: 4/7
- NeilAgg (you haven’t actually stated it but I assume)
- ArsenLapin
- yebellz
- martin3141
Additionally antonTobi has manifested interest.
2 Likes
Since the places are filling up pretty quickly, I will cave and confirm my participation 
More off-topic probability
Even though this probability was for a different much more difficult setup, it made me question whether my intution for the original question was way off, so I wrote some code to check whether the “try and discard” approach is feasible. This is how many attempts it took to get a valid stone placement (21 stones on 13x13 board, with no two adjacent) in ten different trials:
663
174
10
1247
13
582
292
233
2141
365
(I made each placement at random on the 169 intersections and immediately aborted the attempt if it happened on top of or adjacent to another stone)
And for comparison, I ran the same program trying to place 30 stones on the same board, that actually took a couple of minutes to finish:
1567299
2429838
3286975
3378851
871482
531407
253101
1510326
2317355
169269
2 Likes
Thanks for joining the game!
Off-topic starting board discussion
I agree this discussion is probably off topic, but I have been finding it very interesting. My gut feeling was also the scenario is not as pessimistic as @ArsenLapin1 was stating. Thanks for checking that.
@ArsenLapin1’s calculation assumed he needed 105 random numbers out of 169 possibilities without collisions. But, then he/she noted that the neighboring spaces could overlap. That might account for the difference in the numbers.
Another bit of housekeeping -
I found this page List randomizer
Once we have the players, I will ask someone to generate and post a board with 3 starting positions for 7 colors. After that, I will type the 7 colors into the list randomizer and have it generate them in a random order. I will write them in a starting post. Then, I will put the player names into the randomizer and have it randomize those. I will write the names next to the colors in the order the randomizer gives them to me.
Hopefully, this will be an acceptable starting procedure for everyone involved.
1 Like
So you want to shuffle both the list of player names, and the list of colours?
Wouldn’t it be easier if we kept the colours in the order they are listed on Vsotvep’s multicolour go board? This way we can easily see who’s next on turn just by looking at the board, without having to refer to a post buried somewhere in the thread.
See the colours listed on the right side of the board.
2 Likes
I don’t want a pre-determined order of play.
I will edit the first post so the order will be easy to find.
It might be interesting to randomize the order of play for each set of turns, but let’s hold that off for another game.
Obviously the order of colors is arbitrary and doesn’t affect gameplay, so I like the idea of using the order from the tool.
2 Likes
I want to be responsive to the people, so let’s put it to a vote once we have all the players.
I guess we need to put a time limit on sign-ups so I will start the game either when we get 7 players or at 10am CST tomorrow.
Let’s start the poll to see if people prefer to have the order of play for the colors randomly assigned or follow the order listed on the playing board. Please only vote if you are playing the game:
- The order of play should be determined randomly and shown in the first post of this thread.
- The order should be as shown on the game board: red, yellow, blue, green, pink, cerulean, orange
0 voters
We will still assign players to colors randomly.
I had not previously considered the vote could be tied. If that happens, I will flip a coin.
(as already mentioned) I would like to join as well. Current ruleset looks reasonable, but it would be really nice to somehow soften the timelimit. Maybe variation of Fisher clocks or whatever. On average, I am eager to make turns quickly, but in some corner cases (e.g. leaving the city for weekend) it would be pretty uncomfortable to have such a strict deadline. Maybe we can consider 4 byo-yomis like 1, 2, 2, 1 days with the restriction to kick player after 3 days offline? This may be pretty complicated system, so I definitely do not insist on exactly this variation.
For me there is no difference between systems because I already have to remember player <–> color mapping. Which should be shown in the first post of this thread.
I am not meaning the time limit to be oppressive. If you are going to be unavailable, you can post it to the thread and the game will wait for you.
In the other game, players disappeared for long chunks of time without any communication, leaving the other players to wonder if they were still playing. I am only trying to solve that problem.
Also, I am sure there is going to be a flurry of messages before the first move since people will have to cope with their assigned starting postions. We will allow extra time for that.
I will add some info about this to the rules in the first post.
1 Like
It would be nice to automate “screenshot” part of the game 
Maybe we can add a corresponding button to https://vsotvep.github.io/MulticolorGo.html interface?
1 Like
That would be nice, but we can work with the tool as it is now. Maybe @Vsotvep will consider implementing it as a feature. Time permitting, of course.