Building a Go Board

One thing I've wanted to do for a while in SL is make a Go board. The major design problem is that the game is played by placing stones on a 19x19 grid, so if I was just going to have a prim rezzed for each stone, that's theoretically 361 prims. I don't really want to make something that requires having that many prims available to use. Of course, stones aren't placed on every space in a normal game, but it's usually over 200 and games exceeding 300 moves aren't that rare. I've seen one Go board before in SL, and it just used this method.

The first idea I came up with was to have textures for each possible configuration of a small portion of the board, then repeat that to make the full board. I realized that this wasn't going to work when I started figuring out the details. First, how big do I make the sub-sections? I discovered that 2x2 is probably the biggest that is feasible, and even that requires a pretty big number of textures. Each space can be either empty, have a white stone, or have a black stone. So for 2x2 sections I'd need 3^4 textures, or 81. If I went 3x3, that becomes 19683. But I'd also need different textures for the edge and corner pieces, because the grid lines would need to end at the edges instead of sticking through. Finally, there's the problem that 2x2 sections don't fit evenly into a 19x19 board (in fact, 19 is a prime number, so no possible section would fit evenly). This means I'd also need to have some different shaped sections (like a 1x2 and 1x1) . So the final tally is:

- 81 textures for the middle 2x2 sections
- 81 textures for the side 2x2 sections
- 81 textures for the corner 2x2 sections
- 9 textures for side 1x2 sections
- 3 textures for the corner 1x1 section

So 255 textures, plus I wouldn't even be saving that many prims. I'd need a 9x9 grid of 2x2 sections to make the 18x18 board, that's 81 prims. Then another 19 for the edge to make it a 19x19 grid. And I haven't even mentioned that all these different sizes and types of sections would make for a coding nightmare.

So the solution I'm considering now is to have one prim for the whole board, and have the board send an HTTP request to a web server that would take the current board configuration and send back a texture for the entire board. The texture would need to be generated on the fly, as storing all possible textures is literally impossible (even if I could store a texture on a single atom, there aren't enough atoms in the universe to store them all).

This last option seems the most feasible, even though it involves some things I haven't done before, such as HTTP requests with LSL. And there's also the issue of the HTTP server. I can run it on my own computer when I'm building this, but unless I'm just going to use the Go board for personal use, I'd need a dedicated machine to run the server.

If anyone has any insights about this or other methods, please let me know.