Volity::Player - Volity players, from a referee's perspective.
An object of this class represents a Volity player present at a table. The referee creates one of these objects for every player who comes to that ref's table. The player might not actually play the game (i.e. sit in a seat), but is nonetheless recognized by the referee as a potential game player and table presence.
In certain circumstances a ref may choose to keep an object for a given player persistent, even after that player leaves the table, while other times the player's departure results in the object's destruction. Generally, it just does the right thing.
You should never need to create or destroy player objects yourself; the referee object takes care of that. However, there are a number of methods defined by Volity::Referee and Volity::Seat that return player objects, so you may find yourself interacting with them anyway.
Volity::Game subclasses refer to seats more often than to individual players, since most game interaction takes place at the seat level.
This class defines two kinds of object methods: accessors to basic, informational attributes about the player, and triggers to send RPC methods to the player's client.
Consider these methods as read-only accessors to attributes that the referee sets. (Well, you can write to them if you'd like, but I can't predict what might happen if you do, so don't.)
This player's full JID.
The player's JID, minus the resource part.
This player's MUC nickname.
The Volity::Referee object of the table this player is at.
1 if this player is a referee-created bot, 0 otherwise.
The Volity::Seat object this player occupies. undef if the player isn't sitting or missing.
A Volity::Seat object that's most appropriate to use when sending state to the player,
preventing suspension-mode state-snooping.
send_game_state_to_player method documented in Volity::Game.
1 if the player has abruptly vanished while sitting at an active game, 0 otherwise.
These methods all send volity-namespaced RPC methods to the player's client.
Generally, you shouldn't have to call any of these yourself. The ref takes care of all this stuff.
Sends the RPC request "game.$function(@args)" from the referee to the player's client.
Note that in most cases,
you'll actually want to call UI functions on the seat level,
not on individual players.
the Volity::Seat class defines this same method,
which works in the same manner.
(To tell you the truth,
it just mirrors the
call_ui_function call to all of the player objects it holds...)
Updates the player about the game state and seats, sending it the proper volity RPCs.
Jason McIntosh <firstname.lastname@example.org>
Copyright (c) 2005-2006 by Jason McIntosh.