Games are programmed for the Volity system as modules, rather than stand-alone applications. This allows for much faster development, not just because there's less code to write, but because so many of the components necessary to create a fully functional networked computer game already exist, provided by one's module programming framework of choice, as well as the Volity network itself.

See the section called “The technologies of Volity” for a brief but more detailed tour through the alphabet soup of technologies mentioned in this list.

Since Volity standardizes its graphics and communication protocol across all the games it supports, a single Volity network account and a good client application allows a player to play every single well-programmed game on that network, regardless of what computer platform that player is using (or what platforms any of those game servers run on, for that matter). Note that this also reflects back on Volity's attractiveness for game developers, since it makes their games' potential audience as wide as possible.

In some ways, this is not unlike what a player experiences through game systems accessed by a Java-enabled Web browser, such as Yahoo! Games. However, the idea of variety extends beyond the concept of games, since an open system architecture means that people can create client applications specific to different computing platforms, with user interfaces finely tuned to the various play and communication tasks involved in using a game network. This can prove a much more satisfying user experience than performing everything through a Web browser window.

Again showing how Volity's features for developers and users are intertwined, the system's open nature plays a subtle role in the variety of games available to players: since (unlike closed systems like Yahoo!'s) any developer can create a game module and add it to the Volity network, the landscape of Volity games is ever-growing and always changing, and can prove as fun to continually explore as the games themselves are to play!

Jabber is an open instant-messaging (IM) standard. From the enduser's standpoint, a typical Jabber application works a lot like a client program used with one of the more popular (and proprietary) IM networks, such as AOL Instant Messenger or MSN Messenger. With both Jabber and these other systems, every user on the network (which usually operates as part of the world-wide Internet) has a globally unique idenitifier of some sort, and messages that users send one another, either person-to-person or in a group-chat of some kind, appear instantly to the receiver. In principle this isn't too different than ordinary email, but IM's central conceit is the notion of presence, where a description of the user's online status — such as "available", "idle", or "offline" — becomes available to any entity that asks, thus making continually updated user rosters (a.k.a "buddy lists") possible, letting users know which other users are around to receive their messages.

Jabber's uniqueness in the IM field (which is, admittedly, dominated by the aforementioned proprietary networks) comes from its completely open design. Unlike AOL or MSN, the Jabber Council^[1] publishes the core protocol where all the world can see, allowing programmers to build applications or IM code libraries that make use of it. Furthermore, the Council uses a request-for-comments (RFC) system, inviting the public at large to suggest and decsribe possible extensions to the protocol, which may then enter a period of review and, after time and proven usefulness, possible standardization.

This open paradigm also allows programmers, even ones with no affiliation with the core Jabber development team, to use the protocol — and the network that supports it — in all kinds of interesting ways. Most examples of programmer creativity in the Jabber world take the form of chat-client applications, which allow the users of various computer platforms (or cross-platform platforms, such as Java) to make use of Jabber's IM features in various ways. However, enterprising programmers can extend the protocol, adding features and and functionality beyond basic instant-messaging. And this brings us to Volity.

Volity uses Jabber — and its underlying, XML-based protocol, XMPP^[2] — as its one underlying communication transport. Jabber/XMPP (and the various standard Jabber extensions) cover enough ground to actually do most of the work for Volity. In truth, Volity's protocol is more a collection of guidelines on how to use someone else's protocol in order to get the job done, versus the collection of low-level message definitions one usually expects to see when reading about a communication protocol. (That said, Volity does possess those sorts of things too, in the form of XML-RPC calls — though these too get a free ride from Jabber, as the section called “XML-RPC” describes.)

SVG, which stands for Scalable Vector Graphics, is an XML-based standard for representing vector-based images. An SVG document describes all the points, lines, paths and shapes that make up an image; it's up to a separate viewing application to interpret this code into something visible. Examples of general-purpose SVG-viewing applications include Adobe's SVG Viewer plug-in for Web browsers, and the Apache XML Project's Squiggle stand-alone Java application.

Figure 1.1 shows an example of an SVG fragment, describing a playing card image.

<!-- "&#x2660;" is the XML character entity for the Unicode "spade" glyph. -->
<symbol style="fill: black" id="AS">
	<rect width="100" ry="10" rx="10" style="stroke: black; fill: white;" height="140" />
	<text y="110" style="font-size: 100; text-anchor: middle" x="50">&#x2660;</text>
	<text y="74" style="font-size: 10; text-anchor: middle; stroke: white;" x="50">jmac.org</text>
	<text y="15" style="font-size: 15" x="5">A</text>
	<text y="30" style="font-size: 15" x="5">&#x2660;</text>
	<text y="15" transform="rotate(180, 50, 70)" style="font-size:15" x="5">A</text>
	<text y="30" transform="rotate(180, 50, 70)" style="font-size:15" x="5">&#x2660;</text>
</symbol>	      
	    

While static SVG images are nice enough, giving users the ability to scale and transform them however they wish without loss of image quality, the real power of the language (as far as its game-playing potential is concerned) comes when it's partnered with the ECMAScript scripting langauge. This lets you use the DOM object model^[3] to treat the image as a collection of separate, individually-identifiable symbols (or "actors") that can follow a script in order to animate themselves and react to user input. When hosted over a network, this can make for highly dynamic, server-side graphical user interfaces that rival (and, some would argue, surpasses) ones makes with proprietary technologies in the same sphere, such as Macromedia's Flash.

Games running within the Volity framework use SVG and ECMAScript for all their graphical user-interface needs. A typical Volity client application will, for every game in which the user is currently involves, maintain one SVG viewport winow which contains the game's user interface. (Interacting with other people playing the game is a different matter, involving the use of core Jabber messaging protocols, and clients will typically manage such messages in other, simultaneous windows.) Note that some games can get along fine without using SVG at all; word games, for example, can be played wholly through a text-only interface, using nothing more complex than ordinary Jabber messaging. However, any Volity client, server, or game-toolkit software package must implement SVG before it can be considered complete.

The XML-RPC protocol defines a simple way for running programs to call functions defined elsewhere, often on completely different machines reachable over the Internet. (RPC stands for Remote Procedure Call.) In a nutshell, the protocol specifies how to send requests, which inlcude a function name and an argument list, to the receiver, as well as the responses that the caller should always receive back.

Volity uses XML-RPC as a catch-all technology to do everything too specific to the application of game-playing for handling by the general-purpose Jabber protocol. Fortunately, Jabber allows us to meet it halfway, providing its own standard for couching RPC requests and responses within Jabber messages^[5].

While the pattern is no doubt obvious by now, we'll nonetheless give a tip of the hat to XML in general. Volity gets away with calling itself a fully XML-based technology simply because all of its technological componenets — all the things mentioned in this section — are themselves XML applications.

As its name suggests, the bookkeeper's role in the Volity network involves managing all the game and players records generated by game activity. Whenever a game ends, the bookkeeper hears about it, taking note of who played, who won, what server hosted it, and the like. Thereafter, players can query the bookkeeper (directly through their clients, or indirectly through a website, as the section called “The Website” covers) to learn about that game. The bookkeeper also holds similarly queriable directories of all the system's known game servers and players.

In the network depicted by Figure 1.3, the bookkeeper has the JID bookkeeper@example.com. This is the Jabber address to which the network's game servers will send their records of completed games, and from which clients will receive information about the network's active games, player rankings, and other information. The bookkeeper is able to respond to all these requests by maintaining a connection to the Jabber server hosted on example.com (where it has the username bookkeeper, hence its particular JID)

A Volity game server is an automated process that knows how to play a game of some sort, and allows players to create tables where this game can be played. The game played at each table is overseen by another process under the game server's jurisdiction, called a referee, who handles all server-to-player (and player-to-server) communication for that particular game instance.

From the network's point of view, game servers do not actually host the game; like every other Volity component, it's simply another user-level node of the Jabber system. Rather, it listens for, and responds to, RPC requests from players (and may also handle other sorts of Jabber messages, such as personal chats, depending upon how its programmed). The most important of these is the new_table request, sent by a player that wishes to start a new table. When it receives this request, a server makes sure that all conditions for a new table are met (that it has enough computing resources to do so, for example, and that the player making the request isn't on any black-hole lists the server cares about), and then proceeds to create the table — which is simply a normal Jabber MUC^[6] (multi-user conference, or "chat room"). It then informs the player about the table's location (i.e. its JID, for every MUC on a Jabber network, even a temporary one, has its own unique Jabber ID), allowing the player's client to join. From there, the player may invite friends to join, or advertise the table's existence to the world, or even just summon up some computer-controlled bot players as instant opponents. (See the section called “An example Volity session” for an illustration of this activity in context.)

The distinction between game servers and their referees is subtle but important. Game servers listen for requests from the network at large, but don't really pay any attention to actual games being played, even at tables that it created. That's the job of the referee at each table, who pays full attention to that table alone, including the game currently in play there (if any). In fact, the referee is the game, to a great degree, since the current state of any table's game is known wholly by the referee, and it must describe the game individually to each player. Generally, it performs this by activating ECMAScript functions stored on the player's client, which in turn cause the client to modify something in its SVG-based visual display to the player.

The referee is also the target of communication from the client to the game, as when the player clicks on an image with an attached method. For instance, a game might have display a "Roll dice" button, or an animated image of the dice themselves, which, when clicked, send a roll_dice message to the table's referee. Typically, the referee would respond by determining the die roll, then sending to that player's client (or all players, if the roll isn't secret) an instruction to activate a ECMAScript function which displays the roll's result.

Any network entity capable of sitting at a Volity table and playing games is a player. Most players are humans, connecting to the network through specialized client applications. Like everything else on the Volity network, every player possesses a unique JID, the domain part of which reflects only the Jabber server they use to connect to the network, and says nothing about the game servers or bookkeper they use.

A player can also be a bot, which is simply a computer program that acts like a player. Volity makes no formal distinction between its human and machine players; just as with human players, bots accumulate their own permanent, publically-visible records as they play games, and can earn (possibly negative) reputations over time (as described in the section called “The Reputation System”).

A volity game module is an implementation of some game's ruleset, compiled into a game server plugin. Part of Volity's strength comes from the fact that game modules are relatively easy to create, since Jabber handles network and user management, and the higher-level Volity protocol takes care of UI handling and display. A module programmer need only implement the game rules, and create a suitable UI through creative use^[7] of SVG and ECMAScript documents.

The future may hold snazzy game construction kits, allowing people to put together Volity-ready games with even greater ease (though some programming skill will always be required). For now, though, Volity game programming is open to anyone able to learn there way around an existing toolset (such as the Perl modules and frameworks that the Frivolity reference implementation provides).

Volity networks, ideally, are self-governing, operating with minimal top-level human moderation. Some of this emerges from the architechture itself, with its natural resilience to cheating (see the section called “Cheating”). Volity's reputation system attempts to address the touchier issue of inter-player conflict, giving players a simple and easy way to express their opinion about other players. Thus lets each player on the system build up, over time, a reputation score that reflects what their past opponents have thought of them, and thus encourage a sort of beneficial prejudice in potential opponents regarding whether or not this person would be fun to play with.

The system takes its cue from similar reputation-scoring systems seen on places like eBay or PayPal. When a game completes, all players involved have an opportunity to give one another a reputation point, either positive or negative (or neutral), with implications described by Table 1.1. This number is meant to represent whether or not the player in question was fun to play the game with, and the likelihood that the scoring player would want to play another game (of any variety) with the same person. It not not mean to represent their skill level at that game, but rather how they conducted themselves while playing it.

As the table suggests, players can also assign reputation points to servers, as well as other players. If a player feels that a particular server plays is game exceptionally well, and offers a pleasant UI and speedy response to player input, then it deserves a point. Conversely, if a server doesn't seem to properly follow its own declared ruleset, or is miserable to use, or (worst of all) appears to cheat, then the disgruntled player is free to give it a negative point.

Reputation scores of both players and servers is public information. Players can use these scores to decide if a stranger is worth playing with, or if a game server is worth using.

The Volity Central website, beyond serving as a general information repository about the Volity system, also allows people to browse game and player records, create and manage player accounts, and bring new game servers to the bookkeper's attention. It uses fairly standard URLs for its various player services, so that "lazy" client applications can simply open a Web browser window in response to certain information requests from the user, such as looking up a player's profile.

These Volity Central services apply only to the main Volity network centered around the volity.net bookkeeper; other Volity networks must create, host, and run their own websites in order to receive similar functionality.

One of Volity's slogans is "Games for everyone", and, alas, the set called "Everyone" does wholly include the subset called "Jerks". While the reputation system (see the section called “The Reputation System”) tries to discourage bad behavior during game-playing, Volity's design makes it actively difficult for uncouth players to cheat.

This is largely accomplished by how the system's different components trust one another — or, rather, how they don't. First of all, all trust is invested in the bookkeper, at the network's center, as described in A matter of (no) trust: Why is there only one bookkeeper?. From there, game servers are given leeway to speak for themselves, sending cryptographically-signed game records about games that they've overseen. These are stored on the bookkeeper, and assumed to be valid and factual, but if the orginating server receives a negative repuatation, then this can flavor — and, in extreme cases, even nullify — all the records it created in the past.

Finally, and most importantly, clients are trusted as little as possible. A sane, non-cheating game server will never send a client any information that wouldn't be available to that client's player. For example, in a Poker game, a proper server will tell each client which card-face graphics to use in order to represent that one player's hand, as well as any cards face-up on the table, with not the slightest clue about what might lay in the draw-pile, or in the other players' hands. (And non-player game observers can't "look over the shoulder" of any individual player, either.) If it's discovered that a server acts otherwise, through either bad programming or malicious intent (such as always sending full card-information to the player with the JID sneaky-pete@example.com), then its reputation should suffer accordingly.

Clients are furthermore kept thin, and "dumb". Since they can play all compliant Volity games, they don't "know" anything about any game in particular; they simply display the graphics and text messages that servers send to them. Therefore, no amount of clever client-side hacking can ever give players an unnatural advantage over their opponents; you'll never see a "card hack" that lets you peek at your opponents' hands. Real cheating must take place server-side, and once such a server's villainous ways are releaved to the world, then avoiding it is as easy as not playing games hosted by that server (and giving it, and perhaps its owner, a swift kick in the reputation system on your way out the door). Conversely, a "clean" server with a good reputation is guaranteed to give its players a cheat-free experience, no matter who plays on it, or what clients they use.