Jason McIntosh > Frivolity-0.7.1 > Volity::Player

Download:
Frivolity-0.7.1.tar.gz

Dependencies

Annotate this POD

CPAN RT

New  1
Open  0
View/Report Bugs
Source  

NAME ^

Volity::Player - Volity players, from a referee's perspective.

DESCRIPTION ^

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.

USAGE ^

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.

METHODS ^

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.

Basic attributes

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.)

jid

This player's full JID.

basic_jid

The player's JID, minus the resource part.

nick

This player's MUC nickname.

referee

The Volity::Referee object of the table this player is at.

is_bot

1 if this player is a referee-created bot, 0 otherwise.

seat

The Volity::Seat object this player occupies. undef if the player isn't sitting or missing.

state_seat

A Volity::Seat object that's most appropriate to use when sending state to the player, preventing suspension-mode state-snooping. See the send_game_state_to_player method documented in Volity::Game.

is_missing

1 if the player has abruptly vanished while sitting at an active game, 0 otherwise.

Volity RPC methods

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.

start_game
end_game
player_ready ( $ready_player )
player_stood ( $standing_player, $seat )
player_sat ( $sitting_player, $seat )
suspend_game ( $suspending_player )
resume_game
player_unready ( $unready_player )
seat_list
required_seat_list
timeout
timeout_reaction
table_language

Other methods

call_ui_function ($function, @args)

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. Luckily, 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...)

update

Updates the player about the game state and seats, sending it the proper volity RPCs.

SEE ALSO ^

AUTHOR ^

Jason McIntosh <jmac@jmac.org>

COPYRIGHT ^

Copyright (c) 2005-2006 by Jason McIntosh.

syntax highlighting: