Free games perlwar software for linux

Games::PerlWar is a Perl variant of the classic Corewar game.

This is a sparring program, similar to the programmed reality of the Matrix.
It has the same basic rules, rules like gravity. What you must learn is that
these rules are no different than the rules of a computer system. Some of
them can be bent, others can be broken. - Morpheus

PerlWar is inspired by the classic http://www.corewar.info/|Corewar game. In this game, players pit snippets of Perl code (called agents) against each other in order to gain control of the vicious virtual battlefield known as... the Array.

GAME PARAMETERS

Size of the Array

The number of cells that the Array possesses. Each cell can hold one agent.

Agent Maximal Size

The maximal length, in characters, of an agent. If an agent is or becomes larger than this limit, it automatically segfaults upon execution.

Game Maximal Number of Iterations

The maximal number of rounds that can be played before a game is declared over.

Games::Cards is a Perl module for writing and playing card games.

SYNOPSIS

use Games::Cards;
my $Rummy = new Games::Cards::Game;

# Create the correct deck for a game of Rummy.
my $Deck = new Games::Cards::Deck ($Rummy, "Deck");

# shuffle the deck and create the discard pile
$Deck->shuffle;
my $Discard = new Games::Cards::Queue "Discard Pile";

# Deal out the hands
foreach my $i (1 .. 3) {
my $hand = new Games::Cards::Hand "Player $i" ;
$Deck->give_cards($hand, 7);
$hand->sort_by_value;
push @Hands, $hand;
}

# print hands (e.g. "Player 1: AS 2C 3C 3H 10D QS KH")
foreach (@Hands) { print ($_->print("short"), "n") }

$Hands[1]->give_a_card ($Discard, "8D"); # discard 8 of diamonds

This module creates objects and methods to allow easier programming of card games in Perl. It allows you to do things like create decks of cards, have piles of cards, hands, and other sets of cards, turn cards face-up or face-down, and move cards from one set to another. Which is pretty much all you need for most card games.

Games::Euchre::AI is a Player API for Euchre card game.

This class implements a skeletal Euchre player programming interface. Subclasses can be created quite easily as interactive interfaces or AI computer players.
If you wish to write your own computer player, I recommend you start with Games::Euchre::AI::Simple. If you wish to write your own human interface, I recommend you start with Games::Euchre::AI::Human.

CLASS METHODS

new

Create and initialize a new Euchre AI. This object is implemented as an empty hash. Subclasses may wish to use this hash for state storage.

INSTANCE METHODS

Actions

The following methods are called in the course of the game where the AI (or human) has to make a decision. The state of the game is always passed in a hashreference. The following fields are always available:

name is the name of the current player. This is useful for output messages.
names is a hash relating player number to player name for all four players.
debug is a boolean indicating if we are debugging game or the AIs. Your AI may wish to provide verbose output if debugging is going on.

bid STATEHASH

Choose trump or pass. The relevent details of the current state of the game are provided in a hash reference. Here is an example of that data structure:

{
name => Player 1,
names => {1 => Player 1, 2 => P2, 3 => P3, 4 => Fred},
number => 1,
turnedUp => KH,
passes => 1,
ourScore => 2,
theirScore => 4,
winScore => 10,
hangdealer => false,
notrump => false,
hand => [JS, QH, 9S, KC, AD],
debug => false,
}

turnedUp is the suit and value of the card on the top of the blind. This will be undef on the second round of bidding.

passes says how many people have passed so far
hangdealer is a boolean saying whether the hang-the-dealer optional rule is in effect

notrump is a boolean saying whether the no trump optional rule is in effect
This function must return one of: H, D, C, S, N, HA, DA, CA, SA, NA, or undef
N means no trump, A means alone, undef means pass. Not all of these are legal at any given round! Use the isLegalBid() method below if you are unsure.

pickItUp STATEHASH

If this is called, you are the dealer and someone called trump. Choose which card from your hand to discard in exchange for the top card of the blind. The relevent details of the current state of the game are provided in a hash reference. Here is an example of that data structure:

{
name => Player 1,
names => {1 => Player 1, 2 => P2, 3 => P3, 4 => Fred},
number => 1,
turnedUp => KH,
trump => H,
bidder => 2,
weBid => false,
usAlone => false,
themAlone => false,
hand => [JS, QH, 9S, KC, AD],
debug => false,
}

This method should return the 0-based index of the card to trade for the turnedUp card. Namely, this in the index of the hand array for the card that you choose.

