UGSMixed Content

    Keywords: Online Go

This page is a collection of UGS-content that doesn't seem to fit to any of the ather pages, but shouldn't be removed yet on the other side.

Table of contents


wms about KGS and UGS

Benjamin: As UGS shall become a combination of the five great web go services SL, GTL, goproblems.com, KGS and gobase.org, it would be great to get their inventors into the project instead of trying to re-invent their things and trying to take over the market - that's not what we want. I don't know how e.g. Arno feels about UGS (maybe he didn't even hear about it yet), but we should try to convince him that we don't want to take away his archievements, but just try a further step after his seperate projects (SL, GTL, goproblems) succeeded that much. I'd really love to cooperate with him, as well as Jan van der Steen (gobase) and wms (KGS), of course, although I don't know how realistic this is. What do the others think about this? Is a cooperation with them:

  • a) possible?
  • b) reasonable?
  • c) how many compromises can we accept in order to make this possible (e.g. keeping the seperate sitenames sl,gtl,goproblems while accessing them through centralizes client)?

wms: Well, speaking for KGS, I'd say I'm not real interested in this. I'm just as happy with the services being "split" as unified, and I already have a server that I very much like working on, so there just isn't a lot of gain for me. And if I did join the UGS project, then I would lose a lot of control over KGS, which is something that I do not want to do. Actually, I've been watching this project from time to time with some interest, but I have make a conscious decision not to say anything unless directly asked (like now). Why? Because this is not my server. If I were to give advice, I'd always be recommending to make it more like KGS (since KGS is my idea of what a server should be), and there is no point and no fun in making a clone of KGS. So while I'm not interested in joining with UGS, it is interesting to see the progress made in it!


About Use Cases

Create UML-style use cases with actors and actions. Typically, actors will be users and the actions can be described in sentences like "A user joins a room", "A user creates a new game". By looking at the verbs and objects of the sentences, you can get an idea of the objects we need to design, and the actions that should be possible with it. For example, from the previous two use cases you see that we have as objects "user", "room", "game". A room has a "join" method. A game has a "create" method. And so on.

From the use cases, determine what objects there are. The goal is to describe the system in business terms, not going into implementation details.


Discussion of an UGS-Forum

It seems to me that not a whole lot has been getting done because of the lack of communication that is taking place, especially between the developers. Although Sensei's is a great medium for building a compendium of knowledge, it is not so great for holding debates and discussing features. Also, it doesn't allow for the data to be organized into very specific categories (the only sort of division that exists are the few sub-pages that make up the UltimateGoServer pages.) And although the project's [ext] SourceForge page has a "forum" it is extremely limited and perhaps not particularly encouraging to some who are not familiar with it who might otherwise have had something significant to contribute. Lastly, NEITHER of these two mediums are very code-friendly. It's hard to communicate in precise terms.

So, going back to my personal favorite form of internet communication, we have this:

[ext] UGS Development Boards

I'm hoping that all the developers and interested members of the UGS will come together on this and make it the one-stop resource for development discussion. It's open for registration, and it features syntax highlighting in many languages (including Java, of course), to encourage some concrete discussion of code.

Hope to see UGS enthusiasts there!

Evan: I'm going to add an early objection to this, we simply don't need an online bulliten board with thousands of subforums etc. Online forums are not a very good tool for development, storing information and being productive in general. My experience suggests they are only good for meaningless social chit chat! If we feel the need for threaded discussions, then please set up a mailing list, but this wiki should still remain the primary place for storing and organising information about the project etc.

