Category Archives: random thoughts

Naked on Pluto wins VIDA

It’s been busy in Elastic Versailles lately, last week it was announced that Naked on Pluto won the VIDA award, and the game was selected to appear at a series of Robots and Avatars shows next year. The VIDA award concerns art and artificial life:

The projects may be based on systems which emulate, imitate or speculate on the notion of life through current research and technology. These systems may involve attributes of agency and autonomy which display specific behaviour, are dynamic, react to their surroundings and evolve, and which question the frontiers between what is alive and what is not, between synthetic and organic life.

The game attempts to minimise differences between bots and players, while the bots also form a dynamic whole, cleaning and bringing the game world back to it’s original state while players attempt to disrupt the system. The game world of Elastic Versailles is also connected with the very real world of human relationships – it’s this connection that makes otherwise very simple games engaging, and the main reason for the rise of “social games”. In our case we are attempting to use this powerful medium in order to question strong assumptions about privacy that have arisen due to the homogeneous culture these systems have sprung from.

It will be interesting to see how much this publicity will increase the player assault on Elastic Versailles – we’ve seen a rise in visitor numbers but the game is challenging and requires a lot of collaboration by players. At the time of writing, only a few brave users have broken through to the outer reaches – the final quests have yet to be beaten.

We now have the challenge of presenting Naked on Pluto at a larger scale in various exhibition settings. The spaces we will create will need to be linked with the live game world in multiple ways, we have some ideas sketched out but there is much work to be done.

THE SERVICE IS GOOD, HAPPINESS WILL LAST FOR TEN THOUSAND YEARS

Free software projects are not products

One of the best things to happen if you are a free software developer is to see your code cropping up in other projects. Recently I’ve been helping Till Bovermann reuse the Betablocker DS virtual machine and integrate it into Supercollider, where it can be run at audio rate to create sound directly. The fact that the code was written to run on Gameboy means that Till’s also able to run 20 of them at audio rate at the same time.

In other news, the Fluxus editor is now being used as a way of livecoding Open Frameworks. This has a nice symmetry to it, as Fluxus uses some code from Open Frameworks for it’s camera input.

To me this highlights how thinking about free software in terms of being products (in a consumer capitalist sense) is an ill fit. This kind of cross pollination is really “the point” of free software, and would be, by necessity full of barriers if these projects were proprietary.

The problem is that it’s very hard for us to see outside of these ideas when they are so ingrained in our world and our thinking. It’s sometimes valuable to try and outline these assumptions, and become more aware of them.

The popularity in terms of raw market share is an interesting metric for a free software project as it has a kind of irrelevance or is even an obstruction when users are not supporting the project somehow. In the same way, the definition of “user” and “developer” seem a hangover from the same kind of producer/consumer thinking we are interested in finding the edges of.

What we want to know is what kind of people are using the project, are they curious, will they fiddle with things, do they blog about the work they are doing, can they translate the documentation? Most of all, will they increase the energy surrounding the work? People that do that are precious.

If we want a good metric of a project’s success in terms of cross pollination, perhaps we can borrow from scientific methods – where citations are a major metric for how influential a paper, individual or group is. Is there a way of tracking the movement of code and ideas in free software?

Why open licences?

I was recently asked by Wendy Van Wynsberghe from constant to explain how and why I use open licences for a lecture she’s doing on the subject. Like a lot of seemingly straightforward questions – it took me quite a while to work out the answers. With her permission, I thought it might be worth posting here.

So how do you use free & open licenses in your work?

I consider myself a software artist – so I am concerned with the process of creating software (via the combination of code and other digital assets). All the software I write is covered by the GPL licence, which means that all derivatives of it (created by me or anyone else) have to also be published as open source. I use similar licences for videos, images and written documents I produce as well.

Why?

Firstly, most of my work is publicly funded (either via arts grants or science research funding) so this is a moral issue for me – why should tax money be spent on work which is then removed from public access?

Secondly, and perhaps more interesting, is that the use of open licencing changes the way you go about your work in some fundamental ways.

For example, making your working method open immediately makes your work accessible to your peers, encouraging comment and collaboration at all stages. This for me is one of the most important lessons art can learn from the scientific method.

