This is the product of about two laptop battery charges (~2.5 hours), and one hour to polish, fix the odd bug and package .. so in total it’s about a ~6 hour game. It’s based on the garbage compactor scene from a particular space opera that had it’s heyday in the late 70’s and early 80’s. You could imagine it was one of the ideas that was considered, then discarded, before the early arcade developers went “Nah, we should do a 3D X-Wing game with vector graphics. That would be much cooler”.

You are the (inexplicably) green hero. You play with the arrow keys. You move bits of junk (grey) such that you can jam the compactor before it crushes you. Some bits of junk (white), are too large to move. There is only one level and no sound.

Play it here (Java applet, requires the Java plugin that you most likely already have installed).

No related posts.

Phobocore is a two-player hotseat game, where the aim is to capture all the planets onscreen by shooting them. It’s sort of a cross between Asteroids and Risk/Galcon, with a respectful nod to open field overhead shooters like Robotron, Bezerk or Gauntlet.

Download Phobocore (v.09 for Windows & Linux) [10.3 mb]

The experience of creating this game has been quite enlightening so far. It really got me thinking about aspects of game design I hadn’t thought deeply about. I threw around lots of ideas relating to ‘resources’ and ‘defenses’, particularly thinking about how RTSs like Starcraft require balance in play style between defense building, offensive maneuvers and resource gathering. Good players must multitask and proiritize to get the upperhand on their opponents. Key questions like “Should captured/neutral/enemy planets be solid objects or unhindering ?” occupied more than one dinner time conversation, bearing out all the ways these would changed the game. I had great fun testing the effect of different game rules, and how these changed the dynamics of the gameplay (with huge thanks to my long-suffering girlfriend for playtesting. The next best thing to writing an AI player ). If you are keen to fiddle with these game rules yourself, you can throw various flags in the phobocore.py sourcecode to test how these variations change the play style required to win.

I also spent considerable time tweaking things like fire rates and the “planets-held to ammo recharge rate” ratio to try and make the game somewhat fun. It works pretty well for players that are equally matched, but much like Galcon, once one player gets an edge, it can be hard to recover and things are over pretty quickly.

Big features I’d love to add in the future: an AI compurer player for single player mode, and maybe network play. I need to work on the collision detection, improve the graphics, add background music, and add a help screen / tutorial screen and slap on a license (probably GPL for code and Creative Commons for audiovisual assests).

Have fun & feedback is, as always, welcome !

Here’s the README.txt

┏━┓╻ ╻┏━┓┏┓ ┏━┓┏━╸┏━┓┏━┓┏━╸
┣━┛┣━┫┃ ┃┣┻┓┃ ┃┃  ┃ ┃┣┳┛┣╸
╹  ╹ ╹┗━┛┗━┛┗━┛┗━╸┗━┛╹┗╸┗━╸
Copyright Andrew Perry, 2008, 2009.

A two player hotseat game of screen domination.
It's pink vs. blue.
Boys vs. girls.

┃: GAMEPLAY :┃

Phobocore is a a simultaneous two player game. The goal is to capture
 as many planets as possible.
* You capture planets by shooting them - eventually they will turn to
  your colour.
* If you shoot a planet enough, it becomes locked to your colour -
  these planets cannot be re-captured by the enemy.
* The more planets you capture, the faster your ammo refills (orange
  bar). The more locked planets you hold, the more powerful your
  bullets become.
* You can fly through neural (white) or enemy planets. You cannot fly
  through your own planets.
* Shooting the enemy freezes them momentarily, however they also
  absorb your bullets for their own ammo store.
* Powerups occasionally appear - these give you more ammo, and can
  provide the vital edge you need to capture more planets than your
  opponent.
* The red bar goes up the more planets you lock. Once you have locked
  30 % of the planets on screen, you win.

┃: CONTROLS :┃

Player 1 (pink, left ammo bar): W,A,S,D and space
Player 2 (blue, right ammo bar): Arrow keys and right-CTRL

┃: OPTIONS :┃

Commandline options:

-f          run the game in full screen mode

┃:   TIPS   :┃

Early on, every bullet counts. Fire accurately and efficiently.

