Playing Games with Python and Volity.Net

A few years ago my friends and I used to get together just about every Friday night to play board games. Our old standby was Risk in all its variations. One week, however, a guy brought over a new card game he had bought called Fluxx by Looney Labs. It was fast-paced and fun and quickly became a regular at game night.

The game Fluxx on Volity.net

Then about a year ago I met someone who serendipitously mentioned that she played Fluxx. She introduced me to a free online version hosted by Volity.net. It's a great implementation of the game, complete with the original artwork and decks from two different versions of the game.

Volity.net, though it has largely failed to do so, aspires to build an online community for gamers interested in traditional card and board games played by computer. They have developed an infrastructure using the Jabber network for interested programmers to develop their own games. The great thing is that the implementation is open source and very expandable. There are several games I would love to see electronic versions of, and having quite a bit of programming experience, I decided to take a look.

While the games available on Volity are fairly impressive, I unfortunately found their documentation and infrastructure underwhelming. The following is a log of the steps I followed in trying to use their Application Programming Interface (API). Hopefully it will not only serve as a critique of the Volity service but also be helpful to others considering using it to implement their own games.

I found a developers' guide on the Volity wiki. The first thing to do was decide what language to use. Volity has libraries for Perl and Python. I have a passing familiarity with both, but decided to go the Python route in order to learn it better. After a bit of searching, I headed to another wiki page to download the following libraries: volity.tar.gz, games.tar.gz, zymb.tar.gz, and volityd.py from another wiki (I didn't feel like dealing with a Subversion server.) Some people will recognize these as *nix compressed files, which they are indeed. They need to be ungzipped and untarred in a working directory.

Next, rather than trying to implement a whole new game off the bat, I decided to modify an existing sample in order to get a feel for the API. I chose the classic, and very simple, Rock Paper Scissors (called RPS for short in the Volity docs).

Following the tradition of many a shoddy programmer, the best documentation I eventually found was in a source code file, volityd.py. It explains how to get things running. It's a bit complicated (fortunately OS X includes Python, so I did not need to install it), but basically there is the concept of a Parlor. It is a specialized Jabber client that knows about one type of game and lets users sit down at a Table to play that game. Making a new game means creating a new Python class that extends the class volity.game.Game.

To get things going, I made a simple change to games/RPS.py, commenting out the logic that decides the winner so that white was always victorious. In order to test my changes I had to register my Parlor with Volity's servers. This was a simple process on the Volity web site. Note that if I had created a whole new game rather than just modifying an existing game, I would also need to register a RuleSet document and a User Interface.

I fired up Gamut, the Java-based user interface application for Volity.net. Gamut requires a Volity user ID, which I had already created for playing Fluxx. After logging in, I chose Game/New Table At... and typed in my Volity/Jabber ID for my Parlor. The RPS interface came up. I could add a bot (computer player), take a seat, and play the game. As white I won every time, sort of.

Apparently the user interface code has its own logic for determining the winner. The Game (ie referee) knew that I won and registered that fact with the server, but the UI would show the result of the original implementation. This is obviously far from ideal, especially in a distributed system.

At this point my initiative was about spent. I explored the UI implementation for a time. It basically requires creation of an SVG file to create the graphics and Javascript to implement interface interaction. Even though for this game the interface file is surprisingly short and straightforward, dealing with two more technologies was a bit more than I was willing to bite off at the moment.

For others more adventurous than myself, I did locate the following resources. Within Gamut, selecting Game/Game Info... and clicking the UI tab tells the location of the current user interface SVG file. This can be downloaded and modified. Then choosing Game/Select New Interface... can load a local SVG file. There is also a UI tutorial available on the Volity web site, and an SVG Testbench application.

I give the Volity developers a lot of credit for creating a usable infrastructure with many good game implementations. It is also great that they have made it open source and tried to lure further developers. Unfortunately, the system fails in the way many open source projects do. The documentation is hard to locate and often incomplete, and the implementation is exceedingly complex. Granted, if I dedicated several days to understanding the intricacies of the system, I'm sure it would all be very straightforward, but in reality how many people are going to take the time to do that before getting started on a project?

In addition, to be fair, my choice of Python may have been non-optimal. The Volity reference implementation is in Perl, so that language may be better documented. There is also a developer forum available on the web site that I did not take advantage of. Overall, I found Volity.net a good effort but disappointing for new development.