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 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.
Possibly? I missed that part, well I skimmed over it because it already happened, and jumped into the web version
Definitely possible. I guess I’m somewhat conditioned when thinking of joseki to think of black has these stones, white has these and not so much “a stone is here”. I guess not hinting with the colours is a little bit more like
Although trying todays one I’m more confused. I’ll keep guessing but I’ll post some here that I just don’t understand. Maybes it’s the mirrors and rotations kicking in?
So from going from guess one to two, I expect there to be a black 3-4 point and kosumi but not the first and third moves. It definitely feels like they need to be black stones from the further guess. But I can’t see a way to use that information to figure out anything further to guess.
I might need more practice and to think a bit more. I’ll try more guesses. It’s gonna be a bad score today
This was impossibly hard for me to use the hints, I think because I don’t quite understand the mechanic. So I just guessed one joseki, and nothing felt like it was going green and afterward I just guessed an entirely different joseki, different starting point and got mostly green, then just messed with the last few moves.
It might be the case that as said
that might help a lot to understand the mechanic of it. Lets assume I’m familiar with wordle or some other joseki game, but I haven’t read the forum discussion and was maybe linked by a friend
Edit: minor things aside, I’m pretty excited for this, and it’s pretty fun, I just want to figure out how to start using the hints to work toward the answer
if you see a symbol next to the hint, those hints are coming from your submission rotated/reflected. if it’s absent, the hint is based on exactly the position/sequence you submitted.
I first included this because I thought it would be useful, but then I removed it because I found it confusing… however, I added it back in before posting the link because I found some bugs in the rotation/reflection code. so I’m definitely interested if people think this is useful or not, and how generally to handle rotation/reflection in the puzzle design. it seems to me like something that it really should take into account, like these two guesses should really be evaluated the same?
however they’re actually not (at least for puzzle #1 or #2, can’t remember what I was testing), they produce different “strings of hints”, without the symbol
this is because the code tries to match exactly, then reflects and matches. it then compares the resulting hints, and shows you the “better” one, in other words one with more greens/yellows. but these two have the same number, just different order. I added this “scoring” matcher because it was the only way I could think to compare matches after reflection.
I’ll try to restructure the code a little bit with some comments and post it, and if others have ideas or can find bugs with it, maybe we can make the reflection better. I think it’s a bit challenging to get right…
I can imagine a situation where you try to guess a joseki and in one guess it gives you the unflipped score and the next, somehow the mirror is closer or better in score and then that throws you off.
I can’t think of a simple example immediately though, maybe something where the guesses are very wrong? Maybe even only one move in common with the right answer. If it doesn’t come up practically though, then it probably doesn’t matter.
I think the possibility of rotations make it a bit tricky to indicate on board hints. One would also have to adjust the stone positions to show how the game rotated or reflected them. Maybe just avoid rotation and reflection altogether, but instead follow conventions about how solutions must be oriented, like first move is always by Black and within the polite triangle. Until symmetry is broken (after the first move played off the diagonal), subsequent moves in the solution are also within the polite triangle. However, the user can place joseki in whatever rotation/reflection they want to on the board. Eventually, when input checking is implemented, we would have check whether any rotation/reflection of the input is found in the joseki dictionary.
@michiakig, I’ve implemented on board hints and marking up the tree to indicate hints. Also, I blocked submission of empty and duplicate guesses, and allow hints to be generated for guesses beyond the length of the solution. Pull request sent, but you can see a live version here: Josekle
Yeah, the colors are kind of awful and garish. I really need to play with those a lot, and reconsider the color design of everything as a whole. Those colors are just a quick placeholder. Luckily, they are just specified as easily changeable values in the CSS file.