The initial fear that someone may steal “all your good ideas” is actually less likely if they are published and disseminated widely, as the danger for anyone wanting to borrow without attribution is that they will be found out all the easier.

This is not an absolute position. The embryonic stages of an idea for me need to be carried out and understood to a certain level away from such a public view. However it seems that the earlier you can open the working process for the idea, the faster it will develop and in more interesting directions.

FarmVille

At it’s height Farmville attracted 60 million players per month. This makes it the most played computer game in history, and not without good reason – I enjoyed playing it too. What continues to fascinate me beyond the appeal of the game itself is the worldview it presents regarding plants (and also domesticated animals) and food production in general. In order to appeal to such a wide range of players there have to be strict restrictions on how they treat issues such as death, disease and slaughter.

FarmVille creators Zynga explain how it works in a single slide

For example, horses are cultivated for the harvesting of their hair, when pigs are “100% ready” you get truffles. There is no death allowed anywhere, everyone is clearly vegetarian, there is never bad weather, crop failure or insect infestation. The game has come under some criticism for these and other issues. What I find interesting is that despite the restrictions on awkward issues, the logical conclusion of the way the game works leads to animals crammed in to the smallest area possible, and the winning strategy for plants is to create a vast monocultures of the most lucrative crop.

This clearly is “just a computer game” albeit one that 60 million people play regularly, but computer games can be used to create and explore worlds at the limits of our imagination – so what does it tell us if this is the way we need to portray the world for people to have fun? How does this happen? It the only way possible?

One aim for the Germination X project is to explore these questions.

Naked on Pluto vs Mozilla

We had some trouble following a submission of Naked on Pluto to the Mozilla Game On competition. Aymeric describes the full story here, and it looks like a case of satire mistaken as the real thing, but it’s just a shame that we needed to go public with a blog post before we received any replies from Mozilla to our numerous emails.

FaceBook

I also wanted to write something about FaceBook as so far we have had zero problems with them over Naked on Pluto, a FaceBook game designed to confront the concept of online social networks.

This could be for two reasons, firstly FaceBook could be a place that welcomes strange and awkward software art and games even if they are a bit critical and have an odd sense of humour (although evidently they can’t be as confrontational as the web2.0 suicide machine).

The other, much more likely possibility is that with the sheer number of applications and games they haven’t even noticed we exist – which in itself makes the space, if not free, slightly “loose”.

Clojure frustrations

One of the nice things about Clojure is that it comes with a huge set of data structures, all of which can be handled using normal Lisp commands. However things are not as simple as they first seem, and it’s a bit of a dark art as there is limited information online. I’ve just spent a day or so on a frustrating voyage of discovery, so I post this here in the hope of saving someone some time in the future.

Lisp generally allows you to read and write data very simply, there is no need to use a separate parser as you store information in lists – the same as the code, for which you already have a parser.

For example if you have a text file called data.txt containing ‘(“one” “two (“three” 4) 5) all you need to do is call (define d (load “data.txt”)) and it gets parsed for you from it’s text form: (first d) returns “one”. This is more efficient than using another kind of format such as XML which you’d need to run a separate chunk of code for.

One of the clojure data types I decided to use was StructMaps, which you define like this (defstruct mystructfieldone :fieldtwo :fieldthree) : and gets created like this:
(struct mystruct 1 2 “three”) => {:fieldone 1, :fieldtwo 2, :fieldthree “three”}

Clojure also comes with some handy io calls, so you can save the StructMap with (spit (struct mystruct 1 2 “three”) “data.txt”) and you get a file created containing {:fieldone 1, :fieldtwo 2, :fieldthree “three”}. This can be read back in simply by using (read-string (slurp “data.txt”)).

The catch is that the result of read-string is a different type to the object we saved:
(type (read-string (slurp “data.txt”))) => clojure.lang.PersistentArrayMap whereas: (type (struct mystruct 1 2 “three”)) => clojure.lang.PersistentStructMap. Presumably the reader interprets the curly braces as a different type. Annoying, but I then got reading about print-dup, which provides more serialisation information for recreating the data:

