Discussion: Go Board

Haven't re-sized the board at all. Everything is still at default values, as the scripts set them up. I'll dissect my board later today, if I have time, but my suspicion is that there is something wrong with the basic tile building block, that is causing it to not texture properly.

Everything else seemed to be working. The only odd part was that when joining a game, I had to select the 'board size' pie link, rather than the 'sit here' link.

Hmm, good point. A list of even 361 integers would probably be too big. At least these things very rarely come up in actualy games. I'd be very surprised if there were ever a group of more than 200 stones in a real game, although that might be too big as well.

The using letters idea gets round the recursion issue since you just need to check that some intersection labelled with this letter has a liberty next to it - neat. Maintaining the letters might be a bit of a pain though. You'd need a max of something like 200 different possible "letters", and you can't make a list of them... yuck.

A while back i wrote a unicode to utf8 encoding function (it's on the wiki); once you generate the escaped versions of the characters you can use them in strings (then when your script initilizes it unescapes the string).

So you'd use that to work with integers for the various groups, but have the info stored in strings?

I was thinking of some nasty stuff to reuse letters that had disappeared, due to capture or consolidation of groups... maybe it's not worth it, but it wouldn't be hard to store a list of reusable letters, and if its empty, use a new one.

Now i remember why i didn't write a go board, storing the liberties is an ugly ugly problem. For each group you would need to keep track of them. Though its not impossible...

you could use the group character to find a character in a string.

Sorry you're having problems, not sure what it could be, unless it's just a texture loading issue. I know sometimes in the past that textures have been very slow to load, which can make it look broken. Not sure if there's anything much I can do about that, others may have some ideas ..

Oopsy. Probably used in a previous incarnation of the code, I tried to clear up most things like that when I did the final code clean-up, but obviously missed that one, will fix on the wikki.

Stack problems can occur during scoring on a 19x19 board with very large groups. Notably if you 'finish' a game with no pieces on the board at all (so the whole board is one big territory) it'll chug for a while then die horribly. Hopefully with most realistic game situations though, this wouldn't be a problem, but I've only played a couple of full size games to test.

As someone else noted, yes the prim usage is constant, regardless of game size. If you want to only support smaller sized games, you can reduce the prim usage a bit - there are brief pointers to this on the wiki.

I'm sure there is a better solution that the basic recursive technique used for group checking, but it would probably require significantly more code. It's esssentially the same as a flood-fill problem, and I'm sure I've seen clever solutions to that.

Just curious anyone still actively working on go boards these days?

There is one other person who has to my knowedge developed a Goban that is Jorgeluis Burrel. I used to play him quite often.

well between that post and now I've gotten mine working... 19x19 3 prims and lots of temp ones - I'm not checking ko (but that rule enforces itself ). looking forward to testing with people soon.

BamBam Sachertorte and I have done a board - you can find it at the Go Center of Second Life.

A bit different than other approaches: The board uses one prim per stone, even when empty. This allows for a very nice playing feel: Just touch where you want to play.

The board supports handicaps, komi, scoring, markup, and limited undo. Coming soon are full undo, game review mode, and SGF output. Check it out...

And it uses Jonathan's lovely go stone sound!

- Zarf