It may seem frustrating at first, since you can't shoot very fast.
Early in the game, aim to quickly but efficiently capture as many
planets as possible, and pick up powerups if you can. Don't waste
ammo locking too many planets early in the game - it's more about
quantity not quality at this stage. As you capture more planets,
your fire rate will go up.

Once you have a reasonable fire rate established, start focusing
on locking planets too. This will increase your bullet power,
meaning you can also capture/lock planets faster.

Take opportunities to steal any weak planets owned by your opponent
(the smaller ones) with a quick circular spray of bullets - this
will seriously impact on your opponents fire rate, frustrating
their efforts to capture/steal/lock more planets.

Try not to fence yourself in. Keep in mind that planets you capture
become blockades for you, but become open space for your opponent.
Rather than spraying a whole 360 degree circle of bullets to capture
all the planets in your vicinity, try doing 270 degree sweeps,
leaving yourself a exit small hole of neutral or enemy planets.

No related posts.

(Thanks to Mike Kasprzak of Sykhronics Entertainment for hosting this monstrosity. Respect to the other Fathers and Mothers of Towlr’s)

No related posts.

[youtube b56mNpfsMeY]

LD48 #13 : pansapiens timelapse

One screenshot every 5 mins, taken with the script (screenshot.sh):

#!/bin/sh
OUTDIR=/home/perry/timelapse
DISPLAY=:0.0
import -window root -display $DISPLAY $OUTDIR/$(date +%F_%R.%S).png >/dev/null 2>/dev/null


using the cronjob:

0,5,10,15,20,25,30,35,40,45,50,55 * * * * /home/perry/timelapse/screenshot.sh


And converted to a video by running the script (timelapse_convert.sh):

#!/bin/sh
# convert pngs to jpgs and scale down the size
mogrify -format jpg -scale 840x526 *.png
# convert jpgs to video
# will fail if there are any frames of different sizes (geometry)
# also, need to remove "blank" frames if the screensaver went off
mencoder "mf://*.jpg" -mf fps=4 -o timelapse.avi -ovc lavc -lavcopts vcodec=mpeg4:vbitrate=800


No related posts.

Bad Ass Frog Escapes from LA

The Hollywood-script-worthy Backstory

The year it 2010. You are the last Frog in LA. Your name is Kurt Russell, but you are no relation to the actor, and you’ve never met him.

Controls

Arrow keys to move.
Space to restart after the game ends.

The Game

(if it looks broken, you are probably using Internet Explorer. Try the applet here)

Downloads

Download standalone version of Badass Frog Escapes from LA for:

• Windows
• Linux
• Mac OSX
• Mobile Phone version (MIDP 2.0, largish screen phones, 240×291) … short link: http://is.gd/aDRQ
• Source code of the Applet version, ready to be loaded into Processing
• Source code of the mobile phone version, ready to be loaded into Mobile Processing

Related posts:

1. Belated Ludum Dare #14 “entry”

simplemenu-alpha0.tar.bz2

Requires pygame and rabbyt. It’s under the MIT license. I’m regarding this as alpha, since it’s incomplete and poorly tested, (although I am using successfully it in a small game already).

simplemenu, as it’s unimaginative name suggests, is a simple set of classes to automatically lay out a vertical column of ‘buttons’ on the screen, with click and rollover effects. Like the about simplest sort of GUI you could imagine. I made it because I felt like I needed a quick and brainless way to make simple “Start”, “Options”, “Quit” menus at the title screen of games, and during a Ludum Dare 48 hour competition, you don’t want to have to mess around with the details of things like this.

There is nothing I’d call game logic in the classes. There is demo code under “if __name__ == ‘__main__’:” … again this is what I would call ‘functional documentation’, not useful game logic. It’s all still quite ugly.

No related posts.

No related posts.

I had various dramas throughout the 48 hour competition, namely two electricity outages … this is not the code I spent most of my time on, but I’m actually happy it all worked out the way it did.

The game is written using batari Basic v1.0. I learnt a lot by reading the included sample code, and the excellent batari Basic manual. I also used the online PlayerPal 2600 Sprite Editor to draw the sprites.

Ways to play:

