Currently isSuicide will return true if you are filling in a gap that should result in a capture rather than suicide. eg:

W W B -
W - W B
B W B -
- B - -

Black cannot currently play on (1,1). It should be a legal move that results in the capture of all the white stones.

Modules should be named with lower case or snakeCase if more than one word.

Class names should be capitalised

If...else should be bracketed

Before placing a stone, check whether it would be a suicide.

Assuming even individual stones are part of a group.
Loop through each stone in a group and if it has no liberties
i.e. no empty spaces surrounding it then it is captured.

https://en.m.wikipedia.org/wiki/Rules_of_go#Ko

Ko basically describes a situation where the board returns back to its previous state in the move before. Could be reasonably easy to implement with a history.

@Xephz Thorsten has uploaded a peer review template on Moodle we need to use to describe our contributions to the project.

We need to use this as he's going to process it with python (of course).

My student id is psxmpt, what's yours?

I was wondering whether we should use the return key for playing whitestones?

K_RETURN

It just feels a bit clearer and more natural than delete to me?

Minor point which is easy to fix, but the font directory is currently hardcoded. This does not work across different OSes. The .ttf should be included with the game and loaded from there.

• Left Player - Instance of the Player Class
• Right Player - Instance of the Player Class (Prevents there being lots of players initiated)

## Methods

• init()
• calculateScore()

For players who don't know how to play you could step through a really simple game and show tooltips for what's going on.

A single or multiple stones of the same colour connected non-diagonally.

• colour
• list / set of coordinates as tuples
• isVirtual? - Boolean if the group is temporary
• id - incremented from groups.length

Methods

• init(colour, coordinate)
• isInGroup? (coordinate) -> Boolean
• mergeGroup (group)
• add group.coordinates to self.coordinates
• is captured? (if every element of the group has no surrounding spaces)

Board controls the game state, it places stones, removes stones, checks for suicide, checks for empty spaces, checks if a play is on the board, check for contents of square, check for group membership, update group ids.

• size = int
• groups = []
• matrix = []

Methods

• placeStone
• getGroup(coordinates) -> group.Id, colour
• isSuicide?(coordinate)-> Boolean
• isEmpty?(coordinate) -> Boolean
• offBoard?(coordinate) -> Boolean
• playable?(coordinate) -> Boolean
• printBoard
• deleteGroup

We could do with a start menu that allows you to select the Board size. Probably best implemented as a UImessage that exists in a main.py (which replaces test.py) and calls matches up. This would also probably need to implement a menu class which can be recreated by match on completion.

As part of our hand in we need to provide a description file explaining the game <= 2 pages. I think in this we should also be including how the code is structured?

We should probably think about defining the structure of this at some point soon, perhaps just with headers and bullets to start?

I think it would be good to try and keep everything in this repository if possible and use git to manage versioning.

Board UI class, draws the board and board lines.

Variables

• Divisor - holds the board size plus one.
• Background - the board's background shape
• Origin - (0,0) as pixels on the grid
• Coordinates - list of lists with pixel rules for coordinates on the board
• Interval - the step between lines,based on the board by size and grid size
• Line width - sets the line width of the grid

Methods

• init()
  self.grid = Board.size

• create()
  Draws the board and board lines.

• getBoardUICoords(self, coordinates)
  Returns pixel tuple for a given set of coordinates.

Games of go should have a time limit that counts down for each player and pauses when the game switches to the other player.

Should be able to increment time for each player.

So I can probably work through the UI over the next few days but I think it would probably good to make some decisions about how all the logic interfaces with the UI and vice versa?

My general thought is that the UI does no logic, UI classes are responsible for:

