@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.
But the zooming always goes to the same corner, right?
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
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)
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.
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, @okonomichiyaki, 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
Could there be a āshare for discordā option that uses the ā||ā syntax for spoilers rather than the ādetailsā syntax?
Although that doesnāt really hide the length so maybe the spoilers donāt really matter and it could just be a spoilerless option for sharing across platforms like discord Twitter etc. You know, to help it go viralš
Wow, I was just composing a post about icons, before I saw @Goopletās new post come up.
I definitely agree that we need to add an icon, and I quickly threw together this icon earlier this morning.
I tried to capture various aspects of the visual design of the hints as well as adding a stylistic J in the top-left stone. However, Iām not sure if I fully love it. The design might be a little too busy.
This icon is inspired by the below icon that I made for BesoGo.
I wanted to build off of that concept, due to the codebase connection.
Note that background color is slightly different. For the BesoGo icon, the color is the average color of the realistic wood board image texture, while for the proposed Josekle icon, it is the current background color of the board for that interface. We could also reconsider the specifics of the color design of Josekle as well (do we like a brighter board color?).
Is there an accessibility reason for the color choice? I donāt love the look of purple and green together in the app icon, but if that color choice is important for the game itself it might make sense to keep it in. Although thereās always the possibility of taking a bit more inspiration from the Wordle one, where only the success color is shown in the icon.
Something like the Shin KGS one might work nicely:
I do like the idea of playing off the design of Beso Go though
Well, I fully love it!! Donāt think it is too busy but not sure how it looks zoomed out. Only suggestion would be to somehow refactor the āJā, so it stands out more⦠Contain it entirely inside the stone, or replace the stone with the letter like the āGā in BesoGo icon?
Iām not an expert on accessibility or color blindness, but we chose it from @antonTobi 's suggestion:
I like the purple and green, but would be happy with more options⦠I think the yellow of Wordle is too close to the goban itself