Sanity Check for a newbie

Hi, I'm new to Second Life, and so new to LSL coding. But it looks like fun, so...

Being the ambitious type that I am, I thought I'd try to make a Go board as my first attempt at scripting. But I seem to have hit a problem - every possible position on the board has to be selectable as a place to play a turn. As far as I can make out (and I have read the wiki quite extensively), the only way to deal with a user clicking is with 'touch' events, and they are just dealt with on a 'one per prim' kind of a basis. So I'd need a prim for every place a user could touch to place a piece. On a full size Go board that means on the order of 400 prims, which seems to push the idea into the realms of impracticality, given both the time required to create that many prims (I was going to do it dynamically when a game was started, but with a 1 second delay per rez ...) and the land required to support that many prims. So, am I missing something? Is there another way to do this? Perhaps some way to get the actual coordinates of a 'touch' event on a prim? Even a 9x9 Go board, which is just about big enough to be fun to play, would be stretching things a bit.

Any help and advice appreciated.

Jonathan

You could use a rezzer that generates black and white pieces that can be dragged or otherwise moved onto a position on the board, but this might make playing a bit cumbersome.

Only feasible solution i can think of.

Fortunately, I'd tried something like this before back when I was only half-decent at scripting. Here's my take on the matter, though honestly, it's pretty deep. These are just things to think about, and if you have the good fortune of finding me in-world, I might even help you make it!

Anyway:

1) The board itself is a difficult matter. One solution is to use a controlled prim over the top to define where to place a board piece, as opposed to touch.
2) Since board pieces are non-descript "dots," or "stones," it's feasible to use the particle system in a radar manner to display board pieces. Even lower prim overhead, and we can use lists and distance formulae to find where to go.
3) Now for a problem. How, exactly, would you check for "atari" of pieces on the board? Leave it out and just focus on the actual game?

Anyway, these are things to think about... but they're fairly advanced concepts. Good luck!

You can build a board using fewer than 362 prims (1 board + 361 points) if you're willing to deal with some complexity in your scripting. Unfortunately, there is no way to tell where on a prim it is being touched.

You can however detect which prim of alink set is touched. You could assemble your board of several segments that communicate over chat. Each point can be covered by a prim, and touching that prim would play at that point. If you made each of the prims the shape of a stone, you can just change its alpha and color to make it visible and black or white.

It's fairly straightforward to write a script that assembles the board and stone components into segments that can be rezzed into place as a whole board. Though that scripting may be more tedious than constructing the set by hand. Either way, if the board is made of several segements you can rez them by script and let them chat to communicate.

Another approach is to use textures to fake the stones, and use chat commands to play on the board. But really, saying C-12 to play a piece is so inelegant. But if you go the texture route you can use a neat prim hack to display 3 textures in a plane: make a box prim, set the X size of the top to 0.33; make X=3, Y=1, Z=0.01. This gives you 3 1x1 squares as different faces of the cube, and it all looks flat. Then you can set the textures of the faces independently. If you want to conserve prims, put four intersections on each side and then you have 81 textures to get the combinatoric set for empty/black/white for four points. Or you can be less crazed and use 9 textures for 2 points, and at 6 points per prim, you'd only need 70 prims for the board surface. That's not too bad, and it is even linkable.

Anyway, it's a challenging problem. I look forward to seeing your solution.

You're sure you don't want to do a rocket as a first script instead?

Instead of a chat command (or in addition to -- multi-mode input, yay!) you could use a cursor, some prim that woud start at the center of the board and move up down left or right by touching buttons on a controller pad.

You could also use the texture technique to implement the cursor.

Good luck on this project.

Thank you for all your various suggestions, nice to know there's a good helpful community here

I considered the 'play c-13' type approach to get around needing a prim for every point, but it's klunky and nasty and goes against the whole idea of it being a 3d world where you interact with things by touch. Similarly using a 'control prim' to select where to play would be extremely tedious to use in practice, I think. I actually had an idea for how to solve the problem while lying in bed last night. Isn't that where all the best ideas happen? It's still slightly klunky, but a bit better I think. It'd work by needing two clicks to play a piece. The first click would zoom in on a particular area of the board, then the second click would select the exact space. So to support a 19x19 board you'd just need a 4x5 grid of 20 prims to select where to play, with some cunning 'moving prims around and resizing them' code. Sound feasible?