(print-dup (struct mystruct 1 2 “three”) *out*) => #=(clojure.lang.PersistentStructMap/create {:fieldone 1, :fieldtwo 2, :fieldthree “three”})nil

This seems to output code that should be able to recreate the StructMap. However, to actually write and read this from disk, we have to call it a bit differently:

(use ‘clojure.contrib.io)

(defn serialise [data-structure filename]
    (with-out-writer
        (java.io.File. filename)
        (binding [*print-dup* true] (prn data-structure))))

(defn deserialise [filename]
    (with-open [r (java.io.PushbackReader. (java.io.FileReader. filename))]
        (read r)))

At this point I was getting a bit frustrated, but felt I was close. Unfortunately, deserialising the file created – I got this message:

java.lang.IllegalArgumentException: No matching method found: create (NO_SOURCE_FILE:1)

Great, so the clojure.lang.PersistentStructMap/create doesn’t actually exist? More searching revealed that this is indeed the case, and is not going to be fixed in the short or medium term. Perhaps we can bump down a level and use some serialisation stuff from java – some googling provided these replacements:

(defn serialise [o filename]
    (with-open [outp (-> (java.io.File. filename) java.io.FileOutputStream. java.io.ObjectOutputStream.)]
        (.writeObject outp o)))

(defn deserialise [filename]
    (with-open [inp (-> (java.io.File. filename) java.io.FileInputStream. java.io.ObjectInputStream.)]
        (.readObject inp)))

These seem to do the trick: (type (deserialise “data.txt”)) => clojure.lang.PersistentStructMap. However data.txt is now a (relatively) large binary file, and not human readable. Not a showstopper, but all the same, not very Lisp like. I’ve been aware all this time that the documentation suggests using Records instead of StructMaps, so I assume these will work better – you create and use them in a similar way:

(defrecord myrecord [fieldone fieldtwo fieldthree])
(myrecord. 1 2 “three”) => #:user.myrecord{:fieldone 1, :fieldtwo 2, :fieldthree “three”}

However, they exhibit all the same problems as ArrayMaps when it comes to serialisation – and although they do work with the last method, they exhibit a further problem. If I change the definition of myrecord and then stream in the file, I get this:

java.io.InvalidClassException: user.myrecord; local class incompatible: stream classdesc serialVersionUID = -791607609539721003, local class serialVersionUID = 4065564404893761810 (NO_SOURCE_FILE:1)

The problem here is that I need to be able to change my structures and then convert older saved data using versioning. I can do this with StructMaps as they are not statically typed, so I can write code to check them on load and modify them to the current version (this was used a lot on NoP to keep the game running all the time with the same data while changing the fundamental types). I think a lot of my problems stem from coming from Scheme, so I’m not really aware of the “Java way”.

The other approach is to just abandon looking for an existing solution and go back to writing per-object versioned serialisation/deserialisation parsing like I do in C++.

Germination X – the next steps

Lina and I have begun work on the next iteration of Germination X which will be more playable than the demos we’ve been working on up till now. We are developing the look and building some of the underlying technology we need for the Pixelache event in March, lots more of this to come, but I’ve begun using the Lirec wiki to start to organise and document things.

The first part I’m looking at is getting characters drawn on paper into a multiplayer game instantly using various computer vision algorithms. This will be used in of one of our workshops at Pixelache, but we also want to prototype characters quickly and easily ourselves. Something which was lacking with the first groworld games, and I tried to address during Naked on Pluto was the effectiveness of making games shapeable by everyone involved in a project. Programming time and effort spent on this kind of accessibility seems to buy you a lot more time throughout a project even if it’s not actually seen or used by players in the end.

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.

On Flash, software art and freedom

With the current state of html5 not really being where I want it to be, I feel I need to air my dirty laundry on the use of Flash.

I want to make browser based applications in order to increase accessibility – with the understanding that I may need to make concessions to freedom to achieve this. With experience, I have found (for example by porting fluxus to windows) that such concessions over accessibility lead to more people using free software (and in that case, moving over to the linux version completely over time) than sticking in accepted, and eventually all too comfortable, spaces.

Obviously licensing the source as GPL helps, as does using a GPL toolchain (Haxe). Above all though, in artistic terms I find excessive purity to be counter productive.