KGS Leben: On Hold!

Due to a career-related change of priorities occurring in the second half of this year, I have put KGS Leben on hold temporarily – I do not have time to work on it. (In all honesty, it has been quite a while since I have had time!)

For the time being, I recommend that interested Go players take a gander at Ilya Kirillov’s extremely exciting Go Universe project or dive into my KGS Leben source code and build whatever they want – I will gladly answer questions, merge pull-requests and patches and help when I have time.

KGS Leben: Autumn Update

Here, in the Northern hemisphere, Summer has rolled past and it is Autumn once again. The leaves are turning on the trees, the wind has picked up, the temperatures have plummeted, the weather in the Alps is cold and wet and Federweiße and every variety of Kürbis adorn the shelves in the German supermarkets.

I have finally found time to write gratuitous code and I even played a whole game of Go, yesterday!

I have committed to KGS Leben twice in the last week. Here follow the highlights.

Sound Cues

I was not too surprised by the clamour for clicks and beeps. I did not intend on implementing them, yet, but recording and integrating sounds seemed like a creative way to resume work on the project and they were clearly desired by players so here they are.

This click was recorded, manually, and retouched in Audacity to remove the noise of my desktop microphone, fade it in and out and clip it so that it feels synchronised with the board when in use.

The pass bell was synthesised using a script in Audacity that implemented the work of Jean-Claude Risset.

Both of these sound cues should be played in all supported browsers, now, although Internet Explorer will play them with the obsolete HTML 5 Audio object instead of the draft Web Audio API published by the W3C and implemented by nearly all other browsers of import. In that case, concurrent instances of the same sound cue will be culled – this might be noticeable in blitz games.

Unit Testing

I have added some unit tests for domain-models such as the game-position and game-tree models and I intend to add many, many more. I know I should have done this a long time ago because development is always smoother when one possesses ability to automatically test not only existing code but changes and new code too.

To write the unit tests, I have used Mocha.js. It works acceptably well, in general, and is actually quite good for JavaScript. In my development environment, I can even attach to the Node.js debugger and step through my code, using source-maps so that I can work with the original TypeScript sources. Development for the Browser is almost becoming civilised!

Microsoft Internet Explorer

The player-panels are no longer a complete dog’s breakfast in Microsoft’s quirky browser and several other odd glitches have been fixed. I have tested under MSIE 11 and under MS Edge and both appear to work.

The list of tested browsers now includes Firefox, Chrome, Internet Explorer 11 and Edge. Opera and Safari (desktop, not mobile) should be supported but I have not tested under them. Internet Explorer 10 might be usable – I will probably test it at some point, if only for amusement purposes.

Ko Centres marked on the Board


The picture on the right says all that needs saying.

Behind the scenes, both the last-move marker and the Ko marker are now part of the game-position schema, making it incredibly easy to cover them in the unit tests for that model.

I also re-wrote the way that Ko is detected – the new implementation is much cheaper than the old one which relied on comparing positions in the active branch of the game tree.

The server implements the Ko-rule but it also necessary to implement it on the client in order to draw the marker and to avoid sending illegal moves to the server only to have them rejected.

Pass, Resign and Done Buttons

Prompted by feedback, I went searching for these three buttons and discovered that they were suffering from some sizing problems and they were completely hidden in Internet Explorer. These issues are now fixed. I have also tested them and they work as expected.

Here are the pass and resign buttons when the player-panels are positioned above and below the board:

This slideshow requires JavaScript.

When it is one’s opponent’s turn to move, the pass button is disabled. Clicking either button shows two secondary buttons. Clicking the second of these, the colourful one, will confirm the action, playing a pass-move or resigning the game. Clicking the other, or anywhere else for that matter, will cancel the action.

Here are the buttons when the player-panels are positioned on the left- and right-hand-sides of the board.

This slideshow requires JavaScript.

In this set of screenshots, you can also see the done button. During the scoring phase, the pass button morphs into the done button – a logical evolution.

KGS Leben is Open Source

Visit GitHub for the source code, along with instructions for building, testing and hosting the application. Features requests and bug reports may be submitted to the GitHub issue tracker for the project and open discussion can be found here, in the comments section, or in the Life in 19×19 thread related to the project. All project artefacts are released under the MIT License.

KGS Leben: Auto-Match

Earlier this afternoon, with my development environment still open and my code yet uncommitted, I connected to the live KGS server with one of my own ranked accounts and played the first real games ever to be played via KGS Leben. Games against other humans!

2016-05-31 hyaumet vs. Xharlie
hyaumet (5 kyu) vs. Xharlie (6 kyu, me)

I have reached a major milestone: all the use-cases required to play a complete game of Go (and those required to join the automatic match-making queue) are implemented, operational and stable enough for me to set aside my test accounts and play with a real one!

After playing several games, I joined a game between Imnot7d (7 dan) and Dom (6 dan) as a spectator and took some screenshots to show off the visible aspects of my work since my last post. I will upload a video showing the client in action as soon as I clean up a few rough edges that became apparent during today’s testing session but, for now, enjoy the pictures!

Firstly, by popular demand, I present markers on the most recently placed stone on the Go board:

Here is a picture of the board during the scoring phase:

Imnot7d (7 dan) vs. Dom (6 dan)
moku” markers showing territory and dead stones that were not removed during play during the scoring phase of a game between Imnot7d (7 dan) and Dom (6 dan)

Here is a picture of the score-summary section that appears in the sidebar:

Imnot7d (7 dan) vs. Dom (6 dan)
The score-summary table is updated dynamically during the scoring phase and also visible after the result has been finalised

The score-summary table draws some inspiration from the the dialogue box that the Java client, Cgoban, displays after the result has been finalised except, unlike the latter, my score-summary table is visible from the moment scoring begins and remains visible thereafter. I have also tabulated the data for readability and indulged in a little innovation. Let me state my case…

All the client software I have used to play Go on the Internet, when it does give the user a score break-down, adds the number of stones captured during play to the number left for dead on the board and marked as such during the scoring phase. A single tally of ‘captures‘ is presented to the user. This does not represent the way I count in my head.

When I count the game, mentally, I count territory and dead-stones together and add previously removed prisoners and constants such as komi or reverse-komi afterwards. For me, the final result of the game is important because it lets me know how accurately I did this and that feedback helps me get better at counting and, hopefully, stronger as a player.

In my score-summary, I have broken the player’s scores down to a more granular level, displaying separate counts for prisoners, being stones captured and removed from the board during play, and captures, being those remaining on the board at the end and marked as dead during scoring. I admit that the terminology needs some work but I think the feature will be very useful to players, like me, who want to know how close their mental counts came to the facts and where they went wrong in their assessment.

To the previously shown player-panels, I added buttons to pass and resign and, to the home view, buttons to join the auto-match queue. Joining incoming challenges has been doable for quite some time, as previously demonstrated and games started from incoming challenges can also be played to completion, naturally.

KGS Leben: Player Panels

I have finished working on the player-panels for KGS Leben, tweaking the automatic layout algorithm, polishing the seven-segment LCD clock’s design and adding elements to display capture counts, komi and user information.

Here are a couple of screenshots that I captured while spectating live games in the E.G.R.

2016-05-15 Player Panels - Away Landscape Canadian

In landscape orientation, the player-panels are displayed on the left and right sides of the game board. When spectating, the away panel (pictured above) belongs to the stronger of the two players, or the white player in the case that the players are of equal rank. When you are a player in the game, this panel will always belong to your opponent. Esquire55 (2 dan), playing white, must play twenty-two moves before the end of his rather short Canadian overtime period. White has not captured any of their opponent’s stones and is only receiving a half-point komi.

2016-05-15 Player Panels - Home Portrait Main

In portrait orientation, the player-panels are displayed as horizontal strips along the top and bottom edges of the board. This is a screenshot from a different game, showing the home panel. TOKKURI (2 dan), black, has captured two stones and has not yet entered overtime.

KGS Leben: Boards, Players & Clocks

I spent the last several days experimenting with KGS Leben‘s game area – the space that will hold the Go board, clocks, prisoner counts and more. At the start, I wasn’t sure where I was heading or where I would end up but something materialised, nevertheless, and I am immensely satisfied with it.

I divided the space into three areas: one for the board, one for the ‘away‘ player and one for the ‘home‘ player – thus named because, when spectating a game, neither of these may be the current user.

The two player-panels currently host the player’s clock and will show prisoner counts and other vital elements in the future. When one of the players is the current user, their panel will provide them with buttons including pass, resign and undo. Otherwise, the space will show the player’s identity: their name and avatar.

The layout adjusts according to the available screen real-estate, showing the away player’s panel above or to the left of the board and the home player’s panel below or to the right. The decision is made to maximise the size of the Goban, arguably the most important thing on the screen.

2016-05-05 Byo-Yomi Clock Feature
13×13 board at 2560×1440

The Goban itself is restricted in size so that it can never grow larger than a real-life specimen. This ensures that a nines board never grows so large that the stones appear like draughts-men! The user can always use their browser’s zoom-feature to bend this rule.

After settling on a design I implemented the game clocks. I began by using SVG graphics to make a simulacrum of my nice and chunky Chronos chess clock and, when that was operational, I began to extemporise…

This slideshow requires JavaScript.

A clear, readable game clock is crucially important and I think that this design satisfies that requirement with aplomb. Besides, if it looks this pretty after one quick iteration, it will be truly beautiful on release day!

KGS Leben Announced

KGS Leben is a prototype that will become a full-featured interface for the KGS Go Server. It is a web application and will simply run in a standards-compliant web browser, without the need to download or install any software or runtimes.

After one month of experimentation, exploration, trial, error, frustration, success, water, beer and tea, the software is capable of joining open game challenges, negotiating a game proposal with the challenger, playing moves on a Go board, spectating games being played by others, watching demonstration boards and chatting in rooms and channels. Furthermore, I have succeeded in the most difficult task demanded by all new software projects: I have chosen a name! The name comes from the German word for life „das Leben

None of the features exhibited in the preview video are really complete, yet, because I chose to spend the last month confronting risks that I identified when I began wrangling with the idea and tackling the most technically challenging facets of the project.

I hope to achieve rapid progress, now that the foundation has been cast.