The summer season

A new month, and the start of various new things around here. One is a slub residency with sketchpatch, where we write processing sketches and bounce them between us in a game of “sketch tennis” that lasts a month. We already have a bunch of sketches and it’s only the first day.

I’m also taking part in a collaboration with Marloes de Valk and Aymeric Mansoux involving social games, text adventures and far distant planets. This is quite a new direction for me, and it’s exciting to be forging new alliances. A bit more explanation coming soon!

On the groworld front, we are also doing some design and further development surrounding permaculture, in what could become quite a big game project. Again – more on that as it happens.


Here is another experiment with html5 canvas, this time working with Lina Kusaite to try and bring some of the groworld illustrations to life. There is nothing particularly ground breaking happening at the moment, we are just testing some things. You might need to reload the page for it to work properly, I still have to figure out some caching issues:

In my last post I forgot to mention a very big reason why javascript is important – the fact that it’s very easy to access via the browser’s “view source” feature. It’s a pretty simple thing to take a site and modify it on your own machine with just a browser and a text editor. I wouldn’t be surprised if this is the most common entry point for new programmers at the moment.

Wilderness in html5 canvas

My exploration of web programming continues, this is a rewrite of the wilderness game world from haxe/flash into javascript and html5 canvas. There are some plans to make this into something more resembling an actual game, but at the moment it’s serving as a good test as I get to grips with these new fangled bits and pieces.

Leaving out all the hot air about small companies beginning with “A”, here are my thoughts on canvas for making games compared with haxe/flash:


  • Javascript is much nicer for me than Haxe due to dynamic typing and it’s comparative closeness to Scheme.
  • Immediate mode for graphics allows you to draw a scene how you want with your own containers. The retained mode MovieClip object in Flash is an annoyance for me. Hopefully similar things happen in web graphics as it did in 3D with the early DirectX retained mode, which was eventually abandoned.
  • I’ve started using Chrome for development – the javascript debugger is one of the best I’ve come across, and the Firefox one is pretty good too. When using haxe/flash I ended up completely relying on print statements.
  • It’s nicer to develop in a normal webpage rather than a plugin.
  • Cons:

  • Canvas is currently much much slower than Flash. It’s quite possible I’m doing something stupid, but the canvas version uses about 40% of my processor where as the flash version is 5-10%.
  • Less built in support for text and user interface items like entry dialogs. There is probably much more missing along these lines, and much that will need to be implemented from scratch. Personally speaking I am not too fond of library frameworks implemented by architecture astronauts, so I can live with this at the moment.
  • Update: While I hope HTML5 is the future, it seems on some counts my optimism was premature, it seems it’s still to reach a point where it’s available for the majority of people – and where it is available, the stability and performance is variable. With this in mind : On flash, software art and freedom

    Build a World

    A self building text adventure game which starts off with an empty world:

    You build new places with “build my house n” (which means build my house to the north) then you can go there “n” and give it a description “describe a blue house with red doors”. You can also make objects with eg “make cheese” and take it (when it will be added to your inventory), move around and drop it elsewhere.

    If you type “dot” you get a text description of the world which can be read by graphviz. Here is part of my mental model of Helsinki:

    As it says in the embedded page, it’s very much inspired by Craig Latta’s quoth musical livecoding system, which uses an interface like this to create musical entities you can interact with.

    Groworld Prototypes Released

    I’ve gathered most of the game prototypes I made for groworld and put them into a cross platform release. There will probably be a bit of tweaking still to be done, as the windows version of plant eyes seems a bit unstable.

    OSX version (Just extract and run)
    Linux version (needs fluxus-0.17 installed which you can get here)
    Windows version (Copy the Fluxus directory to “C:\Program Files” and run the executable it contains)

    You may recognise the “menu plant” from the Kansallisteatteri building projections, a bit of recycling.


    Hampstead is a text adventure game written in 1984, which conveys a certain attitude I find refreshing 26 years later. It’s a document of London life, and rich in satire of the social customs of the time. It even exists as a museum piece – not sure how many computer games can lay claim to that! “The aim of the game is to attain Hampstead, not just to reach it”.

    Visualisation of Live Code

    Alex Mclean, Nick Collins and I have written a paper for EVA 2010 on Visualisation of Live Code (link to preprint version).

    In this paper we outline the issues surrounding live coding which is projected for an audience, and in this context, approaches to code visualisation. This includes natural language parsing techniques, using geometrical properties of space in language semantics, representation of execution flow in live coding environments, code as visual data and computer games as live coding environments. We will also touch on the unifying perceptual basis behind symbols, graphics, movement and sound.

    The paper includes betablocker, daisy, al jazari and scheme bricks.

    Plant -> Game interface

    I’ve reconstructed some of the plant sensing hardware we developed during the summer and adapted the plant eyes game to use the sensors to reflect changes in the real plant’s environment. Currently, light levels change the perception of time to the game plants. When it gets dark the plant slows down, so the world around it speeds up. This is shown by altering the speed of the non-plant life, the insects – for instance butterfly wing flaps slow down as the plant receives more light. Moisture levels affect the health of the plants in the game, changing their colour from healthy green to ill to a dried up yellow/brown. Here’s a before and after shot of watering a test pilot plant:

    Code and schematics to follow.

    The hidden history of the Monopoly board game

    As I’ve been researching the ideas of Jane McGonigal lately, I was interested to find out the real history of the Monopoly board game from Dmytri Kleiner at the weekend. From wikipedia, thanks to the research of Ralph Anspach:

    In 1903, the Georgist Lizzie Magie applied for a patent on a game called The Landlord’s Game with the object of showing that rents enriched property owners and impoverished tenants. She knew that some people would find it hard to understand the logic behind the idea, and she thought that if the rent problem and the Georgist solution to it were put into the concrete form of a game, it might be easier to demonstrate. She was granted the patent for the game in January 1904. The Landlord’s Game became one of the first board games to use a “continuous path,” without clearly defined start and end spaces on its board. A copy of Magie’s game, dating from 1903–1904, was discovered for the PBS series History Detectives. This copy featured property groups, organized by letters, later a major feature of Monopoly as published by Parker Brothers.

    While the official history on the Hasbro monopoly website picks up the story a little bit later on, and leaves off all details of its original, critical nature:

    It was 1934, the height of the Great Depression, when Charles B. Darrow of Germantown, Pennsylvania, showed what he called the MONOPOLY game to the executives at Parker Brothers. Can you believe it, they rejected the game due to “52 design errors”! But Mr. Darrow wasn’t daunted. Like many other Americans, he was unemployed at the time, and the game’s exciting promise of fame and fortune inspired him to produce the game on his own.

    Heres an image from Lizzie’s original patent: