A list of features you'd like in a new chess server

[hgm]

Chess variants (as opposed to arbitrary games and puzzes) do not have a large impact on the ICS design. Especially not if the move generator used in the legality checking of moves and mate testing would be table driven.

Not more than a few percent of the code will have to deal with the actual game being played anyway. The most obvious details to make the design 'variant friendy' is to make the piece-indicating letters (used in SAN and FEN) not fixed but programmable on a per-game basis. (So that different games can use different letters for the same piece, and the same letters for different pieces.)

Drop variants (Crazyhouse) need some extra code to keep track of captured material. There are quite some engines that can play crazyhouse. Bughouse does require a lot of special code outside the game-handling proper, because it is a 4-player game, and as such goes against the logic of the rest of the server.

As for termination conditions: most Chess variants are very similar w.r.t. this. Notable exceptions are extinction variants, where you win by capturing all pieces or a subset of pieces. But this is totally trivial to program. The most complicated condition I ever encountered is that needed to determine the result in case of a 3-fold repetition in XiangQi. Of course XiangQi is a variant that does have its own Computer World Chapionships. Like Shogi.

[sje]

For the very first version, I'd like to concentrate on getting the communications issues resolved and the event handling logic running.

1) Only two variants supported at first: regular chess and a simple non-chess game (3-D, order four tic-tac-toe). This means only two-player games (likely permanently); I've never seen a big demand from authors for non two-player games.

2) All games matched via auto-match; the opponent is randomly selected from the pool of connected and open players. Player can specify open/closed match status.

3) Only blitz time controls.

4) No adjournments.

5) No web or e-mail functions.

6) Some player database functionality, but extremely limited game database functionality.

7) Only one or two server side robot players; one of these will likely be a GUI-less Crafty connected to sample client side open source code. Other candidates are TSCP and an experimental version of Symbolic.

8) Basic Elo rating system; each player starts at 2000 elo.

9) Only one match per player at a time; no simultaneous play.

10) Support for ALL flavors of FIDE draws and resignations.

11) Server side automatic recognition and enforcement of game termination by checkmate, stalemate, and clock flag; recognition of draws by repetition, insufficient material, and the 50 move rule.

12) No remote client start capability.

13) Some kibitz support using a to-be-established standard.

14) Some text chat support; channels are named, not numbered.

15) Limit of eight or so simultaneously connected players.

16) No anti-lag support (timestamp/timeseal).

17) Client side support for mapping events to readable ASCII text that can be used for debugging.

18) All locale specific support (time zone, language, number format, etc.) is the responsibiity of the client as only UTC/English will appear in the sample code.

Of course, all client side support code (all C++) will be open source. Server side code for the C++ base class that each variant must inherit will likely be public in order to encourage third party support for variants.

I think I'll call this the Banjo project with the BanjoServer application, the BanjoClient support, and the BanjoEvent subsystem. Why Banjo? Because playing on a banjo always makes you happy (from a very old Steve Martin comedy routine).

[Don]

I built a simple server for computer go, not nearly as ambitious as this project, but it was a surprisingly huge success. It has become the defacto way to get your program properly evaluated.

It is a success despite the fact that there is a wonderful free server available called KGS, that has far more features and is better done than mine. And you can play games all day on this free server that is so wonderful.

So how was my server different? It answered a specific need that wasn't addressed by KGS. It did not replace KGS as just about all computer go authors continue to use KGS for testing their programs against humans, as I do too.

The need my server addressed was to allow only computers to play each other in computer scheduled matches and get ELO ratings. I don't know of any server that does this right.

With chess servers, you have complete control over who your opponents are. This is a very bad thing if your purpose is to evaluate your program against a variety of opponents in an objective way. If all you want to do is have fun and socialize, then you have a different need. On the chess servers opponents can refuse to play you. You can manipulate your ratings this way, or be taken advantage of this way.

With my go server, your program logs in and all the matches are scheduled for you. That was its specific purpose. The server tries to schedule players who are close in strength, while providing variety. And you cannot just pull the plug when you are losing - games are not stopped in the middle and continued later. So you cannot stop the game in a difficult position, prepare the next move, then continue the game a week later. If you drop the connection, your clock keeps running and you must reconnect if you do not want to lose the game.

I agree with HG on this, if you simply just design a server with all the bells and whistles, you are reinventing the wheel. If you can build a better server that what already exists, more power to you if you can justify the enormous effort involved. But it won't be compelling unless it does something that people really want that cannot be done on any other server.

[sje]

Well, there are design issues and there are policy issues. The idea is that the design has to support whatever policy might be employed. Different operators can have different policies while at the same time using the same server code.

One policy I'd like to see would be to have at least one (and maybe only one) server run as an authors-only site with no cloners, no observers, and no human players, and with all games and results being private by default. Programs both public and private, commercial and non-commercial could battle without any concern of embarrassing results being made public. This approach would encourage more experimentation and hopefully more progress as well.

Another policy option would be to have each author have twin entries; one of which could specify opponent characteristics while the other entry would be matched only with opponents selected by the server. Said selection would be based in part on typical pairing rules seen in human events and not influenced by the payers.

A chess server is really not an enormous effort. Over the years, I have already written all the big parts: the chess specific stuff, the socket/listen/connect stuff, the XML parser/generator stuff, the HTML generator stuff, and the database interface stuff. The real task here is to define the structure and semantics of the event set that will make the protocol robust and easy to use.

