cmdrdats / igoki Goto Github PK

Build a small widget for effectively showing the current branch and nearby branching. Need to come up with a fairly clever way of visualizing it so that you get decent information without needing to interact with the widget. Scrollbars will be a pain. It can even draw stuff on the board... (like next move indication, or branch lines?)

if there are more black stones than white, white starts - else black.

It's quite painful to setup the grid because of the slow refresh rate...

Perhaps some red/green icon somewhere, so that you can see if the app is waiting for the physical board state to match before accepting new moves.

Also allow playing out branches by mouse clicking. This will immediately mark the stones as 'red' because it will differ from the actual board, but would be nice for quickly analysing positions.

This can probably be done by a) speeding up the camera input and b) storing each board snapshot along the way and when a stable state is reached, diff the board snapshots to discover in which order the stones were likely placed, given the current state of the board and the previous stable state of the board.

Figure out how to mesh an old 'reference' with an updated reference on every played move, this way accounting for variances as the game progresses

They just create a stack of noise, and chances are that you're not interested in the moves that long ago anyhow.

Mark board as 'dirty' so that players can see the diff and it doesn't automatically 'play' the next stone until the board matches the current state of the game

Light arrows pointing from the parent node to all sibling branches - green arrow for current branch, blue for alternate branches.

Darker (more emphasis) arrows pointing to next nodes - green if it's the next node in the :current-branch-path.

Especially important with the inference so that multiple false plays are automatically rolled back. Also nicer for when you want to explore a previous position, without using the arrow buttons or painstakingly removing only the last played stone

Oh dear.

Implement this list, in particular:

 "AR" :arrow                                              ; 'from:to' in value
   "CR" :circle
   "DD" :grayout
   "LB" :label                                              ; 'point:label'
   "LN" :line                                               ; 'from:to'
   "MA" :mark                                               ; with X
   "SL" :selected
   "SQ" :square
   "TR" :triangle
   "TB" :territory-black
   "TW" :territory-white

Try find other possible stable points and look for a possible game sequence where both sides can work.

Implement some of the popular time control settings (simple, fischer, byo-yomi, canadian), to assist in live game timing.

Included in this task is to write the timings out into SGF format.

This shouldn't rely on the camera picking up the move, since it wastes some time (we can also add it as a feature later). Rather support hitting a key on the keyboard and down the line we can support hitting a button on the arduino extension, when that is implemented.

The grid is misleading due to perspective - there's no point in trying to make the grid match up. Might as well rather take it away and replace it with the current size text in the middle of the 4 corner points instead.

It runs at pretty much 200% load all the time, which isn't ideal - seen in a 200+ move 19x19 game

Also, this was in sim mode - need to check if it's as severe in normal camera capture mode.

Back can go to negative move numbers
Forward messes up if you play a move in between, even at the same position.

the problem is that back and forward only interact with the move number - which is fine for holding on to the current branch - but forward should go to next move only if there is another sub-branch - update the :current-branch-path if it's bigger than the current move.

Back should stop at zero, but shouldn't need to interact with the :current-branch-path, since it should hold onto the latest branch you were in.

Esp. important when there are multiple branches at a node - show each of the next possible moves that could be made so that, when played, the game traverses those branches.

igoki is well suited to become the 'referee' in hidden move Go:

http://senseis.xmp.net/?HiddenMoveGo

as noBiggerFish at Reddit summarises:

Each player inputs their moves beforehand, the computer deals with clashes however has been chosen, ignoring both stones or alerting the players. During the game it makes a sound if any hidden move is revealed and displays it on the screen.

• https://www.reddit.com/r/baduk/comments/3q50kd/igoki_bridge_the_gap_between_playing_go_on_a/cwd7bw5

When a player makes a move on an online game, TTS the coordinates, so that you can place the stone on the physical board without looking at the screen. This is the simplest way to close the feedback loop.

Have the UI as a web view and start up a local 'server' - see #41

If there's a single white and a single black stone added in quick succession, it might not have debounced yet, but it should be able to handle the moves because the turn order is known.

Currently it's just a toolkit/beep - which is kinda annoying. Would be nice to have sounds for move submit (a subdued shh), playing (a click) or undo (swish)

When you move back in history (left/right arrows) and you play a stone in a previously unplayed branch, add a branch and start recording down that branch instead

Start off with single page Kifu export (with comments for ko captures), from the current position

