As I have mentioned a couple of times recently that I have been enjoying playing the Raspberry-Pi-hosted "Alternate Universe" MUD (AU). As well as bringing back all sorts of happy memories it has prompted me to think about possibilities for using a Raspberry Pi as more than just a generic Linux server. Not that using a Pi as a generic Linux box is a bad thing, but I have several of those kicking around already. To me, the Raspberry Pi offers a really interesting mix of low price, decent capabilities, low power, good connectivity and general "hackability", in a way that's not provided in quite the same way by anything else.

Duncan Jauncey experimented with porting a textual, multi-user system to a Raspberry Pi and has seen it hold up really well to the kind of ebb and flow of users found on the net. The Alternate Universe software must be pretty well written - it's mostly at least ten years old but you can't tell from the outside. Some of the stuff in it such as the rolling Shakespeare "performances" and the riddler just make me smile. However, the idea of the MUD system dates back much farther than that, to a time before the internet, a time of minicomputers, modems and dial-up bulletin boards. In such a setting it made complete sense for the whole "world" of a multi-user game to take place on a single server, and for people to connect to that server to play. This idea is seen in almost all multi-player games. Even popular modern games such as Minecraft and Club Penguin have the same model. The major difference which has been introduced in the meanwhile is the idea of choosing servers. For world-wide games with huge numbers of players, no single server would cope, so the game is cloned onto a growing number of servers, and players choose which one to connect to.

This model helps with scalability to some extent, in that it enables large numbers of players to experience the same game, but it does not scale the game itself. Each clone of the game still has to run on a single server - making the game bigger means every server has to be bigger, too. To look for a way to solve this problem, we don't have to look very far. The most used computer system in the history of mankind is the world wide web. It's so ubiquitous that many people assume that it "is" the internet. The web has achieved this massive scale not by building bigger and bigger servers, each of which holds the whole web, but by spreading it out onto an enormous number of much smaller servers, each responsible for a little bit of the big picture.

So, my thoughts led me to musing on connecting a network of Raspberry Pi boards. Not just the ones on my desk, but others out there across the internet. Each Raspberry Pi is so cheap, so flexible, and so easily networked that spreading a single system across an increasing number of boards should not pose any particular hardware problems. There are enough people who have worked on multi-box networked systems for businesses and other organisations that the programming should not be too tricky either.

The bit that is tricky is coming up with a really good way for these systems to collaborate. Just like the web it has to be tolerant of participating machines coming and going from the network, and of wildly varying versions and development approaches. Learning from the problems of the web it also needs to be secure enough to avoid being misused, even if its job is just to run a relatively simple multi-player game.

First things first, it seems very likely that this system (just like the web, Minecraft and Club Penguin) will need to have some form of client software. AU uses a generic telnet protocol which assumes no intellgence in the client other than the ability to pass keystrokes in and display characters out. This has all sorts of problems: it's fairly greedy of bandwidth, often taking a whole network packet for a single character and it means that everything (logging in, command parsing, re-showing descriptions, player communication and everything else) has to be done on the server. This in turn makes it very difficult for a user to "move" from one server to another. Minecraft and Club Penguin both use custom communication protocols aimed at solving some of these issues, but neither of them do much to address the issue of moving from one server to another. Although the client software provides tools to help with this, using them means stopping the game. The web, on the other hand uses a generic protocol (HTTP) which is relatively easy for any server to implement and, through the use of hyperlinks, makes moving from one server to another a transparent process.

While it is obviously possible to play games using just a web browser, that's not the direction I'm thinking of. What I have in mind is perhaps more like jabber/XMPP where the protocol is organised around communication rather than resource access, and the client is responsible for a certain amount of housekeeping.

I'm really moving into speculation now, but I'm imagining a game where as well as interacting with players, bots, scenery, puzzles, items and so on on a particular server, you also have options to "travel" to other servers where the setting will be different, and the rules of the universe might not even be quite the same. This fits quite nicely with the sci-fi setting of a game like AU. In the current AU implementation, I understand that even though it has multiple locations and ships which move between them, all the locations are on the single server and part of a single notional "map". I'm really intrigued by the idea of this sort of game, but where all the ships, planets and so on can be on completely different servers scattered around the internet.

I'll have a think about this and see if I can come up with a way of implementing enough of a prototype to see if this idea of a federation of Raspberry Pi servers joining together to make a big game might actually work.