That was quick, are you thinking of making a web-based game out of it?
yes, it was quick to put together a very rough implementation with yebellz’s Besogo, and it should be easy to host on GitHub. but the gap between what I have and a polished version is quite big:
I’m experimenting with handling rotation right now, because I think that’s kind of important to make it playable. I’m also going to finish the daily puzzle selection and local storage, and then will post it, probably later tonight. There’s two specific things I could use help with, if anyone wants to contribute:
I’m not checking guesses against a larger joseki dictionary, although I think that’s crucial to the wordle formula, it’s probably the hardest part for joseki. we need to extract valid joseki from Kogo’s SGF or something and encode them in a format that the app can check
I’m thinking of a making an easy version and hard version, based on the activity here. Easy one would be like 6-8 moves long, mostly basic joseki. hard one is if anyone is interested in helping curate a collection of harder/longer joseki to start off with, that would be cool. I could randomize the initial order so you could still play, albeit with a bit of an edge
various game design things like, how many guesses should be allowed? I was thinking to make it either unlimited or just the same number of moves? as a start…
general CSS prettiness, it’s not my forte
I’d be interested in helping, but I’ve got stuff to do in the next 36 hours. Maybe you’re too fast for me .
gotta be fast if you want that
NYT OGS money
more seriously, if there is actually interest, I’m sure I can use your help in a day or two. especially if you want to help with collecting joseki or processing an SGF dictionary. the more I think about it, manual curation is maybe too much work?
but I think something like a dozen easy joseki shouldn’t be too hard for me to collect manually, and is enough for some daily puzzles and iterate from there if there is still interest
Wow! Thank you so much for working on this, and I’m so thrilled that the BesoGo code seems to be helpful for getting this started.
I’d be happy to help out with the project. I should have some familiarity with the original code base at least.
There could be some different ways of handling this. Looking at the KGD, it’s not to clear if there is any consistent style to identify which sub-sequences are joseki, and which childless leafs might be just mistake examples. It seems like there would be a lot of work to make use of KGD as a reliable joseki detector.
There are also a few cases of very long branches where they seem to have included some professional game continuations from some joseki. Also, there are some branches where the position is amended with set stones to consider “what ifs” given other surrounding stones, but these should be fairly easy to automatically prune out.
However, even just checking if the input is within the tree of KGD would be a nice partial solution, while letting in some false positives. This would allow incomplete (prefixes of) joseki to be allowed, so maybe still not ideal, but at least prevents people from just randomly filling a rectangle.
Another flaw of the KGD is that it seems to have been last updated in only 2014, so it won’t have any of the joseki developments of the AI era.
I think extracting data from OGS’s OJE would be ideal. I wonder how much can be simply scraped via the API, or if it could just be exported (maybe only a partial dump) as an SGF from the backend. The best part of this data source is that positions seem to be clearly labeled as joseki. I guess it could be possible query the API in real-time, but that might introduce some undesirable latency.
@GreenAsJade, would it be possible to extract some of the data from the OJE for this project?
This is a choice that can always be tweaked later as game testing shows what might be too hard or too easy. I like the idea of scaling it based on the number of moves in the solution, but unlimited also makes it fun for using this as a learning tool. Maybe turning off the move limit could be an option.
I think there could be some interesting designs to consider for presenting and consolidating the hints. After making a guess, I think it would nice to directly highlight the stones on the board as green/yellow. Then, when entering the next guess, some how having the board with indicators of the past hints would be nice. The hints could be delivered by changing the outline color of the stones, and maybe just these colored outlines could be kept and accumulated for the next guess board. Maybe a small dot on excluded points could also be used.
Thanks again for taking on this project! I can’t wait to see your work and I’d be happy to help with further modifications and some of the stuff that I’ve mentioned above. I had no idea that you’d dive into this so quickly!
Not having read the thread recently, I’m not sure what “this project” is, but certainly the OJE API is accessible, so you can read all the positions out of it, being careful not to smash it.
If we are talking about implementing Josekle, I’d love to see that in OJE, rather than separate. OJE has play mode, but it’s not used that much, because it was never really matured/gamified, rather a protoype.
Josekle would be the answer.
If someone wanted to do the front end, I’d be happy to support any API work needed…
(one advantage of doing it natively would be the ability to use the outcome throughout OGS)
LOL I hope it still works after the upgrade. No-one complained yet
well you know how things go with nerd sniping
I think this would be the main goal
this is one reason why I was thinking about an easy mode versus hard mode… with enough variations an easy mode would start to uncover lesser played short joseki for less experienced players, without being overwhelming to even start (like 20 move joseki )
this would definitely be amazing! I can’t commit to it but I’ll certainly take a peek at the OJE code
okay, here is the Josekle rough draft for folks to play around with… definitely hacked together but hopefully enough for brainstorming. the collection of joseki are all fairly basic, my apologies if I didn’t include your fave or if I made up a new one tried to copy out of OJE carefully
the rules are the same as described in this thread, but with some slight twists: the number of moves is secret, but you can guess too few or too many and it will tell you, matching up as many as it can. this was just easier to implement and easier to play I thought.
also it tries to handle rotation/reflection, but no guarantees as I think that’s trickier to get right than I thought. but it should work if you put a joseki in any corner and any orientation, I would be curious if you find bugs there. the hints will add a symbol if it’s matching based on rotation/reflection. the canonical joseki from the code’s perspective is the ones starting in the upper right corner of course
here was my attempt (I think GMT+ timezone folks you will already be on #2)
Wow! This so awesome!
I have some ideas about layout. There are some easy things to fix, like certain panels to drop. I’ll play around a bit and send a pull request.
since you’re looking at the code, I couldn’t figure out how to extract the move sequence without adding this line: https://github.com/okonomichiyaki/josekle/blob/7be5ccf6358f00df4310b808fa7dbbadedff38c8/besogo.all.js#L45
Yeah, that’s probably the best way to do it.
I didn’t build in any proper hooks for extracting information like that, and the code is even somewhat defensive in shielding objects like that from code external to BesoGo.
By the way, is the combined file that you are using rebuilt (concatenated from the component js files), or did you grab the “latest” release version (which does not contain all of the latest commits)? Edit: never mind, I see you have the latest commits (rebuilt).
Also, there seems to be a bug with the game play in that if you guess a prefix of the solution, it will say “too few moves correct” and prematurely switch the “submit” button into a “share” button, ending the possibility of further play.
I think I ran
./build.sh and took the
besogo.all.js that appeared
good catch! should be fixed
I sent a pull request with some minor changes. The panels on the right are now reduced to just the navigation controls and the game tree, and it is changed to a vertical orientation.
Here are some design thoughts:
- I really like how the move tree is available as part of the game. It’s a natural way to make it easy for the user to flip between guesses and explore past information.
- I think it would be nice to put the hints directly on the board (and note these into the tree as well). This would require some more extensive modification of the core BesoGo code, but I can help with that.
- Pressing the submit button should highlight the moves on the board with yellow and green outlines, and that node on the game tree view should also be highlight somehow (maybe with an outline) to indicate that that position has been submitted. The submit button should not work on a position that has already been submitted, and coming back to that position of the game tree should show those hints on the board again.
- The empty node at the root of the tree should not be submit-able, but when viewing that, the board should be highlighted with an aggregation of all of the hints received so far. Maybe show the locations of all of the green hints so far (perhaps with a green move sequence number inside?) and then the remaining yellow hints found, and then perhaps a small red dot on any point where a move was guessed, but not found to be in the joseki.
- All of this would require new hooks for the editor to receive data about the hints. Of course, I’ll help with these aspects.
- Eventually, the CSS needs to be modified to fit the height and width properly.
- Storing solutions in SGF format might be more convenient in the long-run and there is code for parsing SGF within BesoGo already.
So a quick and dirty way to hack these in is to repurpose the “markup” symbols, like changing the rendering of the circle, square, triangle markers as these hints. The game tree / editor logic could be modified to take these hints and process them into the markup layers appropriately.
if it’s simple enough, that would be great
I think my date math was off we are all on #1 until the next day. or something