NAME

Volity::Server - A Volity game parlor.

SYNOPSIS

 use Volity::Server;
 
 # Create a new parlor
 my $server = Volity::Server->new(
				 {
				  user=>'bob_the_game',
				  password=>'secret',
				  host=>'volity.net',
				  resource=>'server',
				  alias=>'volity',
				  game_class=>'MyGame::Class',
				}
				);

 # And there you go.
 $server->start;

 # ... elsewhere ...

 $server->stop;

However, it is much more likely that you'll be starting a server from the volityd program than from within code. Here's how you'd launch the above server from the command line (and without using a volityd config file):

$ volityd -J bob_the_game@volity.net/server -G MyGame::Class -p secret

DESCRIPTION

An object of this class is a Volity parlor. (It's still called Volity::Server due to historical tradition.) As the synopsis suggests, it's more or less a black-box application class. Construct the object with a configuratory hash reference, call the start method, and if XMPP authentication worked out, you've got a running server.

You generally never need to use this class directly, no matter what you're doing with Volity. Parlor objects of this class are created and managed for you by the volityd program, so unless you want to get into the guts of the Volity system you may be more interested in volityd.

If your main goal involves creating Volity games in Perl, I direct your attention to Volity::Game, which is far more relevant to such pursuits. The rest of this manpage is probably of more interest to folks wishing to perform deep voodoo with these libraries.

CONFIGURATION

When constructing the object, you can use all the keys described in "Accessors" in Volity::Jabber, for this class inherits from that one. You can also use any of the following keys, which also function as simple accessor methods after the object is created:

game_class

The Perl class of the game that this server will use. It will pass it along to all the referee objects it creates. See Volity::Referee and Volity::Game.

bookkeeper_jid

The JID of the bookkeeper this server will use for fetching game records and such. Defaults to "bookkeeper@volity.net", which is probably exactly what you want.

contact_email

The email address of the person responsible for this server.

contact_jid

The Jabber ID of the person responsible for this server.

bot_configs

A list of hashrefs containing bot config information. The keys of each hashref include username, host, password and class. The latter should probably be the name of a Volity::Bot subclass.

volity_version

The version number of the Volity protocol that this server supports.

visible

Whether or not this parlor is visble to Volity's game finder. Set to 1 if it is, or 0 if it should go unlisted.

admins

A list of JIDs that are allowed to call this server's admin.* RPCs.

OTHER METHODS

start

Starts the server.

stop

Stops the server, and furthermore calls stop on all its child referee objects, if it has any still hanging around.

graceful_stop

Stops the parlor, but doesn't affect any live referees.

referees

Returns a list of all server's currently active referee objects. The server will take care of adding and removing referees from this list as they come and go.

You can set this if you want, but it will probably break things and you will be sad.

startup_time

Returns the time (in seconds since the epoch) when this palor started.

wall ( $message )

Every referee will "speak" $message (with the preamble "Server message: ") into its table's groupchat.

NOTES

Automatic roster acceptance

When an object of this class receives an XMPP request, it will automatically and immediately . If you don't like this behavior, consider creating a subclass that overrides the jabber_presence method. (That said, I can't think of a reason you'd want to have such an antisocial game server...)

SEE ALSO

Volity

AUTHOR

Jason McIntosh <jmac@jmac.org>

COPYRIGHT

Copyright (c) 2003-2006 by Jason McIntosh.