dave’s blog of art and programming

user generated content

This is my update from Amsterdam on day two of our Naked on Pluto residency. Marloes’ report on day 1 is here.

Today was all about taking the themes from yesterday and making them into concrete game mechanics we can use. We started by mapping out possible constraints imposed by multiplayer activities. We want a large amount of what you do on pluto to be coordinated with other players – and this impacts on the logic of the game world. For instance, doors can be locked – sometimes in a room full of people we only want players who are carrying a key to be able to get through the door, at other times a single player might be able to unlock a door for everyone (perhaps for a limited time).

A locking conundrum.

This sort of play requires a way for players to coordinate with each other, for example using a realtime chat system. A minor crisis involving the details of how to handle this feature was narrowly averted and we escaped to the shores of Ljsselmeer to begin considering the vertical slice, the moustache as core game feature, community service and mandatory fanny packs.

Betablocker-DS can now be programmed, and I’ve spent the last week testing it on public transport (with headphones…) Lots of niggles to fix, and not enough samples, but the basic interface works.

The DS has such a nice feel – it also seems like a more appropriate interface than the gamepad version. It’s still not really suitable for public consumption, but I’ve updated the binary here. Also I’ve started some minor documentation effort here. This version has a slightly altered instruction set to the original version and is still subject to extensive fiddling!

Our hapstar paper has been published (actually a few weeks back):

Teacher AGF. Griffiths DJ (2010) HapStar: automated haplotype network layout and visualization. Molecular Ecology Resources

There is a preprint version available on the foam site.

Groworld is part of the preliminary program for Pixelache 2011 – we are planning an expanded version of our presence last year, more to follow.

A bit more from the growing of music programs department. (Part 1 can be found here along with reasons for doing this). I’ve been trying to generate ever so slightly more complicated patterns, such as:

(50 50 0 0 50 50 0 0)

Not too exciting, but it proves quite difficult for my naive system to generate code for. A lot of times the evolution becomes stuck in the average number pattern, eg (25 25 25 25 25 25). In genetic programming (and other similar fields) such stuck states are called “local minima” as the system can’t get itself out of a relatively stable state. The problem is that in order to get to a better solution we may need to get worse first. A good description is that you are trying to find the lowest point in some imaginary terrain, and you are stuck in a puddle at the top of a mountain.

Here is a detailed look at exactly what is happening during the evolution process of a program which almost worked. We start with this:

(20 23 1 4 3 7 11 15)

Which was scored well due to the first four elements, the code for this individual (randomly generated, as it’s the first generation) is:

(mod (mod (+ (even 31) 97 22) (- 86 53 (clock))) 25))

Notice that bits of this code are unnecessary, (+ (even 31) 97 22) could be replaced by 119. Some genetic programming systems do this automatically, the approach I’ve taken is to assign a cost to the size of the procedure which should make shorter programs fitter – but I haven’t really tested this works yet.

This code has a cost of 31684. I’m squaring what I was calling fitness before, and calling it cost instead, which makes a bit more sense.

The following generation the cost drops to 15376 with:

(33 23 13 3 29 20 11 2)

Which is starting to approach the periodic nature of the target. This is the code:

(mod (mod (+ (even 31) 97 (+ 97 31 91)) (- (max (/ 56 8 75 92) (mod 21 84)) 53 (clock))) 37)

Considerably more complex, however if we manually remove all the constant expressions, we get this:

(mod (mod 316 (- -32 (clock))) 37)

It looks like the inner modulo providing something like the periodic nature that we need:

(mod 316 (- -32 (clock))) => (-4 -14 -24 -34 -8 -17 -26 -35)

While the outer modulo attempts to scale the “rhythm” values to a range closer to the target pattern. This seems like a good strategy, lets see what happens next. Generation 5 6 and 7 rapidly refine this process by tweaking the numbers – I’ve highlighted the mutations for each generation in red:

(mod (mod (+ (even 37) 96 (+ 97 31 91)) (- (max (/ 56 8 75 92) (mod 21 84)) 53 (clock))) 37) => (32 22 12 0 28 19 10 1)

(mod (mod (+ (even 37) 96 (+ 97 31 91)) (- (max (/ 56 8 75 5) (mod 21 84)) 53 (clock))) 62) => (57 47 37 0 53 44 35 26)

(mod (mod (+ (even 37) 96 (+ 97 31 91)) (- (max (/ 62 96 75 5) (mod 21 84)) 53 (clock))) 53) => (48 38 28 0 44 35 26 17)

The cost is now 11236. Generation 13 this drops to 11025 with another minor tweak:

(mod (mod (+ (even 37) 96 (+ 97 31 91)) (- (max (/ 62 96 75 5) (mod 21 84)) 53 (clock))) 56) => (51 41 31 0 47 38 29 20)

Then, on generation 31 we get a big improvement, with the cost dropping to 2601.

(mod (mod (+ (even 37) 96 (+ (clock) 31 91)) (- (max (/ 56 96 75 5) (mod 21 84)) 29 (clock))) 56) => (50 50 0 46 50 45 0 0)

A couple of numbers tweaked and a (clock) in the previously constant addition expression – this is a good case for leaving redundant code expanded, as it can be used later on due to the processes of mutation. Removing the constant bits to find out what’s going on, this can be simplified to:

(mod (mod (+ (clock) 218) (- -8 (clock))) 56)

The outer modulo is scaling the inner one as before, which is now providing this “rhythm” pattern:

(mod (+ (clock) 218) (- -8 (clock))) => (-6 -6 0 -10 -6 -11 0 0)

Unfortunately, even after 1000 generations (50 50 0 46 50 45 0 0) remains the closest to (50 50 0 0 50 50 0 0) we get – close, but no cigar.

A holiday project run amok, an idea to make version of betablocker for musical livecoding on minimal hardware – eschewing the world of yuppie smartphones for the gameboy ds.

The betablocker virtual machine is up and running, sound is working (although only one sample at the moment) and the tiles are rendered using nintendo’s 2D hardware, with really nice smooth scrolling – as you’d expect I guess. The icons need a bit of work yet, and I’m only using the top screen for debugging at the moment.

The instructions are represented by images, which are designed to only be a little more cryptic than assembler instructions tend to be. No actual livecoding is possible yet, that’s next. Code here, executable here (you’ll need some additional kit to run it on hardware). I’ll provide some level of documentation, when it is actually working.

This week has been about researching the next steps for the germination x design. Principally looking at how we can use the game to demonstrate and exploit some of the work on the Lirec project. I’ve had a speculative look at how we could use companions to fit the theme of a permaculture game, and ended up with some strange combination of bickering greek gods and plant spirits.

I’ve also been playing with the AgentMind code from our partners at Heriot Watt and got some of my own AI agents running and interacting with objects in a test world. At the other end, the client game code is now free from flash dependencies, so it should be possible to target HTML5 canvas and flash in the same code.

I’ve also switched from svn to git for everything and moved to gitorious. Germination X is here and all the rest of my mess is now located here.

A few days of summertime in the Finnish archipelago at the M.A.R.I.N. hacklab at the sea.

This experience included a lot of swimming in the sea, saunas, boat activity and simply exploring the environment, but the hacking seemed to fit in surprisingly well with this routine.

Having the privilege of being in such a place makes you aware of your footprints. With only renewable power resources available, I wanted to lower the power consumption of my computer to extend its battery life. I came across some useful instructions from the ubuntu wiki and from that discovered powertop which I can’t recommend highly enough.

This is the script I’m currently using to switch everything to low power mode, cobbled from the resources above.

# Set CPU scaling / max freq to battery mode

for x in /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor; do
    echo "conservative" > $x
    X=${x%/*}
    # The second column is the second from the highest freq most power savings / least slowdown
    awk '{print $2}' $X/scaling_available_frequencies > $X/scaling_max_freq
done

# Tweak virtual memory to conserve power when running on batteries.

echo 10 > /proc/sys/vm/swappiness
echo 0 > /proc/sys/vm/dirty_expire_centisecs
echo 1500 > /proc/sys/vm/dirty_writeback_centisecs
echo 60 > /proc/sys/vm/dirty_background_ratio
echo 95 > /proc/sys/vm/dirty_ratio

# Enable SATA ALPM link power management via:
echo min_power > /sys/class/scsi_host/host0/link_power_management_policy

# Disable 'hal' from polling your cdrom with:
hal-disable-polling --device /dev/cdrom
# 'hal' is the component that auto-opens a
# window if you plug in a CD but disables SATA power saving from kicking in.

# Change the wireless power mode to Battery.

for x in $(/bin/ls -d /sys/class/net/*/wireless | /usr/bin/cut -d'/' -f5); do
    /sbin/iwconfig $x power on power period 2 power timeout 300u
    /sbin/iwpriv eth1 set_power 7
done

I worked a little more on plant sensing, trying a simple approach of testing the electrical resistance of parts of growing plants with a sensor boosted to extremely high sensitivity. This area is fairly rife with pseudoscience, but has some basis in reality. I was quite surprised to see some changes between the values from a real plant and a dead twig, or air, with distant electrodes – but this requires a scientific test in controlled conditions, and any variation is most likely due to changes in the temperature of the wood with sunlight changes.

Returning to power consumption, it was a good opportunity to build a solar engine, which is a device that collects low currents from small solar cells and periodically dumps them into a circuit which requires a higher current (usually a motor). It should be possible to use this approach to drive self powered microcontrollers for limited bursts of activity, making their state persistent and cleanly shutting down on the low power interrupt, waking up the program where it stopped when new power is available. This could be useful for a remote device running for months or years from a very small power source.

I could only attend the first couple of days, so I’m really looking forward to seeing the results from the other projects being worked on.

Spurred on by Kassen in the last post, and as someone who happens to be learning Finnish, one of the things (originally pointed out to me by Teemu Leinonen) that has struck me is the superfluity of words used to describe “play” – which has always seemed one of these dangerously obscure words in english, with similar problems to “free”.

“Pelata” is to play something you can win (so includes most computer games, and also sports).

“Soittaa” is to play an instrument or make a sound.

“Leikkiä” is more childlike, a play without rules, when you play at being something else, play at make believe or just “play in the garden”.

I think leikkiä seems the most subversive and interesting, as it’s the sort of play where you are learning and exploring without fitting into some pre-existing assumptions (like keeping score, or playing a tune). The sort of games I like (and like to attempt to make) are definitely all about this sort of play.