I haven't done much with my Go board recently. Mostly because I am once again trying to switch to using a Linux environment as much as possible, but have been discouraged from using Second Life because of sound problems.
However, I now have three people who have expressed interest in owning one, so that has encouraged me to try to get back to work.
I'm thinking about changing the way my board handles the stones. Right now, each time a stone is played it rezzes a prim for the stone. The other option is to have an invisible stone fixed at each location on the board, and then when a stone is played make it visible and set its color. The advantages to the second method are that now the players can just click on the board to place a stone instead of having to type in the coordinates. Also, the stones can be grouped with the board so that if the board is moved, they will move as well. It doesn't seem like there is a way to group prims through scripts, so some other method that would most likely be more complicated and not work as well would have to be used to get the same effect.
The obvious disadvantage, and the original reason I went with the first method, is that the board will require 368 prims at all times. Using the current method, it only needs 7 prims when not in use, and if the players are only using a 9x9 or 13x13 size board, they won't come near 368 prims. Even on a 19x19 board, not all games will use 368 prims. As I think about it more, though, is there really an advantage to having it only take 7 prims when not in use? They will still need 368 prims available when they want to use it, and I doubt many people will want to have to return all their furniture or something each time they want to use the board, then re-rez it when they are done.
I have come across two other Go boards in SL. One of them uses this method I'm describing of just having invisible prims for all the stones. The other had the user click the board which would rez a stone, then the user had to edit the stone and move it onto the correct board position. I'm not a big fan of that last method.
Any suggestions?
Subscribe to:
Post Comments (Atom)
3 comments:
What about a a low prim version that uses textures? If you made a texture for each, say, 4x4 configuration then you could reduce prim count quite a bit.
That's something I talked about when I first mentioned the idea of building a Go board. It's a good idea in theory, but it falls apart when you start following through with it. First of all, there are 43 million 4x4 configurations, so they would need to be smaller. 2x2 has 81 configuration, which is probably about the limit of feasibility. Then, of course, a 19x19 board doesn't break up evenly into 2x2 sections, so you'd need textures for 1x2 and 1x1 sections. In the end, you don't end up saving all that many prims and you have to upload a couple hundred textures. Plus, it looks so much better when the stones are 3d ;)
Looking back at that post I linked to in the previous comment, I also mentioned the idea of generating a texture using an external program and then having that texture sent back to the board. As Robby pointed out, that would require HTML on a prim...which is now possible. Unfortunately, the way it works currently is the same as a music or video stream, i.e. what webpage is displayed on the prim is controlled by a parcel setting, so as far as I can see it still isn't useful for solving this problem.
Post a Comment