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.

Immersive Virtual Reality Is All About the Turing Test

While the technical specifications and modes of interaction with modern computers and gaming systems continue to advance, we are still quite a long way from graphics, sound, and user interface that provide a life-like experience. Even so, a properly programmed virtual world could be extremely immersive if the focus was in the right place. Imagine a game world where it is impossible to tell which characters are controlled by real humans. If the ugly troll might be your cousin, and that swamp rat could be your neighbor's pet, while the friendly paladin might simply be a computer character, the world suddenly has some moral ambiguity.

The key to a new breed of virtual reality is the Turing test. Simply put, the idea is that a true test of artificial intelligence is whether you can interact with it and a human being and not know which one is the computer.

Most of the immersive games up to this point have primarily focused on hack and slash. World of Warcraft (or a decade ago Diablo II) allowed people to create a virtual personality and go around looking for evil to slay and treasure to liberate. Other virtual worlds focus only on the social aspect. Services like Second Life let people set up homes and environments and communicate via avatars. The web site, Virtual Worlds Review, lists almost 30 such games.

Some single player games have started to introduce the idea of players choosing their character's morality. Most notable in this genre are Black & White and Fable. Both have sequels in the works. These games were novel in their approach to the characters' interaction with the world. Stealing, killing civilians, and other "evil" acts are allowed. The game tracks a characters' behavior and changes accordingly.

An evil character in Fable has grown horns.

While it is a start for games to apply their own interpretation of ethics, having the world apply real, natural consequences seems even more interesting. If you have no idea whether that troll is computer- or human-controlled, attacking it without provocation becomes much more problematic. Say you kill a real player's troll character. He may have friends or family in the game or even the ability to be resurrected. Those characters could either seek revenge or go through the legal system and seek justice.

This would lead to many new types of game play. Being a thief stealing from both "real" and artificially intelligent shopkeepers adds a new level of potential danger. Some characters might specialize as bounty hunters, tracking down the miscreants. Even the details of a world could vary to increase player interest. Some communities could be frontier towns with only personal revenge type justice, similar to the Old West. Others would be more "civilized" and have complete systems of laws and consequences. Racial prejudice from place to place or outright war would add further interest.

All of this could be realized with existing technology if only people were allowed to play a wide variety of roles in the virtual world and the computer characters became smart enough to blend in with the humans. If Turing is satisfied, the game world would be very satisfactory.