Josekle Development

how would this work? not sure what “as long as it matters” means

1 Like

As long as there are only stones on the main diagonal (A1 to T19), stones can’t be placed above the diagonal.

1 Like

only stones meaning already placed as part of an ongoing guess? I guess it makes sense to force orientation, but I’d want a clear explanation in the message as any blocking of stones could be confusing

with no limits on the number of guesses, I feel like the rotation problem is less of an issue

Yes, it’s not about variations already in the tree. Just the current board position matters.

The discord screenshot Gooplet shared had someone asking about orientation. Visual hints could make that clear.

Even if correct answers are restricted to one canonical orientation (which could be nice but I’m not sure it’s necessary, it feels enough that we know which corner to guess in), I would prefer guesses to be allowed in both orientations, so that you’re not prevented from making a nice strategic guess just because it’s flipped incorrectly.


I think that we should adopt these “polite triangle” conventions for how joseki are oriented in the solution set. I believe the OJE follows these conventions with how the joseki tree is stored.

However, I don’t think that we should restrict inputs to follow the polite triangle conventions. As @antonTobi just mentioned, while I was typing, there could be strategic reasons to input a “flipped” joseki. When following the conventions, some joseki wind up more unbalanced toward one side or the other of the main diagonal, so sometimes one might want to input a flipped joseki to better probe.


That’s an interesting thought (it would be similar to allowing to write english words from right to left in Wordle).Then we’d have to add those different orientations to our joseki database once we’re preventing sequences that aren’t part of OJE.

We don’t need to mirror them in our dictionary. We can simply check all rotations and flips, which is efficient, since the checking for each orientation can quit immediately when it goes off tree, and if one orientation is found to match, we can skip checking the rest.


If restricting to one corner (something like a 12x12 square like we discussed recently), there are no rotations, so only two different orientations to check :slight_smile:


@Jon_Ko recently added a zoom feature, which obviates the need to restrict ourselves to a corner, while still providing a reduced view for convenience most of the time.

With a hypothetical 12x12 input area, someone still could start in another quadrant.

1 Like

But the zooming always goes to the same corner, right? :slight_smile:

Here’s my thinking: unless allowing the player to find the correct answer in any corner (which would open up some unnecessary complexity in how the feedback hints are given), it would be confusing to allow someone to keep guessing in the wrong corner.

There could be a message if you try to place your first stone in an incorrect quadrant, but with the zoomed in board this is actually not necessary, since there’s only one corner visible.


Curating or otherwise expanding the puzzle space is I think the hard thing were should think about more.

SGF uses letters a through s including i, for both row and column. 4-4 is pd
OJE uses letters (excluding I) for column, numbers for row. 4-4 is Q16
Besogo also uses SGF but the unofficial “extract moves” API that I am using returns numeric x,y. 4-4 is x=16,y=4.
Of course we can convert between these easily, but it raising some questions about how to manage this… between the pool of puzzles, the dictionary, and curation

Josekle puzzle pool right now is a list of lists Besogo coordinates, because that’s easiest to compare. My OJE scraper is converting from OJE to SGF and produces an SGF file. Which I load into Besogo and query using the “unofficial API” to compare to the input moves…

The scraper can re-run without hitting OGS and rebuild the SGF based on what I have saved already, and attach any information in OJE into the SGF. It also keeps node numbers, which will allow linking back to OJE on solving the daily puzzle. But curating the pool via SGF means reproducing it from OJE will suddenly become difficult, we would need to manage updates in the SGF somehow.

And of course, if eventually we want to “port” Josekle to OGS, it might make sense to keep it in mind…

So my thinking is this:

  • Canonical form of a puzzle in code would be OJE strings. We pick the daily puzzle from a list of OJE strings. If necessary, we can convert to SGF, but I don’t see the need (see last bullet)
  • Manual curation is done via collecting OJE nodes (numeric ID in URL) and adding them to a list
  • Dictionary is maintained in SGF form as mass dump of OJE, as much as possible to allow many joseki submissions
  • Communication through Besogo continues in the app code converting from OJE to unofficial API

The main goal is to avoid backing into any corner. I think this avoids it.
Also there is another twist which is I think I may have been scraping old OJE, not new… not that big a deal and easy to fix

Another option is to avoid manual curation at all. Maybe two versions:

  • hard Josekle, where any finished sequence in OJE (up to scraped data anyway) is a possible solution
  • normal Josekle, where only those up to some ??? number of moves are possible

It’s possible a handful of longer sequences could be manually curated and added to “normal” pool for variety


Ok, so this is going to be tangential, pedantic, and pointlessly convoluted, but you all know me well enough by now.

Let’s imagine that all of our joseki live within a 12x12 corner, and that by convention we orient them to prefer the polite triangle (as long as symmetry permits) and then the lower triangular region of board (as long as symmetry permits).

Hypothetically, perhaps even the following might be a joseki

Now suppose, someone wanted to enter a guess to probe L9 and L11, but they did not know or think to try the above joseki. However, suppose they did remember this other pretend joseki

Now, they might realize that they could rotate this joseki in order to probe L9 and L11


I think this all sounds great! I guess reviewing the already selected puzzles would rely on looking up the joseki in the OJE, but for adding new ones, one can just confirm that the ID code is unique. That’s nice!


Simply deactivate the intersections of the 3 other corners (like a 5x5 grid) should work enough to prevent them to play there.

I still like more use of a full board as a trunketed one (makes my imagination running better for direction and influences), emptyness has its proper value, but ok that’s me, not a big deal. (Zoom need 1 step only from full board to 12x12)

1 Like

Ah, yes, my “only moves on diagonal” is not the only way. E.g. black 3-4, white 4-4 attach, black hane 4-3 and we’re back to symmetry.


Do we treat OJE as the only source for our dictionary and possible solutions, or do we want to allow other (big) sources too?
If we find OJE is missing some josekis we want to use (as possible guess and maybe as possible solution), do we ask that OJE is updated and adjust the data (moves, links/IDs) or do we just add it from another source (and maybe link to that source)?

And curation of solutions could be done with a mix of automation and manual input. Automatically not only length could be considered, but number of branches too.

1 Like

Indeed, things would be different if variations in the center or along the side were included, but joseki dictionaries generally only include corner sequences. Even though there may be some “midgame joseki” (and if we really stretch the meaning of the word we could include standard endgame patterns like how to respond to a monkey jump), they are by nature even more situational than joseki in the opening: they rely on existing stones and can occur in different positions on the board.

Like this pattern which is common in all kinds of different orientations and phases of the game:

Checking not only rotations and flips, but also translations, sounds quite tedious both for the programmer (only some orientations make sense, and there will be gray areas) and for the player!

So it’s good that joseki in go have this nice property of being local to one corner, it makes josekle a much more viable game than it would be otherwise. To create a similar game for chess you’d probably just consider whole-board openings, which loses some of the charm.


What are some other big sources? I know about Sensei’s Library, but the information there is probably trickier to extract automatically.

I think if we find missing joseki, then we should just get it added to OJE, which I think is quite open to updates. I believe that the links for a logged position are fixed, regardless of what is added later.

By the way, @michiakig, there is an open pull request, which includes board swiping for navigation.


Not necessarily, we can build a page that allows for perusal of the collection via a Besogo board… actually I made this to check if the dictionary was converting coordinates correctly, it shows a random joseki from the dictionary side by side with OJE. would be easy to modify to allow browsing a collection

Certainly we can include other sources, but I’m not aware of any that are easy process automatically except Kogo’s. And that file does not have the equivalent of “Joseki: Done” tag, so it only really useful for the dictionary