JAVA GO GAME

Posts

Pages: 1
I've got a working version of my game now and I would like people to test and give me feedback on here.

List of working features:
- Saving and loading game
- Passing turns
- Move list, shows a list of moves made in the game
- Simple weak AI, I plan to improve it.

I'm also open to suggestions and keep in mind there are a few things I have not yet completed:
- Capturing groups of stones
- Move Numbers for stones
- Other strategies

It is programmed in Java so you will need java installed to play it.


Download Link: http://www.sendspace.com/file/6n12p3
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
Thanks I never knew that... We should play sometime, I'm actually a beginner but I would like to get better.

Edit: Added download link
Capturing groups of stones is something you should probably implement asap, yeah.
Something you might want to consider is some way of determining the influence of a single stone as well (this in terms of creating a stronger AI). This might aid you in creating a "scoring" function which is normally present in go software as well.

The game also suddenly quit on me and said the AI had won. I suppose this is also something which hasn't been coded out entirely yet (just noticed at second look at picture... you're limited to 50 moves?)

Something which you need to fix though, is it's usage of CPU resources. It uses too much of it. It should at least use less when it's window is not the active one.
author=Kazesui
Capturing groups of stones is something you should probably implement asap, yeah.
Something you might want to consider is some way of determining the influence of a single stone as well (this in terms of creating a stronger AI). This might aid you in creating a "scoring" function which is normally present in go software as well.

The game also suddenly quit on me and said the AI had won. I suppose this is also something which hasn't been coded out entirely yet (just noticed at second look at picture... you're limited to 50 moves?)

Something which you need to fix though, is it's usage of CPU resources. It uses too much of it. It should at least use less when it's window is not the active one.
Thanks for the feedback Kazesui!

Yes you are limited to 50 moves I thought it would be good if the player can beat the AI at it's current implementation within 50 moves.

About the CPU resources I don't know what to do about that, since I didn't develop it in mind to be resource heavy... What do you suggest I can do to solve this?

Currently my biggest concern is capturing groups of stones, I've got a working floodfill algorithm so far that can capture groups of stones on the click of a mouse but I don't know a way to apply it in-game.
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.
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.
Actually after looking at the code I can understand why it takes up so much CPU resources, it's because I'm constantly drawing graphics. I guess it could be optimized but it works so thats what I'm mostly happy about.
Pages: 1