Welcome to selectparks

Mail Form
Artist Ts

art mods
art games
location based games
political games
open source games
mobile games
browser games
sex games
performance instruments
digital imaging

standalone games
mods HL Q3A UT03 UTO4
mobile Games J2ME

free engine database
tech books
tutorials and support

email lists

delicious RSS


Free Software Game Development Intensive at the ITU, Copenhagen
Posted on Sunday, January 15 @ 01:32:32 CET by julian

Art Games

In 2005 I gave a 1 month intensive workshop in game development at the Technical University of Copenhagen (ITU).

Around 30 students attended in total, and 7 games were produced. Only a few of the students had programming or 3D modelling skills so the first week and a half was entirely comprised of class-wide technical instruction before throwing them straight into the game-design stage. The last 2 weeks were spent producing projects in groups which were then compiled as standalone executables.

My own sneaky project throughout all this, was to see if it was possible to give a game development workshop using only open-source software to students that had (in general) never even poked a stick at the stuff.

While it had it's bumps things went surprisingly well. This was our development kit:

Mepis Linux
The Gimp

Initially I was a little worried that students would run away screaming from the KDE Linux Desktop, but within a few hours most were getting around it just fine (strange as it may sound, adaptation to the OSX desktop for Windows users has been much harder work in past courses).

Instructions in the use of Blender were fairly intensive (6-7 hour days), but at the close of two weeks most were comfortable working with the modelling environment and were developing game-logics and interactivity using the in-built logic editing tools or directly in Python itself. Free to come up with whatever they please, they drew up designs and were ready to go. As usual many of these designs were completely unrealistic, wanting to produce a teeming Mecca of gameplay in just two weeks.

Together we took The Axe of Kindness to their storyboards, I gave a mandatory pep-talk and they all dived into production.

Here's what came out at the other end.


The BeamBot team's design was not ambitious in their desire to produce a big game, but on the level of implementation, it was truly stretching the programmatic limits of what is possible using the Blender game engine. This however didn't stop them diving deep into the Python API, resulting in a highly original approach to collaborative multi-user gameplay. The BeamBot team really wanted an arcade flavour to their project, and to make it playable for two.

Implementing a network layer in Python was going to be far too much work, so they decided to make a two player game, for just one keyboard.

More than simply a shooter, each player in BeamBots is bound to the other with a beam which acts as both a 'net' for catching missiles and picking up items, and a lifeline. Missiles fired from Zeppelins, or bombs hurled from cannons can be caught in the beam. By working together players can position themselves to catch these projectiles, stretch the beam like an elastic catapult, and hurl it back at the assailant with a fire key.

Should they grow too far apart, the beam will snap, and each player is largely incapacitated. To recconect players must bump into each other, at which point the beam is reactivated and play can go on.

When the players are connected, the combined health of both players is distributed to each, so that if one player is extremely low on health they must re-join with the other player to survive and continue play.

As a spectator sport BeamBots really works; watching two people bungle their way into a symbiosis of intention and action is both hilarious and fascinating. A massive amount of work was done in scripts resulting in some technically advanced solutions to the problems their design offered.

Contact authors: milesten2000 [AT] yahoo [DOT] dk


Somehow, the SunRise team was completely impervious to The Axe of Kindness. Any attempt to un-supersize their design proved fruitless. They would blink and nod, but their eyes shone with The Infinite. That said, I'd come into class around 9am during the production phase and find one or two of the team still at their workstations - a dedication that resulted in an inspired, unique outcome.

Instead of four players in collaboration for a common goal, one player controls four different avatars, whose powers must be combined at the right place to lift the sun up from inside a hill.

SunRise plays a kind of a puzzle. Each of the avatars represents an element (Earth, Air, Fire, Water) and must use their innate powers to breach various obstructions in order for all avatars to meet and combine powers.

I assumed the team was going to have to get up to play with Python in order to be able to realise their design, especially as messaging between game entities was a big priority in their project. They took what they'd learnt working with the blender game engine, and went further, building state machines and a little messaging network without even touching scripts. I don't think anyone on the team even knew what a 'state machine' was at the time.

The game is resource intensive, but still playable. On entering the world you'll need to wait a minute or so for your machine to catch up with itself. If only they'd implemented a load screen it would all look quite normal!

Contact authors: ulrik [AT] limkilde [DOT] com

Web Based 3D Portfolio

Just a team of two worked on this project, which manifested as a design for an online walk-in 3D portal for third-party 3D content.

The web-plugin they were working with at the time wasn't up to scratch, so they couldn't actually implement the project in the browser, but it does run as a desktop application. The content the WB3P used to demonstrate their ideas was that of the other games in class, so they took on the task of curating this content in a virtual setting so that all games can be explored from a single application at a single site.

