Free Software Game Development Intensive at the ITU, Copenhagen
Posted on Sunday, January 15 @ 01:32:32 CET by julian
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:
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
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
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.
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)