Table

A Volity table is simply a multi-user chat where a game takes place. Participating in this chat is the game's referee, and all of its users, whether they are actively playing or merely observing.

A table is created by a parlor when it receives a volity.new_table RPC request from a user. Actually, the table's underlying MUC is literally created by the referee that the server creates first. The referee then joins the table and invites the user who made the original request. That player is then free to configure the table, and invite other users to join. The game will actually start when all users seated there declare readiness.

Only one game at a time can happen at a table, so at any time the table has a basic status of being either in play, or idle.

Tables and MUC roles

At the MUC level, the referee always possesses a role of "moderator" and an affilitation of "owner". Therefore, the referee can always be distinguished from the other uses by its unique affiliation.

The referee uses the Jabber-defined MUC protocol to adjust the roles of other users at the table:

• Whenever it recognizes a user as actively playing the game (either at the start of the game or later on), it grants moderator privileges to that user.
• When a user is no longer actively playing (either because the game ended or some other reason) it revokes moderator privileges, instead giving that user a MUC role of "participant".

As moderators, playing users have access to all the powers defined by the MUC protocol, including preventing observers from kibitzing (i.e. setting them to "visitor" and not "participant" roles) and booting and even locking out unpleasant users. We consider disagreements about the use of moderator privileges to be a strictly interuser problem, perhaps ultimately answerable to the reputation system.