Updated color themes (using purple/green as suggested by @antonTobi) live on my dev fork: Josekle
Also available are dark mode and real stone mode (for @Vsotvep).
Note: we also need to make the rest of the page dark for true dark mode.
Pull request sent to @okonomichiyaki.
merged, I think the purple looks pretty nice 
the on board hints are also useful, looking forward to trying them out ā¦
there is something weird with the date math, the next puzzle drops at a weird time, Iāll try to fix it
any takers?
@Vsotvep curated a list of 30 joseki for this game: The Hurt / Heal Joseki Game!
Some are easy and common, but there are also some quite long and complicated ones as well.
also this is extremely funny to me, at work for years we literally had an image containing a yellow icon in our source code which was named purple.jpg 
because no one could be bothered to fix it everywhere the file was referenced, so it was just swapped out
const YELLOW = "š£";
The tree nodes are highlighted when it has been submitted, and the highlighting shows the best hint given for that node. So, if you guess everything that misses, youāll get a red X. If at least one purple is found (and no greens), it will be highlighted with purple. If there are any greens, it will be green.
All of the hints are aggregated back into the empty root node (which cannot be submitted), and hence the root node is highlighted with the best hint found so far. When there are both green and yellow purple hints for a particular point in the root node, it will be highlighted as green to indicate that at least one previous submission found the right timing of that point.
I guess it is also natural to think of color names as abstract concepts not directly related to actual colors. I just noticed that in the previous paragraph, I had accidentally still called those hints as āyellowā.
This has been looking better and better! But the coloring in the tree was extremely confusing. Why not color each node according to the actual result for that node?
One of these has the first three correct, but itās impossible to tell which one.
And what do the letters on the board represent?
What do you mean? Like somehow indicating how many hints were green/purple? Iām not too sure how to cleanly represent such information.
Or do you mean propagating hints into other unsubmitted nodes?
I guess the game could always do more to assist the player with the processing and presentation of hints, but it is a puzzle after all.
The āA, B, C, ā¦ā letters just indicate where the next move (and variations) are located. Thereās actually a button on the interface to turn these off, and you can switch between showing the āchildā variations (next moves already present in the tree) vs showing āsiblingā variations (alternate moves to the current one already present in the tree).
This is what I took it to mean, and I think it would be a nice QoL feature.
this is what I was going to look into. but Iām not sure if I will have time before tomorrow, so if someone else wants to tackle it, go for it
I didnāt think itās too much assistance because itās information the player can just deduce easily from the existing hints, comparing emoji lists with the tree
I meant that for submitted nodes, you display the hints right on the nodes themselves. Arenāt they a property of the node, after all? Maybe thereās something I still donāt understand here.
For example, it was particularly confusing when I made moves 1-2, and ā2ā was green in the tree, while the first ball was green in the hints section below. I was wondering whether the hints showed the last move first and played incorrectly a few times as a result.
I think itās giving information thatās already available, just presenting it more cleanly. Like how most Wordle adaptions not only color the guesses, but also color the OSK as well.
Oh, I see now. Thatās a good point, and it should be easy to do that, by having the tree check the hint status at each nodeās move.
EDIT: Actually, now Iām thinking of the best way to do this. One naive approach would be to propagate backwards all hints along the path from the submitted node until one reaches the root. However, with some inputs, it could be possible to have an intermediate node with a move that should be purple, but that stone is later captured and replaced with a correct green move. So, we need to careful about propagating backwards all hints, but rather only show the hints up to move X for the node of move X (except that the root should still accumulate all hints, but does not need to be highlighted with anything in the tree).
I think it would be somewhat cleaner to do this while internalizing the solution checking function into the editor code, rather than using a bunch of call-backs to the editor object.
@okonomichiyaki, are you currently already playing with something related to this feature? I could take a stab at it, if not, but I would need to edit both app.js and besogo.all.js so I want to avoid any conflicting changes with whatever you might be currently working on, in order to make merging easier later.
With the hints displayed on the game tree, the emoji display at the bottom of the page becomes almost entirely redundant (but we should still keep it for debugging mode, and of course generate such text for sharing purposes), and the submit button could be integrated alongside the delete button. However, we still need to figure out how to indicate whether the hint was too long or too short.
Any suggestions for how to indicate this, and for icons for the āSubmitā and āDeleteā buttons?
Iām not working on anything for a bit, feel free to edit anything just pull the latest from my repo
it is a bit more complicated with captures, hasnāt thought of that
New hint behavior is now live on the dev fork: Josekle
Pull request sent.
@Feijoa, is this what you had in mind?
Note: hard refresh (like Ctrl+F5, depending on your browser) might be needed in order ensure pulling the latest code.
Good news, I have got time to join the development now 
.
Bad news, Iām still not done with my other stuff.
Very nice 
I think Iāve seen something similar where if you go one move beyond the correct solution it will say itās right up to point and say too many moves, but then you canāt submit the fewer moves solution.
The main reason you might want to is probably to share the emojis.
I think at the moment one probably has to delete the branch to do it.
Thanks, great catch! Thatās definitely a bug. Maybe the system should just switch into correct mode (and allow sharing) at that point? Or does it make sense to force one to resubmit?
Eventually, we might consider variations, where a move limit might be enforced, or at least the number of moves in the solution might not be secret.
I can see pluses to both.
Might seem harsh to punish adding on one extra, especially if that move is or was a common follow up potentially. So one could just say āgood enough :)ā
Then again, one is aiming to get the sequence correct including the length.
So either or
Yes, this looks great!
