BesoGo: yet another web-based SGF editor

Right, I don’t mean to suggest that it’s more difficult if there is no stone on the location already. My interface already captures the clicks by the point location, and I envision that shift-clicking repeatedly on a location should cycle through all of the moves at that location (in some order).

I’m not asking about the difficulty of implementing this, since it’s all rather straightforward once the exact desired behavior is understood. Instead, I’m asking about what should be the designed behavior of “jump to move” should there happen to be multiple moves in the tree at the selected location. Should there be no moves at the location, then perhaps the jump should just do nothing. If there is only one move at the selected location in the entire tree, then that move should be found and jumped to.

My point in my previous post is that I think that “jump to move” should somehow to search over moves both before, after, and on different variations of the current location in the tree, but determining the priority between multiple moves is an interface design decision.

I think it is also useful to look forward, since some users might want to jump forward to see when a particular point is eventually played.

Imagine that you’re looking at a game record where early on both players have decided to leave a vital point unfilled in order to play elsewhere. Hence a jump forward to the move on that vital point could be useful, if you were curious about seeing when and which player eventually filled that point.

I’ve been experimenting with some CSS-based themes:

Just some basic flat-color themes for now, but textured and “realistic” graphics are in the plan for further work.

1 Like

Experimental photo-realistic board rendering:



W: rsun (4d), B: integer (2d)

1 Like

(I moved the following part of the discussion from Smallest Groups With Two Eyes to this thread, seems better)

Wow, that looks purdy kewl, @yebellz! Though … something … dunno, something there doesn’t seem right …could it be the drop shadows? Or is it there some difference in sharpness between board and stones? The exact positioning?

Another question, what do you think: how many different shell stone images would be enough to make it look convincing? Ideally, of course, 180 :smiley: I just purchased a “used” (played once) S&S set <happy> and when I find the time I might go and scan them.

And then again … moving in the diametrically opposite direction: sometimes I think it may all be just too much skeuomorphism … perhaps for digital/visual/pictorial communication of Go diagrams simple graphics are easier for the eye, less distracting … the Eidogo thingie definitely has the best contrast/colour combination, I think … when I look at all three, Eidogo gives me the most relaxed feeling, the least stress.

1 Like

Thanks for the kind words and thoughts! I agree that several things could probably still be tweaked a bit. I’m still going to keep playing with many of the details. Here’s what it looks like without shadows, which I felt seemed a bit flat, but perhaps I still haven’t gotten the shadows quite right.

Fuzzy positioning, and maybe even making the grid slightly rectangular like real boards (which is readily apparent if viewed from directly above) might improve things. Also, maybe color levels/saturation, sharpness differences, lack of perspective distortion… well, there are a lot of challenges to making a really convincing realistic go board. Maybe things are starting to get into the uncanny valley.

Maybe more stone textures would help too. Currently, there are 4 black stones and 11 white stones, all courtesy of another open (CC-BY-SA) project, go-assets. Also, the board image is from jgoboard (CC-BY-NC). It’s always helpful to have more people making more such images freely available.

Regarding whether it’s too much skeumorphish… yeah, I’m not too sure if I absolutely prefer realistic rendering. I worked on it since I thought it would be kind of a neat feature, but I also really like a simple, abstract depiction of the board, such as with just plain flat colors like this, or alternatively adding just a simple outline like this.

By the way, with BesoGo, the board/stone colors are specified in CSS, making it very easy for the webmaster to customize the theme (a power user could even play with changing the CSS defined colors using the browser console). One could also easily ripoff the EidoGo color scheme and stone graphics, while getting the added benefit of avoiding the limitations, bugs and security vulnerabilities in EidoGo.

1 Like

@trohde, just for fun, I created an alternate theme that you might find “relaxing”

The exact board color scheme is directly lifted from EidoGo. I didn’t use their stone graphics, which have a slight gradient, but only low-res images were available. However, the flat color stones that I use have colors based on those images.

If you are curious about some other themes, you can probably guess the names from this:


Oh wow, @yebellz, that’s beau-ti-ful!

I’ve made a few minor changes to this project since the last time I posted about it

  1. Changed the license to MIT (although one can still use AGPL if they prefer)
  2. The code is now released on npm, thanks to the help of another GitHub user. See BesoGo on npm and this GitHub issue discussion
  3. Added the shift+click to jump to particular move as suggested by @Pempu
  4. Added tools for changing promoting/demoting the order of variations

I have not really worked on this in a long while, but I think I want to get back to it.
Here are some thoughts for my ToDo list:

  1. Update the code to modern javascript practices. Specifically, packing things into a proper module (I need to learn how to do this)
  2. Refactor colors to reside fully in the CSS, which will make full color customization much easier
  3. Add a problem mode widget for presenting go problems
  4. Work on something that could be cleanly integrated into these forums, in order to support embedded SGF files

Regarding the last ToDo item:
We used to have EidoGo as a plugin here (on these forums) for directly embedding diagrams, SGF files, problems, but that no longer works and was disabled. Would there be interest and support to use BesoGo as a replacement?


I don’t care if it’s an alpha… There is no excuse for releasing a version 0.0.0 :persevere:

As long as it doesn’t break any forum features as eidogo ended up doing, that would be great :heart:


What’s wrong with starting the absolute count at all zeros?

By the way, the latest “release” is now “0.0.2-alpha”

At the end of the day, numbering and naming of releases are all a bit arbitrary.


I was trying to embed OGS goban in the forum, but got distracted on the way.


Obviously nothing lol you can name it how you like… Just to me any change at all from initial document creation would be grounds for a 0.0.1 release lol so in my head 0.0.0 would just be a bunch of empty file stubs and thus couldn’t be released

This is really nice board.
It is absolutely relaxing!


For example, here is what a minimal SGF viewer widget might look like (just a screenshot)

The theme, color-template, look and feel, orientation, tool panels, options, etc. could all be tweaked.


I think coordinates would be a must, or if you want it as an option at least default on for forum use.


Yep, no problem. My widget supports several and can be configured to make coordinates on (of various styles) the default.

The last one is a corner-relative system that I discussed here: Tournament Shorthand?


Looks awesome already, but the brightness of White (in these screenshots) hurts my eyes, I think I’d prefer it much if it were dimmed down a bit.

<edit> Looking at your “realistic rendering” though, it looks BEAU-TI-FUL! And I realize I said that already in 2016 :roll_eyes: </edit>