Speaking of that, I have been spending a lot of time working on it since my last post (though I've been focused on the Mono testing these past few days). Most of the work has been in things that aren't finished, aren't visible, or were dead ends (at least I was learning how NOT to do things). Here is a quick list:
- The board state is now stored (storing 19x19 integers comes very close to the memory limit for scripts, so I had to make a script that is basically a data server and other scripts query the data through link messages).
- With the board state stored, I can now report an invalid move if a stone has already been played there.
- I added the board's rotation into the stone placement, so it no longer has to be aligned along the world y-axis to place the stones in the right place :P
- I spent a TON of time fooling around with llSetCameraParams, trying to get the camera to face straight down on the board from above. This was in preparation for an idea for a HUD which would overlay things onto the board. Unfortunately, the camera controls don't really allow for precise placement. I was able to get the camera to face straight down on the board, but I could not control the "roll" of the camera (up vector in more technical terms). The SL camera always tries to keep its up vector as vertical as possible. When the camera is facing straight down -- so the up vector becomes completely horizontal -- it apparently always points along the positive x-axis. I could not find a way to change this after much tweaking of the llSetCameraParams arguments. I had to give up.
- I started looking at HTTP requests. I had code for a multi-threaded web server from a networks class I took, so I got that running and was able to send a message to it from SL and get a response. It shouldn't be too hard to have it run copies of GNU Go and pass GTP messages back and forth.
- I downloaded QAvimator and started learning how to make animations.
This Go board project is pushing me to learn a ton of different aspects of Second Life content creation. It's great.
4 comments:
Woot! Cool! I should receive the Go books I ordered tomorrow, so I'm really looking forward to refreshing my memory on how to play. I've spent TONS of recent time on related blogs and websites though, but until I get back up to speed on the basics most of the stuff I've seen there is well beyond my comprehension.
Speaking of animations... You might also want to try DAZ|Studio. It's what I use for my C:SI anims, and it is also free. It's got much more powerful tools than QAvimator (which is a pretty nice program for very basic stuff, don't get me wrong) and can be extended with custom plugins. Just a personal recommendation :-)
I'll check out DAZ|Studio, thanks for the tip!
That sounds really sweet. Is there any possibility you could make it listen only to the person whose turn it is and only on their turn, with click to listen activation? I would love to have a Go board in The Final Stand's dojo but I'm concerned it would mean an active script going all the time.
Right now the board is always listening, but the fact that it's listening when waiting for players to start a game is really just leftover from previous versions. I can easily take out that listener. During a game, however, it would be annoying if the user had to click the board before entering each move, but I have a few ideas of ways to reduce the listening required without adding that annoyance.
Post a Comment