I'm not interested in implementing all the bells and whistles seen on a typical ICS, as most of these are afterthought kludges without any unifying logic. Also, a commercial ICS has to do whatever the typical subscriber wants and that is not necessarily what chess program authors might want.

[Don]

Well, there are design issues and there are policy issues. The idea is that the design has to support whatever policy might be employed. Different operators can have different policies while at the same time using the same server code.

Yes. My go server was based on a specific vision. I think your vision it to build a great "swiss army knife." I had a more specific goal which of course made my task far simpler. I guess you might say mine was more like a unix utility, designed to do one thing but do it well.

One policy I'd like to see would be to have at least one (and maybe only one) server run as an authors-only site with no cloners, no observers, and no human players, and with all games and results being private by default. Programs both public and private, commercial and non-commercial could battle without any concern of embarrassing results being made public. This approach would encourage more experimentation and hopefully more progress as well.

I like that. It would be nice to have rooms with completely different policies possible.

Do you allow for the policy of the server making all the pairing decisions even when not specifically hosting a tournament?

Another policy option would be to have each author have twin entries; one of which could specify opponent characteristics while the other entry would be matched only with opponents selected by the server. Said selection would be based in part on typical pairing rules seen in human events and not influenced by the payers.

I guess that answers my above question.

A chess server is really not an enormous effort. Over the years, I have already written all the big parts: the chess specific stuff, the socket/listen/connect stuff, the XML parser/generator stuff, the HTML generator stuff, and the database interface stuff. The real task here is to define the structure and semantics of the event set that will make the protocol robust and easy to use.

I actually had my first prototype for CGOS in a single days worth of effort. But I did not have ambitious goals. I think you are probably underestimating the effort significantly, given the huge list of features that just you specified. The devil is in the details as they say.

Perhaps there is a nice way to build the core functions and make it possible to add features later as modules.

I'm not interested in implementing all the bells and whistles seen on a typical ICS, as most of these are afterthought kludges without any unifying logic. Also, a commercial ICS has to do whatever the typical subscriber wants and that is not necessarily what chess program authors might want.

You say that now, but earlier you said you wanted to support a variety of policies. Just about every feature of any sever might be useful to some chess authors.

I did not design CGOS as a place to socialize, and I'll bet that is where 95% of the effort is in building a server. However, that is not a bad thing to have, it just wasn't something I was going to take the time to do. For a no-nonsense server this is a frill, but I'm sure you could make a strong argument that this would be a very useful feature in a server even for chess programmers. So where do you draw the line?

[sje]

Five more ideas:

1) Have the server employ a timeout policy that will automatically disconnect a (likely) hung client. The actual timeout period would be dependent upon the time control in use, the remaining time of the player, and the move count. A player could optionally specify a shorter timeout metric.

2) Integrate secure timestamps as part of the protocol instead of an implementation by a separate program like timeseal.

3) Include a hot swap capability in the protocol so that a server can gracefully switch the games and the client connections to a backup server. The switch would be seamless and transparent to all players. This technique could also be used for load balancing.

4) To help make #3 work, a server can have special player accounts that are really accounts for other servers. One server could login to another and send state information and then switch regular players as needed. The idea could be extended to have real players on one server and observers on another.

5) Have a server publish a regular e-newsletter containing top ten lists of games in categories like: shortest wins, longest wins, biggest upsets, shortest draws, earliest mate, longest announced mate, etc. Also, player categories: strongest, bravest (diversity and strength of opponents), fastest, busiest (number of games), bloodiest (least rate of drawing), etc. Servers across the globe could collaborate and produce a unified newsletter. It would be like "This Week In Chess" but instead could be called "Seven Days In Banjo Land".

[sje]

From a server point of view, there are many features like socialization that are easy to support but can be challenging at the client side. And that's okay with me, because nowhere do I say that I'll write a sophisticated client with bells, whistles, or eye candy. Such will be the responsibility of others; all I will do is make sure that the protocol will support their (reasonable) needs.

Also, we must consider the rather likely possibility that third party utilities like Skype (or better, its open source alternatives) are more appropriate for written and spoken conversation than is an addition to the server protocol.

[Dann Corbit]

6. Badboy rating.
If someone disconnects in the middle of a game, store the IP address if it is not already stored and increment a counter (storage of the ip address will prevent spoofing someone a bad score). If the player was about to lose, add ten more points to his score.

Eventually, the poor sports will get a huge "badboy" rating and nobody will have to play against them. I guess that this is the biggest complaint about chess servers.

[hgm]

2) Integrate secure timestamps as part of the protocol instead of an implementation by a separate program like timeseal.

How are you going to make that secure? If no separate program is used, and the protocol is public, how can you prevent people writing a client that abuses the protocol for time cheats?

[sje]

2) Integrate secure timestamps as part of the protocol instead of an implementation by a separate program like timeseal.

How are you going to make that secure? If no separate program is used, and the protocol is public, how can you prevent people writing a client that abuses the protocol for time cheats?

No system can be totally secure. But it is possible to design a system which, for the vast majority of end users, is too difficult to bypass.

Also, there are countermeasures that the server can use to identify suspicious timing behavior; i.e., probably falsely reported lag.