In either case, players perform configuration by sending certain Jabber-RPC requests to the table's referee. Conversely, players are informed about changes to a table's configuration through RPC requests sent from the same referee.
All volity tables have several attributes that are always configurable, regardless of their loaded ruleset. Players can configure these attributes using certain RPC requests in the core volity
namespace. At present, the protocol defines the following configuration requests:
Rulesets are free to define any sort of configuration functions in their ruleset APIs as they see fit. However, a ruleset should be carefully specific about which functions are meant for configuration, and which are intended to be called once a game is underway.
These functions operate like any other game-specific RPC request, existing within the game
namespace.
As an example, see the best_of
and no_ties
functions in the rock, paper, scissors API.
A referee can implement as many or as few of a ruleset's configuration methods as it wishes. (Should we define some sort of disco-based query pattern for asking a server what sorts of config it supports?) (Would be easier to just allow server config variables, which the game module reads. This puts more work on the game designer -- he has to write code to constrain his own config system -- but it avoids issues with possibly inconsistent configurations.)
When a player succeeds in changing any part of a table's configuration, several things happen.
volity.language( JID, language)
, and rulesets can define as many more as they need.
volity.*
calls, then the referee adjusts how it responds to disco? queries, as defined by the game finder page.