A little over a month ago, WMS announced his JSON API for the KGS Go Server. I initially wanted to use it to create a modern desktop client for KGS but, after playing with it for a while, I finally decided to embrace the browser and began working on an HTML5 and Javascript powered client. One month has past and I have finally reached a point where I am prepared to commit to the project.

It will eventually be open-source, under the MIT license but, for now, it is very much a prototype. I spent the last month working on technically challenging and risky parts of the project and not trying to create a feature-complete application. Nevertheless, I have put up a video on YouTube showing the prototype as it is, today.

The intention behind the video is to serve as a beginning: my creation will only grow, from here. I do not want to build anything without the input of the community so I will be publishing regular updates on my progress, henceforth. I also welcome constructive comments on what I am building.

In its current state, the client is capable of joining open challenges, negotiating a game proposal and playing stones in the game when it begins. It can join any channel or room and chat therein and join other people's games and demonstration boards as a spectator.

https://youtu.be/m8yT6qrBSU4

P.S.: Please forgive the amateur nature of the video and the South African accent. I'm a programmer, not a P.R. guru.

That looks quite awesome already, respect!

How will this, being “browser-powered”, work in the end? Does this require some Web site as an entry page? Or will it be a browser plugin? (I know close to nothing about coding, so pls forgive me if the answer should be obvious.)

_________________
“The only difference between me and a madman is that I’m not mad.” — Salvador Dali ★ Play a slooooow correspondence game with me on OGS?

I was confused when you said for demonstration games, you can navigate the move tree. I expected to see a game tree UI somewhere, but I only see that in the java client, not the html one. Maybe you meant the html client can handle variations internally, but the UI part isn't there yet?

Looks fantastic! Thanks, Stephen, for doing this work. I'll try to keep on top of any bugs in the JSON webapp that you find.

Yay!

I'm glad someone took up the challenge. It's a promising start! Please let us know when you decide to release the code; I'd love to take a look.

Wow! That looks amazing! Maybe someday I can play on KGS again without soiling my computer with Java.

Initial thoughts are it looks great. Keep up the good work and be sure to post updates here. Being able to play on any device without the need for Java would be great.

Thank you for all the positivity.

@Bonobo: At the moment, the code isn't really useful to non developers because you need to host the JSON End-point and that requires you to set up Things. In the end, however, you will require nothing other than a proper web browser - Chrome, Firefox, I.E., Edge, proper Safari or Opera, others if you're lucky. When you navigate to the URL at which the application will be hosted, you will be presented with the sign-in screen that is featured at the very beginning of the video.

@yoyoma: Yes, what I meant was that the browser-based client can follow along as the Java client jumps about in the game tree. Sorry for being ambiguous. This is actually not trivial and seeing it work so smoothly is a sign that the internal game tree and position models are capable of unrolling moves and replaying moves to reproduce a position. I probably didn't need to make a show of it but I spent so long testing and tweaking it, I couldn't help myself.



@wms: Thanks. And thanks for the rapid turn-around time on bugs, so far.

@jeromie: If there's anything you wish to see, just shout and I'll consider posting whole code files or snippets. The project, at the moment, is still moving too quickly for me to punt the code, I feel. When it has settled down a bit more, I will write a developer's readme describing the build system and how to set up a dev. environment, a brief overview of the project's structure and patterns and start shouting loudly. (I guess contributor's guides and other such things will need to be enacted...)

@yishn: Oracle's Java Runtime leaves a bad taste in my mouth, too - ever since the whole Ask Toolbar debacle. Luckily, you don't need it. You can use Zulu which is a build of OpenJRE and can be "xcopy" deployed - that is, extracted from a ZIP file and simply plonked into a folder. By serendipitous chance, I actually wrote a guide describing precisely how to do that, a little over a month ago: https://probabilism.wordpress.com/2016/ ... al-damage/

This looks great; I can't wait to try it out. One thing which would be really useful even at this early stage is a mark on the last-played stone.

Yes; very important feature.

Hi Charlie,

Please use a circle for the current move marker (like IGS clients: gIgo, Panda, etc.),
or, at least provide an option for the user to choose among a circle, square, triangle, etc. Thanks.

already a great looking browser client to me plus it has the features I missed in KGS Android client. I don't mind to play both on android (since I've paid for it) and browser client.

to me they bth serve different purposes. I've long wanting to do something similar but lack the expertise and time to explore further or help on similar projects

Good move Charlie!

Heh. I was wondering what the first feature-request would be. At least some of the voices in my head had bet hard imaginary cash on it being a last-move marker.

I like the OGS ones but I find them to be a little too severe. It makes the white stones look almost like black stones. I was planning to try something similar but slightly more subtle. What do you think about it?

Now that I have finished the technical foundation and answered all the major questions in my head, I am trying to follow a shortest-path-to-usefulness strategy. After that, I will probably set up a UserVoice to provide some direction. I will never *promise* to implement everyone's personal whims but I also want to give players options. Options and sensible defaults.

A circular marker on a circular object could shadow over the object you are trying to highlight, though personally it hasn't bothered me. If going with something different maybe use a marker shape that is different and it should be fine. If OGS's circle marker is too harsh try a square or triangle. You could also make the marker a color other than black or white such as red or green. If changing colors I would research exactly what color combos would work best for someone with colorblindness so they can use the app with ease as well. (The thought occurred to me when thinking about the color patterns. I personally have no knowledge or expertise in the subject and no idea if certain colors are unintelligible together or not.)

_________________
I'm thinking...

If I may be so bold: Take a look at Sabaki for inspiration. It uses a small disc as the last move marker and I find it very nice. (Of course, since I made it. )

I'm travelling, tomorrow evening and over the weekend, and have five solid hours of German lessons in the morning so this is probably where my progress for the week grinds to a halt. In lieu of actually doing something useful - here's a link to some words about the game-area and some pictures showing off the SVG-powered byo-yomi clocks that I wrote, today: https://probabilism.wordpress.com/2016/ ... rs-clocks/

Es sieht sehr gut aus, oder?

Allerdings!

_________________
“The only difference between me and a madman is that I’m not mad.” — Salvador Dali ★ Play a slooooow correspondence game with me on OGS?

Cool! Personally, I am struggling to make the KGS json client work for me as it seems to require the http POST and GET requests to be in sequence and there's no guarantee they will be once they go over a network. The only way to make it work is to do the http requests on the same host as the KGS json client and sending the results over a websocket connection.

Is there any particular reason why the KGS json client doesn't just implement javax.websocket.Endpoint and offer a websocket connection ? This would seems to me to make more sense when converting to from a tcp/ip connection and doesn't require buffering packets received from the tcp/ip connection for http GET requests to poll. Alternatively, the downstream packets could be numbered to prevent loss or out of sequence results.

Thank you for your selfless work, regardless of the outcome (althought I hope the outcome will be worth your investment!)

I have to say that I don't find the clock readable at all. I would do away with the black bars or at least make them much less visible. Having two "strong" colors that contrast with the background fighting for attention makes the value of the clock quite hard to read for me.

_________________
La victoire est un hasard, la défaite une nécessité.

Exciting to hear about this project! Thanks!

Do you have any plans to open-source your work? I think there are a lot of developers that would be interested in contributing toward making this happen.