A new server is being developed: Kaya.gs

[BramGo]

My general opinion of this project: it's vague, controversial, over-ambitious, ...

This is like blowing up a giant balloon. Everytime somebody adds a suggestion, the balloon gets a bit bigger. And for some kind of reason the management of this project seems to put high urgency in blowing it harder and harder. That disturbs me because it should in fact be the LOWEST priority in this stage of the project. Collecting these ideas only distracts you from your real priorities. The term "scope creep" comes to mind.

If the complexity of a project is this high, then you should at least first make a proof-of-concept or a prototype application.

Besides that you need planning to keep this project going.
Are there any milestones at all? And are you approaching your goal at the expected speed?

Leaving all that aside, I think it's strange to raise money for such a vague project. And @ASR, I think it's strange that ASR shows this project on the front-page of its webpage. ASR has a very professional look at the moment, and it surprises me that they seem to encourage raising fonds for a project that hasn't even been started yet. Also I don't remember WMS to raise money when he started KGS? I don't remember any go related website neither to raise money even before they started development ...

Your project is just a list of features at the moment. But if you still believe this is highest priority: you can find tons of ideas in the KGS Wishlist on Sensei's library. KGS seems to understand that it has no point to implement all these ideas at the same time. Just start with the basics, and then add features in release cycles.

[stalkor]

well i gotta reply now don't i:)

yes, the project is now only just underway but i(we) think this project has potential to become the next generation go server. Also i saw an opportunity to work together with gabriel in doing some cool things in the ASR which would both benefit us (win win!) we decided we would do a couple of events together and try to raise money for his cause. I guess it worked pretty well, the ASR is a great community and i think it was well received.

But to get back on the money donation point you were talking about. If i remember correctly WMS was HIRED by kiseido to make KGS and at some point he severed that connection.

Apart from that, this isn't about money to actually build kaya.gs but to fill the gap they have between quitting their job and getting kaya.gs to generate income.

[wms]

But to get back on the money donation point you were talking about. If i remember correctly WMS was HIRED by kiseido to make KGS and at some point he severed that connection.

NOT TRUE. Please do not spread misinformation like this.

I independently developed KGS, under the name "igoweb". This was all done by myself with no investment from others of any kind. After it was up and running, a friend was speaking with Richard Bozulich (head of Kiseido), who was complaining that he was having people develop a go server and they were doing a terrible job. The friend showed Bozulich the server I'd already finished and had up and running, and Bozulich got in touch with me and we came to an agreement; Bozulich would put ads for the server in his books and would cover the ISP costs, and in return I change the server's name to "Kiseido Go Server" and have links to his shop on my web site.

So yes, Kiseido did provide money as part of the cross-promotion agreement early on, but it was *after* the server was already finished in its 2.0 release (version 1.0 was my old C client for IGS/NNGS). In addition, that money was only to cover the ISP expenses, I was never paid for my time working on the server by anybody.

[stalkor]

ok, my bad then.

My apologies...

[danielm]

My general opinion of this project: it's vague, controversial, over-ambitious, ...

The planning, milestones, and credibility aspects have been discussed before (sufficiently I think), but regarding the criticism of the features collecting: I do not agree at all that this is a sign of over-ambitiousness.

Yes, the project is ambitious, but is has to be. This is not a hobby project. To stand out and be commercially viable (even to the minimal extend of ensuring their own lack of starvation), will require stepping up a gear from other hobby or semi-professional projects. This is not impossible, though I may be biased there as I was seriously considering doing pretty much exactly the same thing.

The feedback section however, is just that. A pool of good (and bad) ideas, from which the project can draw on. In a well managed agile project, features are being implemented if and when resources are free and it becomes feasible, so planned features are not a liability in itself. There is no promise of all these features being implemented instantly, and it is quite clear that first versions of the server will come with a far more basic set of features.

Criticising the project for collecting ideas in an open and systematic fashion is a bit silly, because that is exactly what you want to do to get a better idea of which features are going to add the most value for the invested development time. You can also be certain that with two full-time developers, the project is never going to be stagnant, so planned features _will_ be implemented eventually, as long as the project survives.

[Bantari]

Still, what goes through my mind is - how will Kaya.go compete?
I mean... I don't mind supporting it because it is a good idea, but why should I play there? I bet I am not alone asking this.
Go servers are like bars. Nobody wants to sit in a bar alone, so people go where people are. But how to get the initial people in?

Well, I believe that being able to give video/audio teaching games, with any account, is more than enough to convince most teachers out there to use Kaya. Some teachers have many students, and these students have friends...

