NAME
Volity::Factory - A Volity bot factory.
SYNOPSIS
use Volity::Factory;
# Create a new factory
my $factory = Volity::Factory->new(
{
user=>'bob_the_factory',
password=>'secret',
host=>'volity.net',
resource=>'volity',
alias=>'volity',
ruleset_uri=>"http://example.com/my_game/",
ruleset_version=>"1.0",
}
);
# And there you go.
$factory->start;
# ... elsewhere ...
$factory->stop;
However, it is much more likely that you'll be starting a factory from the volityd
program than from within code. Here's how you'd launch the above factory from the command line (and without using a volityd
config file):
$ volityd -J bob_the_factory@volity.net/volity -G MyFactory::Class -p secret
DESCRIPTION
An object of this class is a Volity bot factory. 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. Factory 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:
- ruleset_uri
-
The URI of the Volity ruleset that this bot factory supports.
- ruleset_version
-
The version number of the ruleset that this bot factory supports.
- 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
andclass
. The latter should probably be the name of aVolity::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.
- startup_time
-
Returns the time (in seconds since the epoch) when this palor started.
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
AUTHOR
Jason McIntosh <jmac@jmac.org>
COPYRIGHT
Copyright (c) 2003-2006 by Jason McIntosh.