"An unspecified mixture between a wishlist and unfinished code" A discussion document on the future development of Free Software game servers Josef Spillner <dr_maux@users.sourceforge.net>, June 17 2001

Introduction I got lot of input during the last months concerning online multiplayer games. Not all of them were of direct interest for me, but most presented cool ideas which could become interesting once one has more time to implement them. My work of the past weeks has mainly covered the client side of things, thus it seems strange to read that document here - however, my plans target in both the client and server directions, and only the interaction of both makes up a working games network. The examples given here are somewhat biased towards GGZ (what a wonder), but I'll try to keep them as general as possible, so the ideas may be applied to other servers too. Please note that most paragraphs deal with a yet-to-be-invented substance, while others present already working applications. I won't differentiate between these both to prevent prejudices.

Interactive Online Gaming (1) KGGZ, the GGZ core client for KDE (2) Chess, derived from BSD's chessd (3) Server representation with two channels The above pictures present the three main components of the GGZ gaming concept, which is similar to most others which offer more than one game. You have a central client application (here: KGGZ), the individual games (here: Chess), and a server (here: ggzd). The server itself may also be splitted (it is very common to create new processes for every launched game), but this is not visible to the user and may be changed everytime as long as the server-client protocol isn't affected. In this example the player connects the the server, logs in and (optionally) negotiates. After selecting a specific room which is linked to a certain game type, he can chat with others, and launch a game or join a running one. Here is already space for alternatives: It is possible to have the chat rooms not linked to the games, or no rooms at all. The disadvantage would be that the players who share the same interest are mixed with those who don't. Omitting the chat is also possible, however the (rather limited but nevertheless present) experience has shown that it's only half the fun there. So a question could be what to provide beside the games and the chat - maybe a team challenge calendar or a guild center? This configuration is accompained by bot players (AI), a chat bot, and the possibility to interact with those.

Enhancing the server (4) Extended server (5) Stalker, using FCGP graphics The first server had only a channel for its own data which it sends to the client (blue circle), and TCP/IP games (orange circle). I'm talking of channels here instead of connections because it might be possible that a game uses multiple connections within one channel. Now there are some extensions: Another TCP channel, this time secured with Transport Layer Security (TLS), a UDP channel for fast (realtime) UDP games (displayed in brighter orange) like Stalker or bzFlag, and the light blue server control channel which is used by the client application to receive additional information about statistics, meta servers or site-specific details. Only some hours ago, when playing around with the TLS integration, I realized that it's probably not bad to assign "roles" to a server: core A main loop, one process, might be multi-threaded game Firing up one process per game and handle dead games meta Querying other game servers about supported game types and players who are logged in replication Transmit data from server to server, e.g. player database trust Handle encryption and security stuff chat Chat, private messages, broadcasting across rooms, announcement messages visual Could be a httpd server showing server statistics control Administrative control module (dangerous!) Much of this hasn't been considered yet to be necessary - but from the user's (player's) point of view, it makes no sense to get a login at a server, being redirected to another one on the next connection and refused there because he is only registered at the first one. Player data is, however, very sensitive data - even it's only a username/password list, one has to use strong encryption and authentication among the servers. The meta servers are a less critical concept, as already proven in FreeCiv which is used quite well. In fact, many concepts may be re-designed once the number of (potential) players has increased. A recent look at msn.zone.com showed that there were more than 100.000 users online - regardless whether this number is true or not, such a mass cannot be handled by one server alone. Reassignments of players should be done automatically. The Arianne RPG developer mentioned a very interesting concept of "load-balancing" without interrupting the actual game, which shouldn't be too hard to implement, because the game specific side of this red-alert moment is to be coded by the game programmer anyway. Both together are called the "neighbourhood relationship" of game servers. They are different in their Message of the Day (as identification to the player), the games running there, and the policy (e.g. maximum number of player per game), but then again they are equal - sharing one user and highscore database (which may and should be distributed nevertheless), sharing the flow of logging in, playing and logging out, and sharing a common service name. Online game statistics are hardly available today in our free world, but this is most likely to change, and will be standard before 2002 for many games.

Global measurement I haven't addressed issues like global highscores yet, because they deserve an extra paragraph. This is also a relatively new area for game creators - easy to implement in proprietary games (I guess), but we speak about real coding here, and this makes the task a bit harder. (6) KMines with global highscores (7) Arkanae, multiplayering in Java (8) MiMaze, an MBone-compatible iMaze The only concept which is currently known to be (and working) is to use HTTP queries like in KMines, posting variables to a script which posts them into a database. Only registered players should see their names in the highscore (avoiding the lowering of the score by malicious guest players who use the same name), and this does again require a world-wide valid user database, using server replication. This gets even more interesting with really platform-independent games like those written in Java (Arkanae as an example). It's very interesting that the new global net structures (hint: IPv6) are faster integrated by open source games than proprietary ones, with MiMaze or other distributed communication concepts already available to the players in various forms.

Finish Feel free to contact me (dr_maux@users.sourceforge.net) to discuss about the concepts. Please tell me whether you want your comments to be included here, either as cites or as influencing ideas. I intend to put this document, once ready, somewhere at the LGDC so everybody may get an overview. Here's a link list for the screenshots above, in case you're interested: (1) KGGZ (2) Chess (5) Stalker (6) KMines (7) Arkanae (8) MiMaze http://ggz.sourceforge.net http://chessd.sourceforge.net http://stalker.sourceforge.net http://kmines.sourceforge.net http://www.babeloueb.com/arkanae http://www-sop.inria.fr/rodeo/MiMaze This document is (C) Copyright 2001 Josef Spillner. It may be modified and redistributed under the conditions of the GNU Free Documentation License.