Hikaru79: I've foreseen these arguments =P I have counters! First, you'll notice that there is no "off-topic" or "social" or "real life" or "go" subforums-- I had the exact same concern, that we'd end up talking about everything BUT the project. So I didn't include them. Moderation will be strict. As for not being a good tool for storing information, I beg to differ. I can't think of a better one for the general level. Sure, a CVS repository is a powerful archiving tool, but the general population who wants to just throw around some ideas won't know/care enough to use it. The syntax highlighting makes it the best place to discuss actual code that I can think of. As for mailing lists, while not a bad idea for "inside discussion", is not really appropriate for a PUBLIC venue. Really, if someone just wants to throw in a suggestion, see where we are, or just has an idle curiosity, are they going to register to a mailing list, reply to the confirmation e-mail, send a query for the past archive, then read through the humungous, badly organized, .txt file? Or will they be more likely to go to the nice shiny forum with lots of nice visuals, laid out in an easy-to-choose manner that doesn't even require registration (if they don't want to register)? Forgive me if I sound patronizing, but it's not a far stretch of reasoning to notice that in general, things that are visually attractive and easy to use will statistically attract more casually interested observers than an esoteric system that requires ten minutes of work just to view. Don't get me wrong--I'm not suggesting that the forum become the uber-productive development environment that we live in. It's not an alternative to discussion and things like that. It's merely a way to get as many people involved, however little, as we can.

Ansgar?: And here I am with more counters. First, it is not necessary to subscribe to a mailing list in order to post new messages or read an archive (which are even often even indexed by google. Which webforum supports this?). The answers are even delivered right to your inbox, no need to look at yet another online forum. Second, I like being able to read and reply to messages offline with my favorite client. I hate looking through several subforums just to see weather there are new messages besides the last post, waiting three to four secounds for every new page...

Benjamin: I've just registered the mailing-list Ultimatego-devs@lists.sourceforge.net for further develepment planning and discussion. This page and subpages should be restructured to just list the facts and get proposals by extern people easily. Details should be discussed at the list.


Do we need a server apart from KGS?

  • TDerz: Excellent idea to think about but be careful of the implications!

I herewith number the points for discussion: 1) KGS-Like Room-System. 2) Games can be started

    • 2a) like in KGS or
    • 2b) like in IGS.
  • 3) Rooms may have tournaments
    • 3a) many Systems supported.
    • 3b) Pairing, Results etc. will be managed automatically for you.
  • 4) There are games (including comments), problems, situation analysis (i.e. Joseki) and lessons. Lessons can combine any of the former.

5) Everything is stored

    • 5a)in a database
    • 5b) that is managed like a wiki,
    • 5c) accessible to anybody.

6) Both realtime and 7) non-realtime activity is allowed.

    • 7a) like dragon go server
    • 7b) So people may play (...) with long time separation from the server (over a year).
    • 7c) analyze a game in five minutes or over a year.

8) allows you to play with very, very strong players (Eur 6d+, professionals)

9) Cheyenne: Security of the system. You might as well start thinking about this issue. If the system is going to be used for any type of official game where the out come will be used for offical ranking (for example being used to feed back into the AGA ranking system). Also if you are going to have closed games (for example professional teaching games where a student pays for the lesson) you will need to be able to lock who can view or review the game.

    • Ensure that timed games are fair and that the clocks are maintained.
    • Ensure that the game is being played in a fair fashion (think of someone with a modified client that allowed editing)
      • Ansgar?: Using an Open Source client this cannot be possible as everybody can change the client easily to allow editing, or use another program or a real board at the same time.
        • Cheyenne: What I ment by editing is the ability to change the state of the board being played on. For example moving, adding, or removing stone(s) already on the board that is transmitted back to the server or to the other client
        • nachtrabe: What most of these boil down to is keeping track of things on the server. For instance the issue of in-game editing--I don't care if they edit what they see, so long as they can't edit the game being played. That would imply server tracking and that all communications go along the path client->server->client.
    • Ensure that a player is playing who they think they are (don't allow a networked team of players represent a single player)
      • Ansgar?: Neither is this possible. Just imagine several people sitting in front of one computer.
      • geno: True, but the atomos of a system like this is the account, not the hypothesized individual behind it. :-)
    • Ensure that any passwords are maintained in a secure fashion

Benjamin, you already state that KGS is best until, if just the server itself is concerned, because it has features 1+2a+3a+3b+4+5a+5c+6+7c

