SUPREMEWARRIOR'S PROFILE

author=Kazesui
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.