The London Perl and Raku Workshop takes place on 26th Oct 2024. If your company depends on Perl, please consider sponsoring and/or attending.

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.