Free volity software for linux

Volity::Seat is a Volity seat, containing some players.

SYNOPSIS

# From within a Volity::Game subclasss code:
my @seats = $self->seats;

# Or, given a Volity::Player object:
my $seat = $player->seat;

# Now tell the seat they just picked up the Three of Clubs:
$seat->call_ui_function("draw_card", "3C")

An objects of this class represents a seat at a Volity table. Volity players who are actually playing a game sit in seats, and referees address game-specific RPC calls to seats, not to individual players. See the main Volity documentation for more information about the seat concept: http://www.volity.org/wiki/index.cgi?action=browse&id=Seats

USAGE

As a game programmer, you need never create, modify, or destroy these objects yourself; that is all handled for you by the other objects that make up a Frivolity-run table, particularly the referee (see Volity::Referee). However, several methods of Volity::Game, the module you subclass to create your own Perl-based Volity game, will return objects of this class. Several crucial functions of communicating with a games players involve calling methods on these objects, including the all-important call_ui_function method (described below).

Your Volity::Game subclass must define some variables that assist the referee in seat creation, particularly the seat_ids and required_seat_ids class variables. If you wish to extend this class for your game, you can speficy a Volity::Seat subclass to use through Volity::Games seat_class method. All these are described in detail within Volity::Game.

Volity::Player is a Perl module for Volity players, from a referees 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 refs 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 players departure results in the objects 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.

Volity::WinnersList is Perl class for Volity game record winners lists.

SYNOPSIS

Heres code you might see in a Volity::Game subclass implementing a game where there is one winner and a bunch of losers, the latter of whom are all effectively tied for second place (we assume that the methods called in the first two lines are defined elsewhere):

if ($self->game_has_been_won) {
my ($winner, @losers) = $self->get_winning_seat_order;
$self->winners->add_seat_to_slot($winner, 1);
$self->winners->add_seat_to_slot(@losers, 2);
$self->end;
}

And heres what you might see in a subclass defining a score-using games where each player has a discrete ordinal place, and ties and ties are not possible (again assuming the presence of some magic methods defined somewhere else in the subclass):

if ($self->game_has_been_won) {
my @ordered_seats = $self->get_winning_seat_order;
for (my $index = 0; $index winners->add_seat_to_slot($ordered_seats[$index], $place);
}
$self->end;
}

Attached to every Volity::Game-subclass object is a WinnersList object, accessible through the game objects winners method. When a game wraps up, it should use the methods listed in this document to place the tables seats in a winning order before calling the end method. The referee will then use this information when it builds the game record to send to the Volity bookkeeper.

METHODS

slots

Accessor to the raw list of winner slots. Returns an array of anonymous arrays, each representing a single slot, in winning order: the one at index [0] is the winningest slot, and the one at [-1] is the losingest. Each of these slot-arrays contains a number of Volity::Seat objects.

add_seat_to_slot ($seat, $position)

Adds the given seat to the winners list at the given position. Note that the position is expressed in game-rank, so the first-place position is 1, not 0.

If there are already seats at the current position, the given seat will share the slot with them. As a shortcut, you can add several seats at once to the same slot by passing an arrayref of seats as the first argument.

seats_at_slot ($position)

Returns the list of seats the given position in the winners list. Note that the position is expressed in game-rank, so the first-place position is 1, not 0.

Gamut is the Volity projects first graphical client application, written in Java and usable on any Java-friendly computer.

Gamut project is still alpha and more useful to developers than players, but rapidly approaching a more generally usable beta.

Volity is a framework for developing online multiplayer games. Servers are written in Perl or Python, and the user interface for each game is written in a combination of SVG and ECMAScript. The client automatically downloads the proper UI for any game, allowing you to play games such as Hex, Fluxx, and Aquarius without any further intervention.

While most current games are board and card games, many different game types can be implemented and deployed within the Volity framework.