Al Jazari bootable USB version

I’ve been preparing an Al Jazari installation (split screen, 4 player livecoding action) for the funware exhibition at MU – part of the STRP festival. Due to various difficulties with my nordic location, we’ve decided to try getting it running on a bootable USB stick, which I can send via post, and can be run on any computer with no setup required (other than plugging in the gamepads). We will see how this turns out.

Using pure:dyne it was much easier to set up than I’d anticipated. Using this operating system as a base, which helpfully includes fluxus and fluxa already – I could add the script, textures and samples for the installation to the user data partition of the usb stick.

Then I added a .xprofile script to the home directory of the default user (lintian) containing:

cd /live/image/al-jazari-inst

Where “start” is another bash script which does most of the startup work:

./stop  # kills all the processes involved to make sure we don't clash
xrandr --output VGA1 --mode 1024x768 # force a maximum resolution
xset dpms 0 0 0 # turn off the hardware screen blanking
xset s 0 # turn of software screen blanking
sleep 2 # I'm a bit overzealous with these pauses perhaps
jackd -R -t 4999 -dalsa -r44100 -p4096 -n3 -P -s -o2 -S & # start jack
sleep 2
fluxa & # start fluxus's audio server/synth
sleep 2
./bin/oscjoy & # run the joypad to osc program
sleep 2
# run fluxus with hidden mouse, full screen and execute script on startup
fluxus -hm -fs -x aljazari-mp.scm

Notice that fluxus blocks (no & at the end of the line). This prevents the window manager starting up, which means fluxus is running directly on X. Puredyne runs a very minimal wm by default (xfwm4) so the reason isn’t really performance, but rather that there are no window positioning algorithms to mess up when fluxus goes full screen, or decorations or borders either.

Livecoding @ AltParty

AltParty was really impressive. I love how in Finland the demo scene is vibrant and branching out to new areas. This is ESA Mars researcher and Winner of 2009 Move An Asteroid Competition Sini Merikallio describing how a solar sail works:

There were lots of people doing new things with old tech, hardware hacking and other investigations involving robots, rockets, games consoles and 3D printers. I was building programs from shapes that made sounds again (thanks to Till Bovermann for the photo):

Naked on Pluto residency @ BALTAN

The residency we did in september at NIMk was almost exclusively using paper and pens as we were working together to design our game world. We could go for walks while thinking, and mostly keep to analogue methods.

This residency was very different – naturally at this stage focused on the software, we started with an initial list of showstopping things to fix, and then used online methods of organisation via mantis and the wiki.

We also presented the project for the first time, at NIMk’s space invaders event, and we had some super volunteers from Eindhoven Technical University Game Experience Lab to test the game (which Aymeric describes in more detail).

One of the things that I was pleased to get a chance to tackle was how to cope with the basics of online multiplayer games:

* How do we cope with having too many players?
* What do we do with players who haven’t played for a long time?
* How does this shared world repair itself so new players don’t find a world trashed by the earlier players?

The most worrying problem for me was the (perhaps rather hopeful) issue of being swamped by lots of people. This is an interface and resources problem, there has to be a fixed limit somewhere, a point where we have to turn people away. How do we do that?

There are two limits in this game:

A = The number of people playing at one time (interface, game world, and perhaps to a lesser extent CPU limited).
B = The number of people playing in total, with characters and associated data stored in the game (server memory limited).

B is a much higher number than A, so we can hide inactive players in order to accommodate a far higher number of people playing in total than we do simultaneously.

In other cases we are making solutions part of the game itself. For example, “cleaner” bots wander the world removing players who haven’t moved for a week – and at the same time remove items that are left over as a side effect of people playing the game.

Players can move bots around the world along with anything else, so they are given the ability to navigate their way home automatically. In some cases this results in some amusing emergent behaviour.

If left for long enough, the game will clean up all the players and return it
to it’s starting point. If lots of people are playing and messing up the game too much, we just create more cleaners! At least, that’s the theory.

Thanks to Maarten Witteveen @ BALTAN for the photography.

manSEDANse 2010

I took a little train journey up to Tampere to present pure:dyne and fluxus and introduce livecoding in the manSEDANse festival. I couldn’t stay for as long as I wanted, but managed to get some pictures of the exhibition they were showing as part of the festival.

KOKOMYS: ELECTRONIC DEVICES – Four port NAND synthesizer with one of Heikki Salo’s (aka cj hekxsa) music videos in the background.

Tristan Perich’s 1-Bit Symphony

Lirec meeting in Stockholm

The Lirec project is now more or less at the halfway point. We gathered for a meeting last week at SICS Mobile Life Lab in Stockholm and progressed through reports on the various robotic scenarios and showcases. As well as hosting the meeting (and providing us with a tour of Stockholm’s more interesting spots), SICS also gave us the opportunity to engage in a design workshop – where we could consider the scenarios through the lens of potential real life use cases and costs.

One aspect which has always been present in the project and seems to be increasing (perhaps because my mind is attuned to these issues at the moment) is the use of games. INESC-ID are continuing their research using games to study how artificial companions (not exclusively robots) can engage in social activity alongside humans. Games (to begin with, chess, and now risk) can be used to study people’s behaviour when competing and forming alliances. Later these same situations can be used as scenarios in which to test a companion character. Games we also discussed as ways to encourage users to engage with a robotic companion in a more long term manner than is possible with a more casual interaction.

I presented Germination X to the consortium as an example of using FoAM’s experience with public engagement, game design and software to increase public engagement with the project, by allowing anyone to interact with characters using the AI system via a web browser. We are also planning to work with SICS to discuss issues of ethics in relation to the use of data gathered from social networks for research purposes.