KAZESUI'S PROFILE

well the 50 move thing is certainly weird, as it doesn't really make it go. Go is typically about building territory rather than capturing stones, eventhough capturing stones often becomes a process of that. Something which is hard to determine by a certain set of moves (A typical game spans from 250 to 400 moves).

Also, with your current AI which primary concern is to mirror your moves, it's mostly just a matter of playing the middle and building on it and killing all the stones around it (especially since you can take groups anyway), makes it rather trivial.

Of course, doing something with all this is going to be a challenge as the game rules hardly accomodates an AI's way of thinking, but it's kind of needed for it to feel like go. (reducing the size to a 9x9 board usually makes it a little simpler).

As for CPU resources, I'm not sure, that would probably depend on how you've programmed it. Is it properly event driven? Java is my strongest suite, but I can't recall having had that massive cpu consumption when I programmed some event driven gui in java.

And I'm not entirely sure how I would have done the groups of stones problem myself, as I've never programmed a go game. An immediate idea that strikes the top of my head would be to check for adjacent stones after a move has been made, and then check if any groups it might happen to touch has any liberties left.

Your version doesn't support KO's either, and considers trying illegal suicide.

You mention needing java to play it... but I see no link for the game itself. Hard to comment on something like this without testing it.

also, the image tag is working fine, you're just not linking the picture properly.
when you click on your picture in your locker, you should use the link containing "file path" in the image tags. i.e. http://rpgmaker.net/media/content/users/1503/locker/screenshot.png in this case

btw. How good are you at go? Maybe we should play sometime

For something like that, I would recommend dealing with the collision and graphic seperately. by tweaking the particles parameters, you should be able to make shapes which allows for hit detection by eventing.

Let's say you have a particle beam. Just having a parallel event running in the background checking if the player are within the coordinates of the beam would be sufficient, by screen relative coordinates if high accuracy is needed.

For circle based explosions, the best way to go about it would be to check the radius between the center of the explosion and the hero, to determine if it's within the "explosion circle". Again done with events, rather than having every single particle try to detect collisions.

author=Archeia_Nessiah
as far as I remember rm2k3 runs at 30 fps, not 60 O_o

I'm curious as to why it's believed to be 30 fps (wondered when I saw the claim in the rpgrage comic). Fraps tells me that rm2k3 is running at 60 fps.

try this: