It is currently Wed Mar 27, 2024 11:34 pm

All times are UTC - 8 hours [ DST ]




Post new topic Reply to topic  [ 29 posts ]  Go to page Previous  1, 2
Author Message
Offline
 Post subject: Re: Introducing Apachi: A Progressive Go Server
Post #21 Posted: Wed Sep 04, 2019 4:53 am 
Lives in gote
User avatar

Posts: 310
Location: Deutschland
Liked others: 272
Was liked: 126
Rank: EGF 4 kyu
Zenity wrote:
Quote:
don't want to be distracted by theirs.

You only see your opponent's focus during their turn, I think that is fair enough.


I understood that from your original post. I don't want to see their focus -- not even during their turn.

In real life, if my opponent spent their whole thinking time waving their hand about above the board, I would complain to the TD. Or, alternatively, if you think your mechanism is similar to me watching where their eyes are pointing, that's an acceptable analogy but, in real life, one has a readily implementable choice not to look for where their opponent's eyes are focused and so, similarly, one should have the option not to use this feature.

Just implement options. When something is controversial, why risk reducing your audience by making it mandatory?

Top
 Profile  
 
Offline
 Post subject: Re: Introducing Apachi: A Progressive Go Server
Post #22 Posted: Wed Sep 04, 2019 4:59 am 
Lives in gote
User avatar

Posts: 310
Location: Deutschland
Liked others: 272
Was liked: 126
Rank: EGF 4 kyu
Uberdude wrote:
One way to solve the lack of players problem for a shiny new server with a fancy UI is to make your client also a client for existing servers. So in the "find a game" screen or hidden pool of automatch you include currently open challenges from KGS, OGS, and other servers with an open api.


You're 100% correct. The problem is that no such server exists.

As far as I understand, the OGS API cannot be used for actually playing games. The KGS JSON API, as previously discussed, is half-baked, unsupported and incomplete.

We don't need a new server. We need a robust, well populated server with an open, supported API.

To be entirely honest, if I was to write a new client for an old server, today, I'd reverse-engineer IGS' protocol using telnet and target that -- it is probably the easiest of the lot and, given that IGS has never deprecated a client in its history of existence -- it is also probably the safest bet from a longevity perspective.

EDIT: If I was the new owner of KGS, I would put a bullet in ShinKGS, let Cgoban (the Java client) continue to exist in stagnation as it has for the last decade and focus 100% of my attention on creating an open API for what already exists: a good server. That would involve community collaboration on the specification for the API (the source for the server and the API can still remain closed if they want), official hosting of at least the latest and second-latest API versions (to provide a buffer window for other clients to update) and a public road-map in good faith. Were this to be done, I'm pretty damn sure that I'd have resurrected my own projects, GoUniverse would be popular and useful and this thread would be about a new client for KGS with innovative input and HCI ideas.

Top
 Profile  
 
Offline
 Post subject: Re: Introducing Apachi: A Progressive Go Server
Post #23 Posted: Wed Sep 04, 2019 5:41 am 
Oza
User avatar

Posts: 2401
Location: Tokyo, Japan
Liked others: 2338
Was liked: 1332
Rank: Jp 6 dan
KGS: ez4u
Thanks for your quick reaction on my whining about the log in. :tmbup:

The next thing that seems necessary right now is a self-play option. At the moment, 'play' does nothing in the evening in Tokyo time, presumably because I am the only person there. It would be great to play around with the real board, clock, etc. to see how it works.

On the different sized boards for different time limits, I think that you will lose on this one for 19-line boards. For better or worse, some form of blitz is the norm for online play. I imagine this will be even more so while Apachi is still in alpha/beta phases.

On 11x11 versus 9x9 for the small board, remember that a lot have people have played on Go Quest so 9x9 will not be seen as just for beginners and will almost certainly be a bigger draw than a new size.

A 'who's online?' board with a simple chat feature would be a big help for community building even at this very early stage.

I wish you all the luck in the world. I think your ambitions are great and that it is important for Go's future that ideas from modern game design are brought to bear.

_________________
Dave Sigaty
"Short-lived are both the praiser and the praised, and rememberer and the remembered..."
- Marcus Aurelius; Meditations, VIII 21


This post by ez4u was liked by 2 people: Bantari, Zenity
Top
 Profile  
 
Offline
 Post subject:
Post #24 Posted: Wed Sep 04, 2019 6:25 am 
Honinbo
User avatar

Posts: 8859
Location: Santa Barbara, CA
Liked others: 349
Was liked: 2076
GD Posts: 312
Quote:
Just implement options. <snip> why risk reducing your audience by making it mandatory?
Yes. Options are good.

Top
 Profile  
 
Offline
 Post subject: Re: Introducing Apachi: A Progressive Go Server
Post #25 Posted: Wed Sep 04, 2019 9:48 am 
Oza
User avatar

Posts: 2408
Location: Ghent, Belgium
Liked others: 359
Was liked: 1019
Rank: KGS 2d OGS 1d Fox 4d
KGS: Artevelde
OGS: Knotwilg
Online playing schedule: UTC 18:00 - 22:00
Just a throw-in from someone who plays online on and off: although there's clearly a drop in players on KGS, I can still get games there easily, just not always on my terms. Even more so on Foxy. There's a lot of needless stuff going on there in the UI but that doesn't distract me a bit. I hear OGS is good, I just haven't bothered going there.

If the problem is there are so many initiatives, a new one adds to that. Uberdude's comment is then one to cherish.

Maybe I don't have high standards for a go server since I don't play very often and Go is a minor pastime these days. It's just that there is a big silent majority out there whose behavior you need to observe and which may not be expressed by the vocal minority. And for me, the drawbacks of online play will never be solved by any new online initiative, just like the best videoconferencing experience will probably never be able to relieve me from business travel.


This post by Knotwilg was liked by: yakcyll
Top
 Profile  
 
Offline
 Post subject: Re: Introducing Apachi: A Progressive Go Server
Post #26 Posted: Thu Sep 05, 2019 10:11 am 
Beginner

Posts: 9
Liked others: 12
Was liked: 5
Just pushed a small update with these changes:

* Outdated seek requests are now ignored.

* Added a notification when match starts (if you allow it). This is still very crude, but should make it feasible to seek in the background if you want to try your luck. Feel free to do this any time during pre-alpha, even if you don't know if you will be available for the match. Worst case scenario is that the match will time out after two minutes.

* Tweaked stone placement timings and the sound effect. It should feel more natural now.

* Fixed suicide plays.

* Added score visualisation. It looks like this:

Image

The shaded dots are strength indicators and the blue/red circles are estimated territory/points.

In a match you can view the overlay and estimated score if you hover the score element. I haven't decided yet whether this will always be possible or only during the endgame phase, but for now it's always enabled to make testing it easier.

* Added some basic controls to the demo board to try different board sizes (any value between 3 and 199) and show score overlay.


The score estimator is a static one and does not use the Monte Carlo method like most apps seem to do nowadays. Monte Carlo works perfectly fine and I first thought I'd use that as well, but there is also something appealing about a static estimator with clear rules that does not rely on play outs. It still needs some work and I noticed a few new issues as I was testing this, but for a start I'm already very happy with the results.

I will only be doing area scoring, because I want players to always be able to resolve a situation by simply playing it out without incurring a loss. There will be no "marking stones dead" phase, so either the result is clear or players have to play it out until it is.

Thus while the estimator in the ideal case should provide a reasonable estimation as soon as possible, the most important aspect is that it does not make any mistakes that can't be solved by playing out the situation. This mainly means never treating stones in a seki situation as dead.

The screenshot shows a good example where the estimator does not mark the black group in the lower middle-left as dead, whereas estimators using Monte Carlo would do so. White would have to play out the situation until the result becomes clear. There are pros and cons to this, but I think it's overall a good thing if the estimator doesn't basically play the game for the players.


The next major feature I'll be working on is the ranking system, that's going to be fun!

Right now the app is definitely not yet in a state where playing normal matches makes a lot of sense, but it's quickly getting there. In the meantime, the best ways to try out what's already there are (in order of least effort to most useful):

1) Just play around with the demo board, no registration needed

2) Sign in with two different accounts on separate browsers/devices and play against your self

3) Join the Discord channel to schedule a test game (or just hang out and provide moral support <3). The channel is still quite empty, but I'm usually around and would be happy to play a quick game almost any time.

Cheers!

Top
 Profile  
 
Offline
 Post subject:
Post #27 Posted: Thu Sep 05, 2019 2:33 pm 
Honinbo
User avatar

Posts: 8859
Location: Santa Barbara, CA
Liked others: 349
Was liked: 2076
GD Posts: 312
Hi Zenity,
Quote:
This mainly means never treating stones in a seki situation as dead.
Curious: how does the current engine/scorer score this board:
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.

Top
 Profile  
 
Offline
 Post subject: Re: Introducing Apachi: A Progressive Go Server
Post #28 Posted: Thu Sep 05, 2019 3:06 pm 
Gosei
User avatar

Posts: 1639
Location: Ponte Vedra
Liked others: 642
Was liked: 490
Universal go server handle: Bantari
Hi Zenity. First of all, let me say that honestly applaud your efforts and wish you and the new server all the best.

But - since you asked for comments and critique, and since the server is in very early phases at the moment - I decided not really to talk about it feature-by-feature but concentrate more about some general issues that come to mind.

1. What is the problem you are trying to solve?

I get what you are saying about 'progressive', but I am not sure this is enough. If it was, a better way might be to develop a killer client for an existing server (any of them has a open protocol? I am so out of touch...)

There are many things people find lacking about the existing servers. Lack of continuous development and improvements. Bad interface. Ugly board. Lack of teaching tools. Bad matching solutions. Etc... I think the first step can be: lets complete a list of things people want and miss, and lets see if we can build something that addresses those issues. Creating a brand new server can be a good idea in this respect.

As a start, I am not sure (maybe I just missed it), but will your Apachi be open-source? Open protocol? Allow 3rd party clients? If any of that is true, especially the last one - this will probably solve the biggest - by far - issue people are having with existing servers like KGS.

I know that right now you are just having fun programming, so maybe this is not very important to you. However - once you have a list like that, it might allow you to approach the project in more targeted way as well as avoid re-writing stuff later on. Think twice, program once, as my grandma used to say. ;)

2. What is the vision/plan for the future?

And again - I do not mean the features here. Features are easy.

I think the biggest hardship in introducing a new server is not really building it but running it after it is built. You mentioned your thoughts on business models and financing - this is a good start. But from the user's perspective, this is not so important.

Once you get a certain number of users, there will be issues. You will need moderators, some methods to resolve conflicts, deal with misbehavior, and so on... 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.

In current day and age AI cheating might also be an issue. Any plans to address that?

Bad solutions to any of the above will doom your server to failure, no matter what the features are and no matter how beautiful the board looks.

From what you say - you might not mind that very much, but... At some point you might ask people (players or sponsors) to pay or donate to your project, and the answers to the questions above can determine how much traction you get. Remember Kaya - I think many people were bummed and are now reluctant to jump on the "new and shiny but still in alpha" projects. This might be one of the more lasting damages Kaya did - at least in my view - and it would be great if you could undo it.

From what I see right now - you are just writing some cool code, and having tons of fun. Great, more power to you! As people have pointed out - you seem to over-emphasize some of the features which will differentiate you from what's out there. I think a solid base is a wiser way to start with, but I don't really mind how you get there as long as you get there. What I am trying to say is that writing the app is just the first step to creating a successful server, and not even the most important one. I am really interested in your thoughts about the other stuff I mentioned.

Once again - wishing you and Apachi all the best! You can certainly count me in as a user in the future.

_________________
- Bantari
______________________________________________
WARNING: This post might contain Opinions!!


This post by Bantari was liked by 2 people: Charlie, Knotwilg
Top
 Profile  
 
Offline
 Post subject: Re:
Post #29 Posted: Fri Sep 06, 2019 8:19 pm 
Beginner

Posts: 9
Liked others: 12
Was liked: 5
EdLee wrote:
Hi Zenity,
Quote:
This mainly means never treating stones in a seki situation as dead.
Curious: how does the current engine/scorer score this board:
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:

Quote:
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.

Quote:
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 :)

Quote:
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.

Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 29 posts ]  Go to page Previous  1, 2

All times are UTC - 8 hours [ DST ]


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group