• All platforms: Play the game on this page (below the fold) in the embedded JStella applet
• Window, Linux, Mac: download the ROM and run it in Stella ($ sudo apt-get install stella on Debian/Ubuntu).
• Windows, (maybe Linux): Download this zip archive which contains the windows version of Stella and The Siege of von Danken Tower ROM, which is compatible with Keeyai’s Compo Game Loader
• Atari 2600 VCS: For the definitive von Danken Tower experience, you should burn it onto an EEPROM and play it on your Atari 2600 VCS (YMMV. AtariAge may help).

You can also look at the ugly source code.

The Siege of von Danken Tower

Sorry, your browser doesn’t seem to support applets.
Maybe just run the rom using Stella instead ?

(this applet seems a little flaky on some platforms. Works for me on Windows Vista in IE7. Works without Reset button in Firefox 2).

Controls: Left and right arrows, space to fire.

Gameplay

Move your character between the pile of stone blocks on the right and the foundations of the von Danken Tower on the left to build the tower. If you are holding a block, you can throw it at the chariot of the Gods. Watch out for the bolts of light the Gods may throw down at you !

Once you have built the tower, you must destroy the chariot. It will become redder with every hit, before being destroyed. Once you destroy the chariot with a completed tower, you will advance to the next level.

You can sustain only three hits by a bolt of light before dying. Your health state is indicated by your colour.

In the tradition started by Yar’s Revenge … here is the cheezy back-story.

The Story

There are two stories surrounding the famous “Siege of von Danken Tower”. One an allegory for the other.

In ancient times, a warrior named Eric was tasked by the Gods to build a great tower. They hovered above him, and quoth “Build us a mighty Tower, in the name of von Danken”. Eric, unafraid, set about the task of hualing huge stone blocks across the plain to the site where the great Tower of von Danken was to be built. Eric, worked for days, but eventually, he stopped to rest. But the Gods were impatient andmalevolent Gods, and despite the Tower being their request, they made sport of Erics’ toil. They threw bolts of light at him, and ordered him to continue building. Eric, a proud warrior, would not stand for this kind of treatment, even from the Gods. He picked up the block beside him an threw it at their flying chariot. The war had begun.

Millenia later, in modern times, a programmer recieved a message from the aether. I simply stated, “Build a video game featuring ‘The Tower’. Quickly”. He did not know who was telling him to build “The Tower”, but a story from his childhood, buried deep, arose in his mind. He decided to tell the story of the von Danken Tower, a secret family tale passed down from his great-great-great-great-great-great-great-great-great-great grandfather, and until now never widely shared. But mysterious, inter-dimensional beings were not pleased at having their role in the development of human civilisation revealed. Electrical distrubances, power failures and other strange occurances plagued the project. Would the story of the great von Danken Tower ever be told ? Would the the Tower ever be completed, or would the aliens forces reign surpreme in their information war on the human race ? It is up to you to ensure they do not !

Related posts:

1. Belated Ludum Dare #14 “entry”

You can download it here [Mondrian_by_pansapiens_LD11.zip] (Windows and Linux compatible).

More details later. Right now, I have to sleeeeeeeep.

= Mondrian =
A game based on the visual art of Piet Mondrian.
Copyright Andrew Perry (pansapiens), 2008.
Licensed under the GPL version 3 (http://www.gnu.org/licenses/gpl.html).

Created for Ludum Dare 11 – Minimalism (18 – 20th April, 2008).

= Installation =
Unzip the package, run mondrian.exe (Windows) or mondrian.py (Linux & other platforms).

Usage: mondrian.py [options]

Options:
-h, –help show this help message and exit
-r, –random Play a randomly generated level
-e, –editor Launch in level editing mode

Dependancies (only required on Linux, or when running from source):
Python (2.5), Pygame (1.8), Rabbyt (0.8.1), PyOpenGL.

= Gameplay =

Goal: Clear the play area (aka Mondrian painting) to achieve pure white minimalism.
Click on the black beams with the mouse pointer to make then vanish.
Coloured squares expand when not in contact with a beam.
Squares of the same colour vanish when they contact.
Square of opposite colour do not vanish when they come in contact.

= Controls (game mode) =

Click with the mouse pointer.
Press ‘r‘ to restart the current level.

= Controls (level editor) =
Objects are inserted at the current position of the mouse pointer. Otherwise, gameplay is the same.

Up/down key – insert vertical beam
Left/right key – insert horizontal beam
z – insert red square
x – insert yellow square
c – insert blue square
v – insert grey square
s – save level to file “saved.pickle” in the working directory
l – load level from file “saved.pickle”
backspace, del – clear all objects from the level

= Some legalese =

This program is free software: you can redistribute it and/or modify

it under the terms of the GNU General Public License as published by

the Free Software Foundation, either version 3 of the License, or
(at your option) any later version.

This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the

GNU General Public License for more details.

You should have received a copy of the GNU General Public License
along with this program. If not, see .

Related posts:

1. Belated Ludum Dare #14 “entry”

Obviously, the first thing to do is install Python and all the required dependencies (eg Pygame, etc) on a Windows box (or Virtual Machine) and make sure your game will actually run. If it won’t run, you may need to tweak your Python to be more cross-platform. For simple games this mostly boils down to making sure all the sys and os module calls that use file paths use os.path to manipulate the path strings, rather than string concatenation. Paths in Linux use a forward slash “/”, paths in Windows use a backslash “\”, and some other platform may do something else; os.path deals with all this for you. I went through this process with shoodar (v0.11) and got it running under Windows with all the dependencies installed (eg Pygame, PyOpenGL, Rabbyt 0.81).

Now comes the ‘fun’ part – building the executable (and collecting associated dll’s and data files) for your game. There are a few tools for doing this on Windows:

Freeze

Comes with Python, but I didn’t test it.

cx_Freeze

cx_Freeze — I got this working to create a Windows distribution of shoodar after a bit of playing around. One advantage is that it doesn’t require a dedicated distutils script like py2exe. A downside is that it seems to generate lots of files in addition to the executable, and doesn’t automatically know to copy over data directories containing sprites & sounds, etc. You need to remember to do that part manually.

I downloaded the Windows installer for cx_Freeze (cx_Freeze-4.0b1.win32-py2.5.exe) and installed it. I unzipped the shoodar source into a folder called shoodar. In the shoodar source directory, I created a folder called dist. Then, at the Windows command prompt, in the shoodar folder, I typed:

c:\Python25\Scripts\freeze --install-dir dist shoodar.py

I then copied the shoodar\data folder into the dist folder.

The brand spanking new shoodar.exe executable was in the dist folder. It ran, and appears to function correctly.

py2exe, with PyMikes PySetup.py

py2exe — seems to be the most popular choice among Pygamers. There are a few wrapper scripts floating around at pygame.org.

The py2exe tutorial gives a nice example of how it’s done using a simple distutils setup.py script. I used py2exe with PyMike’s PySetup.py script. The PySetup.py script is a distutils setup.py script on steroids, tailored for packaging up Pygame games. It also worked for packaging shoodar, which also uses Rabbyt 0.81 (and hence PyOpenGL) without any special tricks.

I edited the obvious stuff at the top of the PySetup.py script in the shoodar directory (This included adding data, the directory which contains shoodars sprite files, to the extra_data list. I set dest_folder to the empty directory dist. I also added pygame.locals to the extra_modules list, but I probably didn’t need to. I left icon_file empty, since I don’t have an icon yet).

In the shoodar folder at the command prompt, running:

c:\Python25\python.exe PySetup.py

did the trick. Py2exe doesn’t generate nearly as many files as cx_Freeze … not that it’s really a big deal, but it looks less overwhelming in the file manager.

I had one problem with some (apparently) Linux specific code .. the use of os.path.dirname(__file__) which I changed to os.getcwd(). It’s worth noting that even after fixing this bug, py2exe builds failed until I removed the build (generated by py2exe) and dist directories and started with a clean slate. So, I’d suggest removing the build directory and the dest_folder between py2exe build attempts.

Next episode: Wrapping up the distribution in an executable Windows installer package (or How to make an evil “next”->”next”->”next”->”Finish” Windows installer for a Python game).

No related posts.