• handling user input
• drawing elements to the screen to represent the match / board state (e.g. timers, current player, groups etc.)
• displaying messages (e.g. can't go that would be suicide, Ko! etc.)
• binding ui logic to game logic (e.g. ensuring that 0,0 in the UI corresponds to (0,0) in data)

UI classes will be initialised and called within game logic classes. E.g when a match is initialised, then it will create the game in data but also build the UI

What are your thoughts @Xephz ?

I think the current method of having virtual classes is a bit hacky and can be brought in line with the method used for potential boards (using deepcopy). This will be cleaner.

Stone Ui, displays stone sprites, moves stones around the game board, places stones on the board

Variables

• colour
• coordinates
• isPlaced: Boolean
• isPlayable: Boolean
• diameter
• BoardUi

Methods

• show () - shows the stone. if is placed is false. Show at lower opacity. If true show at full opacity

• Move(self, mx, my) - If the stone has not been placed then move the stones coordinates by mx, my based on user input.

• Place() - if group.isplayable set isPlayable to true and a valid control is given then set the stones coordinates to coordinates and set isPlaced to true

So that we can see what's going on with the board, we're going to need to design the visual look / feel of the game. Perhaps we should start with a simple wireframe before sketching up a high fidelity design.

We also need to work out which visual elements need to be included e.g:

• Stones
• Stone placement indicator - e.g. 'ghost stone or crosshairs'
• Last played stone
• Board
• Prisoner pots
• Timers
• Pass button
• Resign button
• Score card / win state

Represents a single player.

Variables

Colour - The character representing the players stones.
Prisoners - The number of pieces the player has captured
Time - indicates the ammount of time in seconds that the player has remaining.
Ingame? - potentially if we want to allow for many players we may need to keep track of who is still in the game, although this may be better stored in the game class.

Methods

placeStone(self, board, coordinate): - This will return a boolean to indicate if the stone was placed.
The process will be along the lines of:
-Check move is playable.
-Check for Ko
-Check for merges
-Check for captures - and adjust for prisoners.
hasTime() - returns a boolean indicating if the player is out of time, may not be needed
resign()? - Again may be better stored in the game class. Will reexamine once I start implementing.

I expect that there are more methods that will need to be added to this class.

It would be nice to add UI messages for KO and no possible moves.

As it seems we're doing pretty well using Issues to track todos and handle discussion, perhaps we should delete the 'Project' view with to do, doing, done boards. It feels superfluous and a distraction?

Help to understand what's going on.

Calculating the territory score at the end is more complicated than I had first imagined. It will take a little bit of research and time for me to sort.

Variables

• isCurrent: Boolean
• colour
• time

It would be helpful to implement Error messages / console logs in the event of errors so the play can know why there was a problem.

Massive multi player mode

Cats vs dolphins mode

Timer fun: getting more time with each play, if you capture a big group you lose the equivalent in time, or time speeds up or slows down as the game progresses

We want to be able to display messages during the game to a player, when the player clicks on the message it should disappear and they should be able to resume play.

One option would be to have a list of messages, when a state is triggered, create a message and add to the list. When the user clicks on the message fire messages.remove(message) removing its reference.

Messages

State: isSuicide
Message: Can't play there...that would be suicide!!!
Action: Remove Message

State: Ko
Message: Can't play...that's Ko..we might end up in a loop.
Action: Remove Message

State: noPlayableMoves
Message: There is nowhere to go. You are completely surrounded.
Action:

new_game_button

State: gameEnd
Message: Another Game?.
Action: Should create a new match and launch the matchloop

quit_button

State: gameEnd
Message: Quit.
Action: Should return to the 'Start Screen'

When attempting to play a stone, first check if the location is empty.

Variables

players[] - a list of the players in the match, given as a list so as to not limit the number of players when we look at experimenting with game mechanics.
currentPlayer - an intiger indicating the index in the players list of whose turn it is.
board - the board on which the match is being played
previousBoard - a matrix representing the previous state, used for indentifying ko
currentboard - tracked just to pass to previous board

Methods

playTurn() - The main loop in which the process a turn is evaluated
matchLoop()

I think it would probably make sense to merge the board and group branches into some kind of core game logic branch, rather than have separate branches for each class. Thoughts?

When a player is choosing where to place a stone their stone should snap to grid positions.

Button UI, builds buttons, handles button actions in response to button state

Variables

• text - String for the button's text
• parent - parent Object
• background -
• border
• textcolour
• font
• states - hover, active
• action
• width
• height
• x, y

Methods

• init
• onclick()
• onhover()

Sound is important in Go, the placing of stones is encouraged to make a 'click' noise when playing for real and so we should include sounds as part of GamePlay.

I'm going to create a UISounds class that:

• Inits a pygame.Mixer to load and playback different types of sounds.

stone_placed_sound = UISound(soundsDir)
stones_captured_sound = UISound(soundsDir)

Methods

• UISounds.update()
  Will select a random file from the given directory, create a Sound object and play it back.