So the additional features we are talking about are:

  • 5b=Wiki character, which overlaps a bit with
  • 7b=non-realtime-server characteristics, and
  • 8=the public using this server

Features 5b and 7b are something which seems to me like adding a tool to the existing KGS, i.e. setting time system to none and/or copying games (automatically ?; is it this what you want?) to a website where those games can be commented on by many (5b: Wiki character).

Point 8 is the one which is not technical, but depends on marketing and market share (someone will use only one system/server at a given time). Professionals are invited more often to KGS to give lectures & lessons and they seem to like the sense & simplicity of using it.

My conclusion: lobby for 5b+7b with wms and hear him sighing - extra features lead to extra risks on stability - despite from possible principle reasons against (THEN we could think of an extra server). point 8: let us lobby for KGS, get some even stronger players and professionals to use it more often.

My warning to also have cautious considerations: I mentioned market share: another server would split up the possible games to be played for all, this would be detrimental for all of us.

E.g. among non-realtime servers, I certainly feel much more for DGS (it offers more features and is easier to use) and any game played on LittleGolem is lost for the better server (DGS).


maruseru (just a japanese version of my first name, Marcel): About requesting extra features for KGS - that's why it would be good if KGS was open source - other people could take care of implementing some requested feature (this works very well for many other software projects). Since it isn't, it'd be good if UGS was open source. If it wasn't, someone else might come along in a few years and say "UGS does X and Y right, but Z is missing, so I'll just write my own".

I do worry about the potential split of audiences between all those servers...

Tderz Me too, that would be my biggest concern. (that's why I reacted so fast) Similar problems exists on financial markets, e.g. standardized options are cheaper than non-standarduzed ones, because their value is much easier to compare world-wide, hence more people are interested in them and the fixed costs sink proportionally. Applied to this question here => it seems much easier (and better, I hope) to add something to KGS (like an extra outlet) than to create something new like a competitor and split the scene.

Still a nice idea to include everything
game-server + Wiki + GTL + goproblems ...
BTW Maruseru, call me Tomaseru then :-), (ToMaSi? would be Chinese, aber ich mag die Zeichen davon nicht)


Skyr: @TDerz: I think Benjamin's description is a little Go-Server-centered; I think his intention is more likely to create a "all-encompassing Go system". An online Go gaming server certainly is part of that, as well as some editing tool. imho the most interesting aspect is the possible integration of a knowledge base of commented problems, study session, game comments, ..., together with some automated management of tournaments, league tournaments, and study sessions - all in one place. As I am writing these lines, I get the feeling that it sounds like an integration of KGS/CGoban and gobase.org... This page is not about a fixed project plan, it is meant for brainstorming - so we get to know what we really want :-)


Hikaru79: I'm with Skyr on this one. UGS can become so much more than just another server. I'm thinking of a one-stop, huge alternative (or integration) of many of the excellent Go services available now. With an account, one could play real-time and/or turn-based games, solve go problems, add their own go problem, rate and comment on go problems, chat, search a database, submit a review request, pick up a review request, start a Rengo, start a mini-tournament, create a "club" (on the server, not simply a room), chat, study joseki, etc. The possibilities are truly endless. Personally, I think this is exactly what the community needs. Count me on as *VERY* interested!

Benjamin: What exactly do you mean with "club" if it's something different to a room?

Hikaru79: I mean built-in support for things like Wings Go Club, etc. The ability to create a virtual "club" and have the server take care of things like membership, organization, etc. Clubs would have rooms, sure, but there would be more to them than that. Then, perhaps, clubs could face off against each other, have schedules (kept track of by the server), etc. Sort of like a room, but one with certain extra features.

nachtrabe: Something I've learned: Aim small, miss small. If you try to create a huge multi-tiered project, it will fail. Create a small, modular project that can be expanded, and then work on expanding it once you have the core components down. Design with scalability and future improvements in mind, but I don't think starting with a "go-server-centric" mindset--designing an alternate to KGS--can be considered a bad thing on any level.