That still leaves the problem of displaying the actual pieces, though in a typical game far less than half the available positions end up with a piece on them. The particle system idea is intriguing though, will have to investigate that.

As for atari, seems fairly straightforward to me. Was going to have the board state at any time represented as a string (given we don't have multidimensional arrays), and it'd be that string that would be used to calculate captures and the like. So you just have to keep the strings representing the previous two positions of the board, then check back if your new state is identical to the state two turns ago, in which case you have atari.

Hmm, this is all going to be quite a lot of work isn't it...

Jonathan

That would be a ko, not an atari Jon... But if you get your Go game working I will come and play.

One way, given your idea of playing with a 'Zoom' and a 'touch' idea might be to have slightly more prims in the board and a coded texture so that you're 'snaphot' prim contains textures for every possible combination of black stone, white stone and space on it. Then a nifty bit of code that chooses the right texture for the new state...

Another alternative, not quite Go, but not bad, would be to have 39 prims - the board and 19 letters and 19 numbers. To play on a given square you would touch the letter and the number, so playing at C19 you would touch the edge of the board twice rather than once, but you would keep a small number of prims.

You'd need to think about whether to use particles, textures or something else to actually display the stone, but that would be a hack that would be OK I think.

Oh yes, so it would. Been a while since I played, forgot my terms. Ahem. So yes, that's how I'd handle Ko, atari would just be a question of a quick parse of the current game state after each stone played, though it could just be left up to the players to be polite about it.

I have a feeling I might rapidly hit that 16k script limit. Ah well, best way to learn

Touching coordinates rather than saying them would be slightly better, but I think still not as nice as the 'zoom' approach, too easy to slip up, misread which row something was on and make a mistake.

Only way to be sure though is build it and see ..

Jonathan

With just about any system, you might want to add accept and reject buttons before finalizing moves. You could see it rez your move, but you could still undo it until you accept it.

Yes, an 'Undo' button is probably a good idea. But I think I need to worry about getting everything else working before I worry about that..

I don't remember go so well, but I think that it involved checking to see if any piece had no "liberties" (free neighboring spots) left. This involves seeing if it is touching (directly or indirectly) any other piece that has liberties... if a whole chunk of touching stones don't have liberties, they're removed.

If you're trying to do this in a script, good luck. I don't just mean this is an ambitious project for a new scripter, I mean this is damn near impossible given the state of the language. List processing is highly inefficient in LSL, with each lookup requiring a scan through the list from the start. You also can't set an individual item in a list to a specific value; you instead have to chop the list up and rebuild it. Same for strings.

I'm sorry to be all doom and gloom, but at best, I think your board is going to be woefully inefficient at liberty-checking. At worst, it's going to be impossible.

Good luck

Atari is actually checking when a group has a single liberty left, it's a 'polite warning to other player that their pieces are about to be captured', like saying 'check' in chess. Capture itself is when there are no liberties left. Was planning on using strings rather than lists for checking, should be more (a relative term..) efficient. Remember, you don't have to check the whole board, just the groups adjoining the new piece that has been played.

But this is all theoretical so far. I've seen chess implemented. If chess can be implemented, so can Go. Or so I'll keep telling myself until I hit a finally insurmountable problem.

How about a mouselook-based "target what you're looking at" thing, where you use the intersection of the board and the eye-vector to find x,y and use x,y as u,v offsets on a mostly-transparent overlay that is the cursor. Then you could also use a bit fancy math stuff to figure out the precise discrete x,y for the new token. Ask me to elaborate if this doesn't make sense. Gotta split now.

It makes sense. It makes my head hurt, but it makes sense. Didn't realise the eye/camera vector was ever available. I think my trig is probably too decayed in my head to figure out how to actually code it though, and I don't think people would like having to go into mouselook to play ...

But thanks for the suggestion.

Jonathan

Seriously? The easiest way to do this is have a draggable piece system using llDetectedGrab to keep the piece inside the board and/or over the spots you shove the pieces.

You'll still end up with a prim per piece, but at least you won't need to code a grid of four-hundred touch-spots.

Correct, Chess was implemented. However, it had no check/checkmate algorithm.

I've given this a fair deal of thought in the past, so if you figure a way to do piece captures and Atari effectively, you have my vote.

Brute force... Slyly.

Create your overlay of 400 prims (in the sandbox) that speak on private channel when touhed then llDie(). Link them together and set the object Temp on Rez. Take it and stick it in your one-prim board. When it's someone's turn to move, script-rez this object over the board. It will only exist for a minute or so or until they click it. It will not count towards the parcel's prim limit. Consider it the scripted equivalent of "hoochie-hair".

Your main problem will be the pieces themselves, since it's possible that most of the board could be covered at some point. I see two main options here. One is to use texture pieces, and make the 81 possible combinations that can fit on a 2x2 square (putting as many of these as possible into a single texture, not each on their own texture!). Then you need only 100 to cover the board instead of 400. (3x3 square would have almost 20 thousand possible arrangements, so that's no go. 100 is the best you can do this way.)