Can tackle pretty exporting of branche, comments and markup as separate features

For development without a physical board/camera - on the initial screen, use the 's' key to start a new frame that handles mouse input to pretty much draw a known 'top-view' board on an OpenCV Mat. Then use the mouse to place or remove stones. This should feed into the camera atom directly so that the same underlying stuff happens.

Just check that the same camera loop happens so that debouncing works correctly.

This will make the user interface a whole lot easier to develop for, since you won't need to reinvent simple stuff, like input boxes and buttons - especially important when we get to heavier UI requirements.

When the app starts up, fire up a local web server and automatically open up a browser (?) to the endpoint.

Treat each new browser as another 'guest' view - in the future, they can 'take a seat' as a player (can provide their name, rank and, optionally, their OGS details) - or they can simply be an observer/commentator, possibly with hidden commentary and branching analysis that can get included in the final SGF.. that kind of thing..

The arduino board will likely use a shift register for 19 x-axis LED's and a 'black' indicator and another shift register for the 19 y-axis LED's and a 'white' indicator.

Circuit diagram still needs designing, but that can happen in tandem. Primary constraint is that you'd want the wires for the x-axis and y-axis quite separate, since they will run in their own directions...

Pretty much only need to update the :player-turn.

The SGF loading code already exists, but once we can visualise and see branches it would be handy to have a way to load up a new SGF file (great for Go Problems.) and load it into the game state. This should be a fairly trivial thing to do, given that the current state is based on the internal SGF representation to start with.

Just load and use the 'igoki.game/reconstruct' function, mostly.

PS - create a new function for the JFileChooser in the ui namespace - there's a bit of a gotcha in that it has to create a new 'always on top' frame in order to work the second time (and not just load under and hang everything)

Currently, just shifting the points doesn't handle all situations well, particularly with heavier perspective angles. A better solution would be to place stones on the corners and then manually match the grid up to the centers of the stones (every other point should be relative to those).

Probably as a new resizable JFrame would be easiest?

When a move is currently unplayable, it simply logs messages out to stdout - rather update the context and show it on the UI so that you don't need to watch logs.

Implement the online-go API endpoints that will likely be used in igoki : http://docs.ogs.apiary.io/

Primarily the authentication and game ones - nearest use would be to get a game SGF, playing moves in games and handling notifications when moves are played in games.

Implement a proper 'delete' node function in the igoki.sgf namespace and use that for undoing. It should clean up branches where possible.

+,- to make the sampling size larger or smaller
[, ] to raise and lower the amount of colour for pieces (hopefully allowing for subtle shadows to not affect the game as much)

Currently it uses a 'easy' vector format :

[:a :b [:c [:d :g] [:h :i]] [:e :f]]

While this is optimized in the sense of efficiency, readability and exporting, it isn't great from a manipulation point of view.

A better solution would to treat each node as if the successive step has multiple branches always - so:

{:move :a
 :branches [{:move :b 
             :branches [{:move :c :branches [{:move :d :branches [{:move :g}]} 
                                             {:move :h :branches [{:move :i}]}]}
                        {:move :e :branches [{:move :f}]}]}]}

Would be the direct equivalent.

This means that sgf writing needs to add the parens only for the nodes that have >1 branches - but this is strictly an optimization, really.

The current-path would then represent each choice down every node, as opposed to the currently compact form. ie - in the vector format, to get to :i, the path was [2 2], with move-count 4 - where the new method only requires a path from root branches - [0 0 1 0] (get-in root [:branches 0 :branches 0 :branches 1 :branches 0]) and no move count required (since you always get back the node.

Simply step the movenumber up and select the branch in the current-branch-path instead.

Find the threshold in the diffed image where shadows disappear and use it to cull out shadows?

Possilities:

Named opening points (san-san, etc)
Attach/Tsuke
Hane
x-point extensions
cap?
Ko
Ko threat - (if non-trivial ko is on board..)?
Atari
Cross-cut
etc...

http://senseis.xmp.net/?GoTerms

Possibly also recognize the forming of common patterns - bamboo, table, empty triangle?

Thanks recursive update-in.

Setup a transformation matrix against the flattened (perspective corrected board)
Continually find the major 'interesting points'
If the interesting points subtly shift, adjust the transformation matrix to compensate.
This should take care of the cases where the board gets slightly turned or moved as play progresses.