Moreover, there are 65 contributors right now, and they will definitely play on the server. It's also possible to imagine that these contributors will invite their friends etc... Some of them (like me) are tournament organizers, and they will definitely broadcast on kaya when it becomes available.

Finally, did you look at the feedback section? There are many new planned features, and many of them are not available on any other server.

There will be players on the server, a lot of players.

I admire your zeal.
Wish you all the best.
I am sure you have enough students to make a not-even-released server a major hit overnight!
All the best to you and may you live long and prosper!

[Bantari]

Much like anything social. That is a challenge every current server went through and many others have failed to do.
We have plans on how to get critical mass, which is enough to play. We expect that when we get enough players to make the place able to get a game, and we have more features, the users will flow more naturally.

Well... let me know how I can help.
I am not thrilled about your business plan, but I acknowledge that you do seem to have a plane, even if you're not sharing. To me, personally, each new idea is a good idea, until it fails... I am not in a position now to donate, but If you want a link on my website, lemme know - I like the way you think!

There is room out there for all kinds...
... and that is what makes life interesting!

[Nostromo]

Rating system: i want to implement an ELO system, very much like Wbaduk and Tygem and most Asian servers. I will make it so that the first set of games define the rank like KGS does which i think is the only advantage of the system.
So a few games to get a solid rank quickly, and then a transparent point based system.
...
KGS rating system has some disadvantages, the main one being that accounts get "heavy", hence people always have multiple accounts. Wbaduk, for example, poeple never make more than 1 account. But it still a drag that when you are close to rank up, you have to play way more many games.

Actually I think the KGS rating system is the best out there. The disadvantage you mention - the "inertia" of a rating that doesn't keep up with changes - comes from the parameters chosen by KGS, not from the algorithm. Recent results need to have a higher weight than older results. I think they already do on KGS, but the weight given to older games needs to decrease faster. Just a parameter change.

Really, the only thing I dislike about KGS is its failure to deal with escapers. If there were a server out there that was exactly like KGS, except that it had the same way of dealing with people who leave games as IGS (say), I'd switch in a heartbeat and I think a lot of other KGS users would, too.

I don't understand why you dislike Java implementations. OK, users have to download a client, but so what? Java clients (like KGS and the new IGS) work in all environments, unlike the Wbaduk and some other clients which are Microsoft-specific.

[Xyiana]

I don't understand why you dislike Java implementations. OK, users have to download a client, but so what? Java clients (like KGS and the new IGS) work in all environments, unlike the Wbaduk and some other clients which are Microsoft-specific.

Becouse this old myth about java isnt true? If you want to target now mobile devices for all 2.5major platforms, even C#(with MonoTouch help) is better solution than java on client side. So Kaya.gs decision on client side technology is correct with only 1 client developer. And for OpenKaya it is easier to get free help from html5/JavaScript ppl than from more specialized developers.

It is different situation than few yers ago and writing new server with high scalability without using overpriced closed technology/frameworks is much easier and expenses on SW part can be zero without functionality loss.

I have more problems with their Ruby choice for all server code works in case of big success( i think Erlang was better choice for their planned features and number of concurrenr users) but at least their other revealed choices seems correct.

[Nostromo]

If you want to target now mobile devices for all 2.5major platforms, even C#(with MonoTouch help) is better solution than java on client side.

I don't regard C#/Mono as a solution at all, because as a user of the client, I don't want to be restricted to the platforms which you (or anyone else) think are among the "2.5 major ones". Java is available for at least 4 platforms.

I have more problems with their Ruby choice for all server code works in case of big success( i think Erlang was better choice for their planned features and number of concurrenr users) but at least their other revealed choices seems correct.

The best choice for the server code is whichever programming language the developer is most comfortable with. It doesn't impact the users.

[Xyiana]

I don't regard C#/Mono as a solution at all, because as a user of the client, I don't want to be restricted to the platforms which you (or anyone else) think are among the "2.5 major ones". Java is available for at least 4 platforms.

If you count iOS as one of major GO platforms(and i think it is) java client is simply bad choice. My opinion is that GO future on computers is with mobile platforms clients and for this atm are both html/javascript or platforms like c#/mono much better choice than mobile platform restricted java.

The best choice for the server code is whichever programming language the developer is most comfortable with. It doesn't impact the users.

Best luck with Ruby scaling during rly heavy concurrent usage. But you are right that with real concurrency estimates for first year of Kaya, choice of server language doesnt matter Thats why i wrote "in case of big success".

