Log In  

Cart #26216 | 2016-07-31 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA

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.


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

version 1.0.0
Cart #26141 | 2016-07-30 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA

Older version 0.0.1 (no counting system)

Cart #25317 | 2016-07-14 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA

P#25318 2016-07-14 19:39 ( Edited 2016-08-12 17:57)

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.

P#26174 2016-07-30 18:04 ( Edited 2016-07-30 22:04)

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 114
114px 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.

P#26181 2016-07-30 19:59 ( Edited 2016-07-30 23:59)

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.

P#26200 2016-07-31 03:31 ( Edited 2016-07-31 07:31)

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.

P#26217 2016-07-31 12:14 ( Edited 2016-07-31 16:14)

Do you plan to implement the Repetition Rule?

P#26501 2016-08-04 22:30 ( Edited 2016-08-05 02:30)

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.

P#26574 2016-08-06 09:52 ( Edited 2016-08-06 13:52)

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.

P#26575 2016-08-06 10:38 ( Edited 2016-08-06 14:38)

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.

P#26805 2016-08-12 13:57 ( Edited 2016-08-12 17:57)

[Please log in to post a comment]