For just a team of two it was a big acheivement and demonstrates an idea that could be taken to some interesting places time permitting.

Contact Authors: anneh [AT] itu [DOT] dk

The AlienLogic team had a few internal difficulties and so split up fairly early on, resulting in just a team of two during crunch time. Regardless they were half way toward building a little swarm/artifical agent system for use in a space combat game and on the level of it's technical merit, did very well considering.

Contact Authors: nils [AT] itu [DOT] dk


The CheatIT team (IT standing for the Uni, 'ITU') wanted to situate the player in a position whereby they would be faced with the prospect of killing a classmate. This may sound a little senseless, but it was all in a very earnest attempt to inspire converstation on the game as a medium for exploring what is normally off-limts. To drive the point home, they situated this moral confrontation right outside the door of where I gave the class. Eery.

The original storyboard and game design was too ambitious, so they cut it back to a choose-your-own-adventure narrative in a 3D setting. However, it was all becoming a bit too much like a lab experiment for them, so they gave the player a seedy rationale..

From a technical perspective this project was full of clever workarounds to the problem of lacking a programmer; things like camera and scene switching were all handled very elegantly without touching a line of code.

Contact Authors: yoo [AT] itu [DOT] dk


It was during a day class on physics and dynamics that this team had an ephiphany. They wanted to make the evil twin of Katamari Damacy, they wanted to make the world's largest and roundest weapon. The Warball.

The premise of this game is simple, push the ball around the landscape trying to kill little soldiers as they attempt to return to the castle. You are their menace, the thing they most fear.

To abet the mood these guys actually came in with a giant casio synthesizer, and recorded an operatic rock anthem for their game, in class (complete with vocal track).

Their game, while aesthetically representative of a well known Southern Park, is extremely addictive in an eat-your-own-fist-with-desperation kind of way.

Contact Authors: pjosef [AT] itu [DOT] dk


The ITUnreal group had yet another ambitious game design (I should come up with an acronym for this); they wanted to reposition the building we worked in as the site of a seige, an infestation of killer robots. Bullets and guns proving useless, it was time for students to find another means of reclaiming what was rightfully theirs, and so they turned to water-pistols because Robots are electric.

They mostly pulled it off, in due course inventing a complete inventory and load screen:

A very convincing simulation of the ITU building:

And a very scary 'electricish' robot:

Sadly the robot in the screenshot didn't actually move in the final demo, but the team did put together a great set of animations for the beast, and also wrote a small chaser script with a placeholder robot in another demo showing how they intended it to perform in a final product.

ITUnreal has a small linear quest system, the player has to fulfill little quests sequentially, things like activating an elevator, finding an ID card, and yes.. also squirting these killer robots with water pistols.

Contact Authors: kofoden [AT] itu [DOT] dk

What is most interesting perhaps about this project is where it eventually led. While having lunch with a chap from M.I.T I showed him the game at which point he immediately decided we should recruit the team for an architectural simulation project whereby buildings, in this case the ITU, can be analysed by the ease in which people can escape the building during a crisis, like a fire for instance. They did go ahead and do this, writing a route logging system and the like for generating statistics on the building's 'performance' post play.
More on this 'scientific gaming' project another time however.


All downloads are the copyright of their respective owners. Contact about the course should be made by sending me an email with "ITU Project Cluster" in the subject.

No responsibility will be taken for any weird, or nasty things that happen to the user or their computer during the course of running any of these games! Most are really just proof-of-concept and very alpha (made in just 2 weeks).

All downloads are currently for Linux only and machines will require hardware graphics accelleration (eg NVIDIA, ATI cards with direct rendering). Windows binaries will come shortly as a few of the games need to be debugged and compiled for that platform. Games will be also be far from optomised - if things are running very slow, wait a minute.

To prepare for play you may need to make the binaries executable
('chmod +x /path/to/game', or RightMouse --> Properties --> Executable)

BeamBots 15.9M

SunRise 127M

CheatIT 32.4M

WarBall 9.8M

ITUnreal 26.5M

Related Links
· More about Art Games
· News by julian

Most read story about Art Games:
Adventures in the Second Person

Associated Topics

Art Games

Sorry, Comments are not available for this article.

All logos and trademarks in this site are property of their respective owner. The comments are property of their posters, all posts themselves belong to their respective owners.

You can syndicate our news using the file Photoshop CS6 keygen or SEO Blog
PHP-Nuke Copyright © 2005 by Francisco Burzi. This is free software, and you may redistribute it under the GPL. PHP-Nuke comes with absolutely no warranty, for details, see the license.
Page Generation: 0.09 Seconds