Almost. But then again the broken visualizer is more like “Here’s an address, it could be mine, but maybe it’s yours - or that guy’s.” Sure, if you go somewhere, you’ll arrive somewhere.
My point is that if you just want to help people with counting, 2 is good (as you still have to make correct judgements about territory but it’s all your own perception) and (broken) 3 is bad (because it is broken).
I think the only reason people think they’d want something that’s a combination of 2 and (broken) 3 is that they’re used to (broken) 3. That’s what we had.
I always cringe hard when I see some kyu streamer click SE and say “O look I’m still comfortably ahead” when the picture it draws is patently wrong. Streamer’s fault for believing in the broken tool, sure, but it’s not too silly to assume there are lots of people who think “I’m weak, so SE is probably right”. It actively hinders learning. If people only saw black/white dots and still had to count for themselves, that would already be a big, positive difference. Rather than mislead players and cop out with “well, just don’t believe the SE”, that is just disingenuous.
Tell you the “real” score, where real is a prediction by a strong bot like katago. It can still make mistakes, but it’s probably going to be too good, and account for things you might not even see. (fairly strongly opposed)
Loosely mark areas of the board in some fashion only with no real knowledge of the game itself. Something like these Voronoi diagrams might do something like that.
Loosely mark areas as above but also give you a score counting areas based on those points marked?
introduce a weak “AI” that knows the rules of the game to help mark areas. It’s probably what the score estimator does now, with some Monte Carlo playouts to help figure out captured stones.
improve the current estimator to account for Japanese rules (which is what’s happening) and fix some other quirks like handicap and leave it like that.
draw tool to manually mark areas and stones to give to each player purely to help visually.
draw tool to manually mark areas as above but also a button to count what you’ve manually marked for you.
Basically it’s the question of what help do people want and what is too much?
Help visualising the areas
Help with counting (because it’s quite tricky to keep track of and add a whole bunch of numbers)
Help to figure out who’s winning (I think that’s really what we don’t want)
Help to figure out how much one players winning by when it’s “obvious” one player is winning. (Even a not so great estimator can tell you that reasonably well).
Should it be different for live/blitz vs correspondence?
Is this the right thread for this discussion or shall we continue it in a dedicated “How can we improve the score estimator” thread?
I guess it’s slightly on-topic since if there’s a better thing coming soon, why mess with the old one? However, the discussion seems to demonstrate the opposite - it’s going to be a lot of work to even agree on what we want, let alone implement it.
So, did anyone try out the Japanese estimation fixes on the beta site yet?
It’s all about to which point OGS wants to enforce the no external help policy. A balance between being rigorous or satisfy the wish of some players. You know we allow joseki books in corr games. And even sometimes here, players ask for AI in-game …
But the truth is that giving a weak SE, which can induce hints and failures is a bit too weird flattery in my opinion.
The main advantage i still see is a help for full beginner to close boudaries and group status, that sort of things. In that case i would better offer a strong SE to them only (20-30k). Or use humans.
What about a prominent button which appears during the agreement phase (or maybe after there have been more than a certain number of passes without the game ending?) (maybe only for TPK players?) which lets volunteers accept the request from help, and jump to the game. These volunteers would have no powers regular users do not have, but would be able to offer advice on how to end the game, and call a mod if the players are still unable to resolve it. The players could, of course, still call a mod directly. Perhaps this is providing a solution to a problem noone had, though.
when one of players is so far ahead that other player should resign and endgame would be real waste of time - I think to understand when that happens is the real thing that estimator should do. Estimator shouldn’t be able to help you to know if you are few points ahead or behind. But it should be able to tell you when you are really far behind. I think purpose of estimator is to know when to resign.
they would be just replaced with neutral points.
no need to rerun estimation from beginning, It able to just continue iterations from current modified state.
(and so, if neutral points will be surrounded by same color, they will be painted in it)
My point is just that they would need to be clarified as being created by a simple geometric rule. If a person, who is not familiar with what the tool is actually doing, saw some of these figures, they might wrongly assume that some more complicated estimation algorithm produced a positional judgement, rather than it just being a visualization of Manhattan distance.
text explaining it and that they should click dead groups themselves may appear each time when you use (during game)estimator
and when you use AI estimator (when watch game) there should be text explaining that this is real Go AI.
So no more confusion.
This is something i do sometimes with beginners: removing stone after stone from the end, i ask them to stop when they lost. Surprisingly maybe, they do find it.
You might argue, for example, that a Black intersection bordering a neutral point should be only worth half a point, since there is only a 50% chance that it will become territory.
now I see what should:
estimator should not mark any of stones as dead automatically - in game above its really not clear what is dead
player should mark stones as dead himself only
and almost everything should be painted. Estimator that leaves too many points as neutral only leads to confusion. It should be clear what it counts “one by one”