[Kaya.gs]

Rating system: i want to implement an ELO system, very much like Wbaduk and Tygem and most Asian servers. I will make it so that the first set of games define the rank like KGS does which i think is the only advantage of the system.
So a few games to get a solid rank quickly, and then a transparent point based system.
...
KGS rating system has some disadvantages, the main one being that accounts get "heavy", hence people always have multiple accounts. Wbaduk, for example, poeple never make more than 1 account. But it still a drag that when you are close to rank up, you have to play way more many games.

Actually I think the KGS rating system is the best out there. The disadvantage you mention - the "inertia" of a rating that doesn't keep up with changes - comes from the parameters chosen by KGS, not from the algorithm. Recent results need to have a higher weight than older results. I think they already do on KGS, but the weight given to older games needs to decrease faster. Just a parameter change.

Really, the only thing I dislike about KGS is its failure to deal with escapers. If there were a server out there that was exactly like KGS, except that it had the same way of dealing with people who leave games as IGS (say), I'd switch in a heartbeat and I think a lot of other KGS users would, too.

I don't understand why you dislike Java implementations. OK, users have to download a client, but so what? Java clients (like KGS and the new IGS) work in all environments, unlike the Wbaduk and some other clients which are Microsoft-specific.

Javascript runs in all environments, so if your preference for Java is its support from all envs, we have that covered.

More than that, the whole idea of an application you have to download has way more friction and secrecy than a webclient.

Picture the following 2 scenarios with the way pretty much all major servers work today:

1) You talk to a go player that is not tech savyy. You tell him to go to a server to play go. The series of steps he has to do before he starts a game is astounding.
a) go to the page
b) download client
c) log in as a guest
Now he sees an entirely new thing he doesnt know how to use, that has no "start game" or anything of the sort.
d) look for someone to help him/assist him into starting a game
As opposed to-
a) Got to the page
b) log in with a form any browser user in the world would understand
c) enter and be able to play a game a click away

2) Another classical example is that you want to share a game being played with someone. "MilanMilan is playing", "they are relaying a pro game", "check out the game i just played"
All those things have enormous friction to share, as the other person has to potentially install cgoban to enter, and look for it.
With a web client, you just share a link. The other user clicks on it, and he is there. Only 1 step.

[Nostromo]

Javascript runs in all environments, so if your preference for Java is its support from all envs, we have that covered.

More than that, the whole idea of an application you have to download has way more friction and secrecy than a webclient.

Picture the following 2 scenarios with the way pretty much all major servers work today:
(....)
With a web client, you just share a link. The other user clicks on it, and he is there. Only 1 step.

You make some very good points. OK, a Javascript solution does have some compelling advantages.

The only other drawback that comes immediately to mind is that a big Javascript solution has to be downloaded every time the user visits the web page. It's all transparent to the users of course, they don't even know it's happening. But if there's a lot of Javascript (and for the level of functionality you're aiming at, there will be), the page could be a bit slow to load. In these days of high-speed internet connections, I guess it will be a small (and decreasing) problem.

[Kaya.gs]

Javascript runs in all environments, so if your preference for Java is its support from all envs, we have that covered.

More than that, the whole idea of an application you have to download has way more friction and secrecy than a webclient.

Picture the following 2 scenarios with the way pretty much all major servers work today:
(....)
With a web client, you just share a link. The other user clicks on it, and he is there. Only 1 step.

You make some very good points. OK, a Javascript solution does have some compelling advantages.

The only other drawback that comes immediately to mind is that a big Javascript solution has to be downloaded every time the user visits the web page. It's all transparent to the users of course, they don't even know it's happening. But if there's a lot of Javascript (and for the level of functionality you're aiming at, there will be), the page could be a bit slow to load. In these days of high-speed internet connections, I guess it will be a small (and decreasing) problem.

From a technical stand point, it will load faster than Cgoban does.
But also, unchanged javascript gets cached by the browsers, so after a single loading it already becomes super fast.

Also, the final form of the javascripts afte rbeing minified and compressed is very small. Again, not an issue.

[xed_over]

Really, the only thing I dislike about KGS is its failure to deal with escapers. If there were a server out there that was exactly like KGS, except that it had the same way of dealing with people who leave games as IGS (say), I'd switch in a heartbeat and I think a lot of other KGS users would, too.

its not a failure. it does deal with them. it just deals with them differently than IGS. IGS is an immediate loss, whereas KGS allows players to resume, otherwise a delayed loss.

you have a great attitude towards sandbaggers. why not take the same attitude against escapers?