playCard STATEHASH

Choose which card from your hand to play on this trick. The relevent details of the current state of the game are provided in a hash reference. Here is an example of that data structure:

{
name => Player 1,
names => {1 => Player 1, 2 => P2, 3 => P3, 4 => Fred},
number => 1,
trump => H,
bidder => 2,
weBid => true,
usAlone => false,
themAlone => false,
trick => 2,
ourTricks => 0,
theirTricks => 1,
ourScore => 2,
theirScore => 4,
winScore => 10,
played => [10H, 9H, QC],
playedBy => [2, 3, 4, 1],
hand => [JH, AH, AS, KS],
debug => false,
}

playedBy is an arrayref of numbers of the players in the order they will play. Without this, the alone possibility makes it hard to tell who played what.

Any needed information not stored here (like who was the dealer, what was the turn-up card, what happened in the first trick) is YOUR responsibility to collect and store in your instance.

This method should return the 0-based index of the card to play. Namely, this in the index of the hand array for the card that you choose.

Java Games project is a collection of simple games that are compiled into Java applets and meant to be played online in a Web browser.

Currently the collection contains four games: XO World (similar to tic-tac-toe, but with lines of 5 on a 10x10 board); 100 Mack (guess the random combination of 4 images out of a set of six); Memory (flip 2 plates at a time to find matching pairs); and Tetris.

Games::3D is a package containing an object system for (not only) 3D games.

SYNOPSIS

use Games::3D::World;

my $world = Games::3D::World->new();

$world->save_to_file( $filename );

my $loaded = Games::3D::world->load_from_file( $filename );

my $thing1 = $world->add ( Games::3D::Thingy->new( ... ) );
my $thing2 = $world->add ( Games::3D::Thingy->new( ... ) );

$world->link($thing1, $thing2);

Games::3D::World provides you with a container class that will contain every object in your game object system. This are primarily objects that have states, change these states and need to announce the states to other objects.

The Games::3D::World container also enables you to save and restore snapshots of your objects system.

Basic things that you object system contains are derived from a class called Games::3D::Thingy. These can represent physical objects (buttons, levers, doors, lights etc) as well as virtual objects (trigger, sensors, links, markers, sound sources etc).

You can link Thingys together, either directly or via Games::3D::Links. The links have some more features than direct linking, which are explained below.

This package also provides you with Games::3D::Sensor, a class for objects that sense state changes and act upon them. Or not, depending on the sensor. Sensors are primarily used to watch for certain conditions and then act when they are met. Examples are the death of an object, values that go below a certain threshold etc.

State changes are transported in the object system with signals.

Games::Poker::TexasHoldem is an abstract state in a Holdem game.

SYNOPSIS

use Games::Poker::TexasHoldem;
my $game = Games::Poker::TexasHoldem->new(
players => [
{ name => "lathos", bankroll => 500 },
{ name => "MarcBeth", bankroll => 500 },
{ name => "Hectate", bankroll => 500 },
{ name => "RichardIII", bankroll => 500 },
],
button => "Hectate",
bet => 10,
limit => 50
);
$game->blinds; # Puts in both small and large blinds
print $game->pot; # 15

$game->call; # Hecate puts in 10
$game->bet_raise(15) # RichardIII sees the 10, raises another 5
...

This represents a game of Texas Holdem poker. It maintains the state of the pot, whos in to what amount, whos folded, what the bankrolls look like, and so on. Its meant to be used in conjunction with Games::Poker::OPP, but can be used stand-alone as well for analysis.

Games::Irrlicht is a Perl module that use the Irrlicht 3D Engine in Perl.

SYNOPSIS

package MyGame;
use strict;

use base Games::Irrlicht;

use Games::Irrlicht::Constants; get EDT_SOFTWARE etc

# override methods:

The Why

When building a game or screensaver displaying some continously running animation, a couple of basics need to be done to get a smooth animation and to care of copying with varying speeds of the system. Ideally, the animation displayed should be always the same, no matter how fast the system is.

This not only includes different systems (a PS/2 for instance would be slower than a 3 Ghz PC system), but also changes in the speed of the system over time, for instance when a background process uses some CPU time or the complexity of the scene changes.

In many old (especial DOS) games, like the famous Wing Commander series, the animation would be drawn simple as fast as the system could, meaning that if you would try to play such a game on a modern machine it we end before you had the chance to click a button, simple because it wizzes a couple 10,000 frames per second past your screen.