Sure, add things to the wishlist and dream up new things, but if you start with such a massive project to create an online community I will place a high chance on it failing versus if you start with just a go server and work up from there.


Benjamin: I don't think that KGS could be changed to an UGS with its architecture. Also, have a look at the length KGSWishlist... I think that one-man-development is too slow, so open source is called for. Splitting the market is a bad point, but I don't think that you should stop a good idea by this argument. Also, if the UGS can really be implemented once in the way I imagine now, I'm sure that market will be less split than now, as both IGS and KGS users will want to switch...


geno: I once considered writing a [ext] GUI for GNU Go, but found that it required more experience with event-driven interfaces than I was likely to acquire anytime soon. Perhaps this is a good opportunity to fulfill that need, along the lines of what Skyr described as an "all-encompassing Go system".

I'm taking the liberty of creating a Ultimate Go Server Philosophy page, for discussions of open-source / wiki / free-speech issues that crop up from time to time. I would also hope that the Philosophy page would be a good place to talk about things like "Any feature which can't be turned off is a bug", et cetera, to make a server and interface that anyone can use.

Pajaro: As we are talking about free software, has anyone checked other free servers available out there? I've seen "ultimate" servers of checker, othello and others in SourceForge. May be it is possible to pick up one and improve it. In this was, the efforts of many other developers can be added.


Malweth: Suggestion for the architecture...

Based on the above comments, and on comments elsewhere in other subpages (someone mentioned a "Jabber" type architecture).

I would suggest a 3-tier (or even further hierarchical) server/client method. This will not only lower bandwidth requirements, but also allow for different types of 3rd party sub-servers.

  1. The Master server has certain tasks that can be initiated by sub-servers (in regards with a protocol specification).
  2. A Switch server can simply relay information to the master (potentially lowering bandwidth requirements)
  3. A Subserver holds the games and can communicate with other subservers at the request of the master.
  4. The client performs the basic client-server tasks and includes the client GUI.

In this way, a "club" (for Hikaru79) sub-server could perform all the tasks for the club, and only game records (demos, etc) would be relayed back to the Master.

Similarly, a subserver could arrange a tournament, individual game results would be relayed back to the master, but the tournament results would be viewable from the subserver.

The client must accept "plug-ins" to allow such "extras" as club forums, special tournaments, etc.

In terms of furthering the project, I would suggest that additional subpages be made to discuss architecture options, security concerns, etc.


tderz The suggestions on Handicap Penalty:

Give higher handicap games a lower weight than even games. with the idea of

    • encouraging people to play games against lower-rated players,

and on and on Rank Difference Penalty

    • Assign a lower weight for games where the rank difference (even given handicap stones) is "too large.
    • would then be causing (not acknowledging) that handicaps are not quite transitive and that 1 handicap stone is not quite the same as one rank.

Hence the conclusion is correct that it

    • May negatively affect the rating system that is based on the assumption that a handicap stone is roughly one rank difference.

Hence, the encouragement to play lower ranked players should/must/will come from something else, which will not affect the rating system ( appraisal in words "Teacher of the month" etc.; teaching game by s.o. even better, How would s/he be rewarded? etc.). You do not need a rating system if you plan to distort it right from the outset.

I offer the following concepts of different ratings for different time limits

Multiple Go Ratings (in analogy to Chess Blitz, Bullet, Lighning, Standard'' etc. [ext] Multiple Ratings)

  • take handicap (teaching) games out of the ranking calculation (users have this choice now: type "free" -> weighting is zero).
  • introduce sub-ratings according to thinking time and handicap:
    • cat.(1) rating for games with >1,5+ hour thinking time,
    • cat.(2) rating for games with >45 minutes (< 1,5h) thinking time (Standard),
    • cat.(3) rating for games with 15-30 minutes thinking time (Long),
    • cat.(4) rating for games with 5-15 minutes thinking time (Blitz),
    • cat.(5) rating for games with <5 minutes thinking time (Bullet),
    • cat.(6) rating for handicap games with 1-3 stones handicap,
    • cat.(7) rating for handicap games with 4-6 stones handicap and
    • cat.(8) rating for handicap games with 7-9 stones handicap.
    • cat.(9) rating for unrated (!) games.

In the end the games could be plotted with [ext] Rating versus Time. The (3-D-)table with the dimensions x=time, y=handicap and z=rating is not difficult to establish for the server. Furthermore it might enable more teaching games without distorting the rating calculations.

Why do I write this? My rating would be quite asymmetric or skewed: weak in fast games, little bit stronger at long games. (I even don't dare to give my account name on which I play fast games).

Benjamin: Wouldn't this be rather confusing? Do you know about experiences with this kind of system on a chess server?

tderz: I guess it's simply standard in Chess. Furthermore (Kasparov, Deep Blue ELO 2800) but bullet the computer stands a proud 3500! nachtrabe: I personally think this much complexity is a recipe for disaster--too much room for confusion and I don't think it would improve the experience that much. Rating is just a number, after all.

tderz: It's just a table with more information, no disaster at all. You'd know that s.o. is fast or weak at blitz etc. That's all.


The time-differentiated games should/could also recognize some particularities of the byoyomi settings. I think of some highly unusual settings as

  • 0 seconds basic time and a playable byoyomi of 30 seconds, which should fall into the "< 5 minute" category (5). But if the byoyomi, e.g. 6 minutes per move, was exceeding the time parameter of that category, obviously that game would fall under cat. (4).

Benjamin: Maybe one should take the average number of moves in a game and calculate the time total from byoyomi by this

nachtrabe: The basic problem with doing it ex post facto [1] is that it encourages someone to increase the weight of a game they are going to win by playing.... very.... slowly.... and it encourages someone who thinks that he is going to lose to play faster--even if he loses, the game will be weighted less. Thus a strategy for a low kyu player is to play quickly in the opening and slow down if you get an edge over your opponent. Similar strategy problems [2] exist with having different weights for different timed games and I'm not sure that subdividing past "ultra-blitz," "blitz," and "regular" games is all that valuable. If the win-loss curve doesn't change[3], then you don't appreciably affect ratings by including such divisions and it does open the door to people manipulating the system (albeit possibly on such a small scale it isn't worth the effort, depending on exactly how the weights are done).

tderz:

  • Re: ex post facto[1]

No that's certainly not the ex post facto-way that games with different time settings would get rated! You take the basic time limit as à priori-criteria. How much time the player use is their personal choice. Of course, I can anticipate some arguments which involve cheating: some lower level players conspire by setting the longest time setting for highest weighting and then play fast and attribute points to themselves. Without a help of higher ranked players losing in such a pseudo-long game and donating points, they don't get more points than the difference in weighting of the styles (Long vs. Ultra-Blitz) times their own contribution to their rating points. Much ado about nothing. Furthermore manipulation in many ways will be sanctioned as is the case in present server regulations.

  • Re: Similar strategy problems[2]

do not exist because of the reason given in Re 1.

  • Re: win-loss curve[3]

I do not understand it: If the win-loss curve doesn't change it seems it cannot cause it does open the door to people manipulating the system. Hence this argument seems flawed and you consider it yourself a small problem as well.

tderz: I suggest a table time vs. rating, so that you can see where you stand at a given time limit. This is normal in Chess. You could qualify the statement this is a strong Blitz player by a rating. If you want you cann blend up these figures again in one rating (in order to include all rated games) analogue to proposed in [ext] Rating Formula – Better than Elo? point 3, last table.

..........Handicap......1-3.............4-6.............7-9
Time
> 1,5 hours............Rating1......Rating2......Rating3
etc.
etc.
5-15 minutes__.....Rating7......Rating8......Rating9
< 5 minutes__.......Ratingx......Ratingy......Ratingz
Ultra-Blitz


This is a copy of the living page "UGSMixed Content" at Sensei's Library.
(OC) 2011 the Authors, published under the OpenContent License V1.0.
[Welcome to Sensei's Library!]
StartingPoints
ReferenceSection
About