ICS from scratch

[jshriver]

As mentioned, I'm out of work and have time on my hands. Writing an open source ICS from scratch has been a dream for years and I honestly want it to be clean and dedicated to computer chess (but doesnt have to be).

I want to stick to the ICS (FICS/ICC) protocol so xboard and the myriad of existing software can work transparently.

So I'm thinking purely backend. I'm an old school guy so I generally do C/Perl.

But since I want this to be something any new person can contribute to, I'm leaning toward Java (due to run anywhere), and an itch to even try C# due to MS creating a Linux version.

For "possible" future contributors, what would you like? What features would you like?

From the start I'm aiming PURELY for regular chess, little/no desire for variants like bughouse/etc. Then again I do dig Shogi but that's above current goals.

Then again open source so if someone wants to tackle that they can

Curious of your thoughts!
-Josh

[ZirconiumX]

I would actually consider something like Python, using Twisted as its backend. That should save a decent amount of low level hackery, and you can use things like the python-chess module, too.

Something that definitely should be in a server like this is encryption support. If I remember correctly (HGM, correct me if I'm wrong?) XBoard supports a -icshelper which it can use, so we can write a helper utility to hide the encryption. It's not like we're in the 1990's, where it provides a significant overhead.

[hgm]

I wonder if it is wise to cling to the ICS protocol. This protocol is basically a legacy from the time that Telnet was the dominant tool for accessing other sites on the internet. As soon as graphical interfaces replaced ascii terminals on PCs, graphical ICS clients like WinBoard were developed. But for general internet access people switched to web browsers. The need to download dedicated clients for ICS play is in practice a large barrier. That FICS is still popular is mostly due to the fact that people can connect with it through Jin, a browser-based (Java) client.

Also note the original ICS protocol with its 2D ascii boards was extremely client-unfriedly, so that ICS implemented a second format (as 'protocol within a protocol') for communicating with dedicated clients ('board 12'). Now FICS and ICC each have their own dedicated methods for communicating with clients for the more advanced functions, (such as updating seek graphs), in addition to the legacy protocol.

If you have to support multiple protocols, it could be better to adopt a protocol that makes browser-based access for human players and observers easy. In addition to that you can support the board-12 protocol plus a few legacy ICS commands used by the existing ICS clients like WinBoard. It would be an advantage to have a different protocol for connecting clients that could possibly support engines as for connecting human players, as using the same protocol for both would make cheating so much easier.

Of course I am mainly interested in this for the purpose of general variant support. For orthodox Chess there will be near-zero demand for new server software. Note there already exists Lichess ( https://github.com/ornicar/lila/ ) as open-source project. Note that the largest part of an ICS deals with user identification, opponent selection, game-database management, user communication and such general tasks. Only a very tiny portion is game-related code (such as parsing moves and checking their legality). Supporting 100 variants instead of 1 would probably drive up the amount of needed code by only 1% or so (if done properly).

[kbhearn]

Of course I am mainly interested in this for the purpose of general variant support. For orthodox Chess there will be near-zero demand for new server software. Note there already exists Lichess ( https://github.com/ornicar/lila/ ) as open-source project. Note that the largest part of an ICS deals with user identification, opponent selection, game-database management, user communication and such general tasks. Only a very tiny portion is game-related code (such as parsing moves and checking their legality). Supporting 100 variants instead of 1 would probably drive up the amount of needed code by only 1% or so (if done properly).

Mostly the argument against supporting 100 variants is barely anyone plays the ones you have, so supporting 100 instead of 5-10 spreads the pool of players that will play them thinner and noone can find a game in the vast majority of variants. This makes it frustrating for a user who picks a variant they think they'd like to try and just can't find a game and discourages them from trying other variants. It's important for a public server to restrict variants to a reasonable number of popular ones and expand carefully (possibly even removing already implemented ones that turn out to be too unpopular).

I agree with most of your points though - expanding lichess or forking it if your vision conflicts with the current developers being the right way forward for a modern open source chess server, etc.

[Evert]

Mostly the argument against supporting 100 variants is barely anyone plays the ones you have, so supporting 100 instead of 5-10 spreads the pool of players that will play them thinner and noone can find a game in the vast majority of variants. This makes it frustrating for a user who picks a variant they think they'd like to try and just can't find a game and discourages them from trying other variants. It's important for a public server to restrict variants to a reasonable number of popular ones and expand carefully (possibly even removing already implemented ones that turn out to be too unpopular).

This goes both ways, of course. If particular variants are not wide-spread, there will be fewer people playing them. If there are fewer people playing them, there will be less incentive to support them.
I don't think having the option for variants would hurt, and if you were to implement "blitz", "rapid", "tournament" time controls as distinct categories, then adding another variant would basically be the same as having another category. The problem of not having an opponent available can be ameliorated somewhat by having bots available.

All of this of course does not change the fact that interest in chess variants is a niche interest, a sub-section of people who have an interest in chess to begin with. People seem dedicated though.

[hgm]

Well, I did not want to imply that we actually need to offer 100 chess variants on every operating server. This is about development of software, though. And I would want the software to be configurable to support as many variants as possible, preferably every conceivable variant. Then actual users of the software (i.e. ICS operators) can decide which variants they want to host.

For example, I am sure a reasonably large number of players would be happy to use a server that would only offer Chu Shogi, and use it enthousiastically. As since 81Dojo stopped offering Chu Shogi, there is no place anywhere in the world where you can play real-time Chu Shogi games. OTOH, if you started another website that would only offer Chess, no one would care, and you would have great problems to attract any players.

[jdart]

It's a nice idea.

I'd favor something like Java (or maybe Go) because you are not going to get the kinds of issues HGM was recently struggling with in the iCS code. Both languages have good support for networking and multithreading.

--Jon

[gbtami]

If you really like to stick to FICS protocol you can start from https://bitbucket.org/wmahan/fatics/wiki/Home