While it is quite simple to restrict the maximum framerate possible, care must be taken to not just "burn" surplus CPU cycles. Instead the application should free the CPU whenever possible and give other applications/thread a chance to run. This is especially important for low-priority applications like screensavers.

Games::Irrlicht makes this possible for you without you needing to worry about how this is done. It will restrict the frame rate to a possible maximum and tries to achive the average framerate as close as possible to this maximum.

Games::Irrlicht also monitors the average framerate and gives you access to this value, so that you can, for instance, adjust the scene complexity based on the current framerate. You can access the current framerate, averaged over the last second (1000 ms) by calling current_fps.

Frame-rate Independend Clock

Now that our application is drawing frames (via the method draw_frame, which you should override in a subclass), we need a method to decouple the animation speed from the framerate.
If we would simple put put an animation step every frame, we would get some sort of Death of the Fast Machine" effect ala Wing Commander. E.g. if the system manages only 10 FPS, the animation would be slower than when we do 60 FPS.

To achive this, SDL::App::FPS features a clock, which runs independed of the current frame rate (and actually, independend of the systems clock, but more on this in the next section).
You can access it via a call to current_time, and it will return the ticks e.g. the number of milliseconds elapsed since the start of the application.

To effectively decouple animation speed from FPS, get at each frame the current time, then move all objects (or animation sequences) according to their speed and display them at the location that matches the time at the start of the frame. See examples/ for an example on how to do this.

Note that it is better to draw all objects according to the time at the start of the frame, and not according to the time when you draw a particular object. Or in other words, treat the time like it is standing still when drawing a complete frame. Thus each frame becomes a snapshot in time, and you dont get nasty sideeffects like one object beeing always "behind" the others just because it gets drawn earlier.

Time Warp

Now that we have a constant animation speed independend from framerate or system speed, lets have some fun.

Since all our animation steps are coupled to the current time, we can play tricks with the current time.

The function time_warp lets you access a time warp factor. The default is 1.0, but you can set it to any value you like. If you set it, for instance to 0.5, the time will pass only half as fast as it used to be. This means instant slow motion! And when you really based all your animation on the current time, as you should, then it will really slow down your entire game to a crawl.

Likewise a time warp of 2 lets the time pass twice as fast. There are virtually no restrictions to the time warp.

For instance, a time warp greater than one lets the player pass boring moments in a game, for instance when you need to wait for certain events in a strategy game, like your factory beeing completed.

Try to press the left (fast forward), right (slow motion) and middle (normal) mousebuttons in the example application and watch the effect.

If you are very bored, press the b key and see that even negative time warps are possible...

Ramping Time Warp

Now, setting the time war to factor of N is nice, but sometimes you want to make dramatic effects, like slowly freezing the time into ultra slow motion or speeding it up again.

For this, ramp_time_warp can be used. You give it a time warp factor you want to reach, and a time (based on real time, not the warped, but you can of course change this). Over the course of the time you specified, the time warp factor will be adapted until it reaches the new value. This means it is possible to slowly speeding up or down.

You can also check whether the time warp is constant or currently ramping by using time_is_ramping. When a ramp is in effect, call ramp_time_warp without arguments to get the current parameters. See below for details.

The example application uses the ramping effect instead instant time warp.

Event handlers

This section describes events as external events that typically happen due to user intervention.
Such events are keypresses, mouse movement, mouse button presses, or just the flipping of the power switch. Of course the last event cannot be handled in a sane way by our framework.

All the events are checked and handled by Games::Irrlicht automatically. The event QUIT (which denotes that the application should shut down) is also carried out automatically. If you want to do some tidying up when this happens, override the method quit_handler.

The event checking and handling is done at the start of each frame. This means no event will happen while you draw the current frame. Well, it will happen, but the action caused by that event will delayed until the next frame starts. This simplifies the frame drawing routine tremendously, since you know that your world will be static until the next frame.

Games::Quakeworld::Query is a class for querying QuakeWorld servers.

SYNOPSIS

use Games::Quakeworld::Query;

my $QWQ = Games::Quakeworld::Query->new("quake.server.com", "27500");
my %info = $QWQ->getinfo(); # obsoleted, use $qwq->get("") instead
print "Server uses map: ".$qwq->get("map")."n";

Hello, this is Games::Quakeworld::Query, a perl module. It is a class made for querying Quakeworld (Quake 1) game servers and getting their informations, that is map name, players, hostname and etc.