EdLee wrote:Hi Zenity,
This mainly means never treating stones in a seki situation as dead.
Curious: how does the current engine/scorer score this board:
$$B 5.5 komi, zero prisoners
$$ ---------------------
$$ | . X O O . X X X . |
$$ | X . X O O O X X X |
$$ | X X X X X O X X X |
$$ | O O O O X O O O O |
$$ | . O . O X O O O O |
$$ | X X X O X O X X . |
$$ ---------------------
- Click Here To Show Diagram Code
[go]$$B 5.5 komi, zero prisoners
$$ ---------------------
$$ | . X O O . X X X . |
$$ | X . X O O O X X X |
$$ | X X X X X O X X X |
$$ | O O O O X O O O O |
$$ | . O . O X O O O O |
$$ | X X X O X O X X . |
$$ ---------------------[/go]
( a reduced case from a bot-bot game, in a scoring discussion back in May. )
Thanks.
This is hard to verify since I don't support uneven board sizes yet, do you have a link to the actual game? The way it should work if the code is working correctly is that the entire right side is considered as unresolved/seki, and stones in such an arrangement are fully scored (including territory). So if I'm counting correctly, the score should be 28 for black and 27.5 for white with komi.
This would make a great test case!
Bantari wrote:Hi Zenity. First of all, let me say that honestly applaud your efforts and wish you and the new server all the best.
Thank you for the kind words!
I'll combine your two points in my response since both really come down to the same thing:
The Vision.
To be clear, I'm not just throwing code against the wall and seeing what sticks, this also isn't just a "fun" project. The idea has been brewing for many years, it's just that only recently I've felt that all the pieces have fallen into place to start with actual production. I have a very clear vision of where I am going, and I believe this vision will become clearer very soon as the app starts taking shape.
Explaining it in words is not so simple, because this is really completely different to what already exists. My goal isn't to convince you guys that my vision will work, but to build it and prove it
I know that a lot of this will be controversial, or rather unexpected for veterans of the community. I have seen these arguments and discussions before, as I've read up on pretty much every discussion of previous server efforts I could find (especially Kaya of course). I expected those responses, so I will not be responding to every criticism or get into any arguments, because that would not be a constructive use of our time. I absolutely appreciate all of the feedback and will read it carefully of course, but my overall vision is pretty much set at this point.
Regarding what problems I'm trying to solve, the gist of it really is to create a place to have fun playing (competitive) go in every situation. I'm not so much interested in the study aspects, because I think that we've already got this covered pretty well. In fact I think that we may be a bit too focused on that in the west, which might explain why western players (at least beginners) often have more theoretical knowledge than fighting skills. That doesn't mean that I don't care about solid integrated tools for study (especially game reviews), it's just not my first priority.
To achieve that goal, my focus primarily lies on:
1) A playing experience that is satisfying and enjoyable by itself. In game design this is sometimes called "juicing it up". It is hard to describe, much easier to show/experience. The point is that the act of manipulating the board itself should be enjoyable, similar to how the tactile experience of playing on a quality real life go board is enjoyable.
2) Tweaking the rules of the game, board sizes, timing systems, etc, to be better suited for online play against random strangers. Go is a very flexible game in its ruleset, but we aren't taking much advantage of this to make it more suitable for online play. I want to change that, and this is one reason why Apachi needs to be an integrated server/client app rather than just a custom client for another server.
3) A zero-friction experience. No annoying design flaws getting in your way. No loading times or awkward sign in processes. Just open the app, click play, get going. This of course also requires straight-forward and efficient matchmaking.
4) No possibility for exploits or griefing that rely on goodwill of the players or even admin intervention. Of course you cannot prevent everything, but I do believe it's possible to do a much better job at this than what we've done so far.
5) A first class mobile experience. Not just making it work on mobile (we have plenty of that), but creating a mobile-optimised experience that feels just as natural as playing with a mouse on a large monitor, even on a small phone in portrait mode.
6) Last but not least, solid metagaming elements to hook new players and keep old players engaged. Online go is not fundamentally different to other online games at its core, and we can take advantage of the same best practices. For instance, one major goal I have is an on-boarding experience that guides new players all the way from learning the rules of the game to climbing through the ranks. There is a ton of potential in this area, but getting into the details of that would justify an entire thread by itself. Also how much of it will be realistic to implement will depend largely on whether I will find a way to work on the project more than in my free time, so I don't want to promise too much just yet.
Moving on to your more specific questions:
will your Apachi be open-source? Open protocol? Allow 3rd party clients?
Apachi is roughly 90% client, the server side is actually a very lightweight layer on top of Firebase. My goal is to create a very integrated experience, so I don't feel that opening it up would serve much purpose.
I know the idea of simply creating modern clients for existing servers is popular, but I personally don't believe that this is the way to go. Various efforts along those lines haven't really gone anywhere in many years, and the chess world has almost entirely gravitated towards the more integrated solutions of chess.com and lichess, whereas previously it was all about generic servers and custom clients. I believe that ultimately the proof is always in the pudding, and I'd love for anybody to prove me wrong on this. But Apachi represents the opposite philosophy, and we'll see how that goes.
Regarding OSS, my goal is to eventually open source any parts that could be of interest to the wider go community (e.g. the board view or the estimator), and I am open to any sort of collaboration to help out other projects. In the end that's what this is really about, to progress the state of go app development. I'd also be more than happy if people like some of the ideas of Apachi and adopt them in their own projects.
There will be haters, and they will need to be dealt with as well. Do you have any ideas on that, and if so - what are they? Do you plan to hire moderators to deal with all this, or get volunteers you can get? Or will you be doing all of this yourself? Hiring will involve steady cash flow. Volunteers might lead to issues we see somewhere else. Doing it yourself will pull you away from development.
Remember I am a game developer by trade, so none of this is new to me. Those are common issues in any sort of multiplayer project, and my strategies to deal with it would be the same as well.
The first line of defense is always to ensure that abusive behaviour is limited as much as possible by the game design, and that users have the required tools to deal with it themselves, like muting functions.
The second line is reporting tools and volunteers to filter through the bad behaviour.
And finally there's me and/or paid community managers to deal with any urgent cases.
If Apachi remains a hobby project, then I will have to do it myself of course, and yes it's going to cut into development time. I'd probably limit things like open chat systems and such in that case, especially if the work required to deal with it becomes overwhelming. If Apachi ends up being very popular, then I'd certainly consider hiring one or more community manager(s) to help out with that. Right now I'd consider that an absolute luxury problem to have
In current day and age AI cheating might also be an issue. Any plans to address that?
It's a good question. That genie is out of the bottle and we certainly can't ignore it. The original plan for Apachi involved plans for long-form tournaments with price money, but the emergence of AI has nipped that plan in the bud.
It's a pity, but there's also a silver-lining to it: While digital go is becoming more and more a suitable alternative for OTB go, the existence of AI also ensures that "serious" matches can only be played OTB. This creates a very natural progression, with digital go being for fun, learning, and maybe qualification, and OTB tournaments being the undisputed "end game". You can observe a similar dynamic in the chess world, which is extremely popular online but OTB tournaments are still seen as a class above since this is the only place where you can be certain that games are legit.
If it was possible to combat AI cheating then I would be fully on board with that, but realistically this is a losing battle. Ranking systems at least make this largely bearable. Things like verification of actual top players / pros can help, but not completely. We trust that a well known player would not cheat, but can we ever be 100% certain?
The only real chance we have to detect AI cheaters is deploying machine learning techniques against itself. But this is an incredibly complex task, and chances are that determined cheaters will always be one step ahead. After all there is a whole spectrum between a match played completely by AI and somebody using AI lightly to gain some advantage. It's a fascinating subject that I'd love to dig into deeper at some point, but I'm also realistic enough to realise that there is only so much I can do about it.
