Plant spirits, AI and gitorious

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.

m.a.r.i.n. hacklab at the sea

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.

Leikkiä, Pelata, Soittaa = Play

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.

On game design

It’s recently become apparent that as I am doing a lot of game design, and seem to have loads of opinions on the subject, that I should acknowledge the fact, at least to myself – that my interests in games go further than programming.

I’m also very wary of ‘design practices’ as it’s been my casual observation that, at least in the fields of creative or programming work, they seem to be invented with the object of selling books and brainwashing management to ultimately sell even more books, rather than really helping in any tangible manner.

HOWEVER, I can get over this stick in the mud attitude and describe two design practises that we’ve been using lately:

User centred design

This one I was taught at a design workshop by Ylva Fernaeus, Sara Ljungblad and Mattias Jacobsson from SICS, but I recognise it from elsewhere, and it was good to have it explained in full.

One part of ‘UCD’ (as I’m sure it’s abbreviated to to confuse the initiates) is called user stories. You make up a fictitious person who might play your game, and describe who they are, why they are playing and what their motivations are etc – you can get quite carried away with this, and within sensible margins, it seems to help.

Then you describe the experience of the game from their point of view. This means you can leave out all the details and focus on what you want them to feel – from the inside.

You do this for a handful of people with different backgrounds. It obviously helps if you have a little bit of experience with the sort of people you are imagining the reactions of. We’ve been using our family members as inspiration, which makes it a bit easier.

The result of doing this is thinking about the players rather than the game, and while it sounds simple, forcing you to think like this can reveal some surprises.

Vertical Slice

This one sounds terribly technical, and I picked it up at Sony. It comes a little later, once you have a clear-ish design and you start to write the code. The idea is that you implement only enough to have a single full experience of your game. For instance, if you can choose between a variety of characters – in the vertical slice you only implement one, and implement it fully. When it’s finished, the vertical slice should show you one possible path through the game, but no more.

This is generally used to persuade publishers that their money is safe, and that the game is a winner with the minimum of development expense required.

However, I think it can also fit with the user stories, if you take one of your fictitious players (perhaps the one who represents the strongest demographic you are interested in) and implement the vertical slice as if you were making it for them, you are forced to face some of the most important decisions first.

Then, and this is really the key thing – you can deal with these decisions while the game is still malleable, both in terms of code, and in terms of your understanding of it in your head, and you are in a much better position to come up with the solutions needed.