The other option is to have Temp on Rez pieces like the touch-field. The main difference is that they need to refresh themselves. Easiest solution is for the board to re-rez these temporary pieces just before they are scheduled to vanish. They will overlap for a moment, but then you'll never have a gap. More simulated "hoochie-hair", but it should work.

That would work, I guess, though the touch-grid would need re-rezzing too. Go is a slow game, people are often going to take well over the 80 seconds to play a move. Don't really like it as a solution though, it seems like it'd place more load on the sim than just having all those objects permanently there, with the constant prim-creation and deletion. I could be way off base with that though ...

From a fe wposts I've read here and there and a little of my own experimentation, temp-on-rez objects do count toward the parcel's prim limits now.

I haven't seen those posts :-/
But anyway a study will have to be done.
Sounds like a bug *gets out bug squashing boots*

I made a (to me, at least) fairly intuitive grid space selector.
It's only 8x8, but should expand to 20x20 quite easily, if you wanted.

I'm using 18 prims to do it -- 8 for columns, 8 for rows, 1 for a checkerboard pattern, and one for a decorative border. A similar design supporting 400 discrete spaces would take only 42 prims.

It's a two-click system. The board is overlayed with 8 transparent "column" prims and 8 transparent "row" prims.
The first time you click a square on the board, you'll hit the "column" prim, as it's the topmost.
It lights up to indicate you've touched it. Then it moves downward, so you can't touch it anymore -- so your second click on the desired square will hit the "row" prim for it.

If you want to try it out, it's at my home in Marunogere, (193, 80) -- it looks like a checkerboard. I'll leave it up for a few days for anyone interested. I'll also post the scripts, if you want.

I've just got my zooming method of selecting working, maybe we should compare and contrast to see which is more intuitive to use . For a 19x19 grid (standard Go game size, though I'm going to support the other two smaller standard sizes two), I need 20 prims, in a 4x5 grid. One click selects a region of 5x4 squares on which to play, the next click selects the exact square, with the same prims being moved around as the sensor grid zooms.

Now all I have to do is implement the actual game logic, he says blithely ...

Jonathan

since there is no real list management, like some other languages, the problem can be addressed by using binary pairs. If you have a board with 64 possible places across the x and 64 possible places across the y, then you can use 64, 64bit binary numbers set like a grid to hold the 1 for a white piece, and zero for a black piece. A similar group of these binary numbers would then also need to be used to detect that there is a piece on the corresponding point.

Was that clear? (It was clear to me) haha

Ah, that's the easy bit. Actually just using strings, bit wasteful but don't really need the extra complexity of using bits. An efficient algorithm for detecting contiguous groups and whether or not they're surrounded, plus handling the slightly awkward end-game and scoring mechanics of Go, that's the tricky bit ...