And here is my second game.
After making the chess game, I though it would be fun to make a GO game.
The game is playable and implement a counting
system to display the score at the end of the game.
Now there is a message asking the player if he's sure he want to pass his turn.
And we can switch the final screen between score and territories.
RULES:
While playing,
Press button O to place a stone (goishi),
Press button X to pass your turn,
The game ends when both players have passed their turn twice in a row
When the game ends,
Press button O to declare a group of stones as dead,
Press button X to display the score
Once the score are displayed, the game is definitely over
At the very end, you can switch between
territory and scoreboard with button O or button X
Excellent, I was thinking about making a go game in Pico for a while but I didnt. Your game is prety well done. I would love a 9x9 version, wich is faster to play.
The cursor is a bit off center, maybe use a 5x5 sprite instead of a 6x6 ?
A visualisation of each player area before showing the counting could be great too.
I think I will make a second cartridge for the 9*9 version, to be able to have larger sprites. Because a lot of texture space is used to avoid numerous draw calls.
55 sprites means reducing the size of the whole board of 5/6 (83%)
so instead of 114114px it would occupy only 95*95px of the screen
so the padding around the goban would be of 16px instead of 7px
Also it is possible to display the territory, I just need to comment a line of code. But it is true that I should allow the user to actually switch between both view.
Nice for the 9x9 version !
For the 5x5, I was just suggesting that for the sprite cursor, so it is centered. No need to change the board size, your's is pretty much perfect.
I would also suggest a confirmation screen when you use the pass button. Or maybe it could be a menu if you allow switching view.
I've updated the game now it's called pico-go
I've implemented your suggestion except for the smaller cursor
if the cursor was 55 then the goishis should be 55 too and there would be a gap between each goishis and it wouldn't look good.
But yeah at first I was frustrated that I couldn't align precisely the goishis on the board. But now I think it's fine as it is.
The fact that we cannot return the board to a previous state ?
Not now.
To make that rule work, I need to store the state of a set of stones two turn anterior from the current turn, I'm not sure how to implement that and it might cause bugs to appear.
Furthermore, I'm not sure this rule is applied in all of the variant of GO.
I'm currently more interested into reducing the lag when a player place a stone and conquer a large territory.
It should be possible to implement the simple ko rules, where if you take a single stone, the opponent cannot take it back immediatly if it result in the same situation than before the first capture. I am not entirely sure but I think you just need to look when there is a single stone capture by a stone that is immediatly in atari, the opponent cannot take it back. It should take care of the most common repetition. I think the usual rules doesnt prevent more complex repetition, and they can result in a draw.
I have started an implementation of the game on my own, but didnt put the ko check for the moment.
What NuSan said, ko has such specific criteria that you could just check once a single stone has been captured, if the next move in that space would cause the previous piece to be captured, then it's clearly ko. I get that it might not be so simple on the code side, but it certainly doesn't require scanning the whole board for redundancy.
[Please log in to post a comment]
