14 August 2009
processing chain game
Combined cooing over Steph Thirion’s games mod workshop and layer tennis over the past few weeks got me thinking about a project I’m looking into running that sits halfway between the two.
Currently lacking in a catchy title, the basic gist is a chain processed game/interactive art. Starting with an original (but basic) games code in Processing- this would then be passed along a chain of X people who would each make X number of changes to the code before passing it onto the next person and so on until it gets to the end and we’re left with some weird mutilated but (potentially) beautiful evolution of interactive art/ game.
Of course there are a lot of variables/ issues I need to work through before moving ahead (such as what happens if the code breaks, how many people to pass it through, what constitutes a change etc…) , and it was great to be able to talk through the idea and issues with some of the guys form FizzPOP on Weds eve who pointed out two main things,
1) Why just send the code through a linear chain, and instead allow it to branch out (e.g. one person passes on the code to two people and so on)- this way if the code breaks it doesn’t matter too much as it will naturally continue along another branch- (such a simple and good idea that I’m hitting myself for not thinking of it)
2) The original code Thirion used for his workshop was ‘over engineered’ to provide it with the hooks that allowed non coders to adapt and change the game: e.g. you didn’t need to write the code to create multiple balls as it was always there waiting to be adapted’. This point was quite a hard one for me, as it left me with two options,
a) If the code is over engineered, then by doing so I’m potentially enforcing limits on the designs evolution – and also limiting the projects scope.
b) but if I don’t, then how accessible would the code be to those with little to no coding experience (and yes I do want to include these people within the chain).
hmmm well a little pondering on the way home allowed me to justify route a- because in creating any game a designer already enforces the limits of what a player can do- and this could also apply if I considered the processes of adapting the code as a game within itself. But also by spreading out when people with and without coding experience interact with the code then someone with experience might actually add new hooks/ code that we hadn’t even been considered at the beginning and those with no experience can move forward and evolve the code using these.
Does all this make sense? Well it does in my head, which for the time being is what matters. But I’m hoping to do some testing of this over the coming weeks with help from the people at FizzPOP (fingers crossed). But if you have any thoughts, interest then please drop me a line- and if you are s**t hot with Processing and might be able to help code the starting ‘game’ then I’d be super interested in hearing from you.
4 Comments currently posted.
Antonio Roberts says:
Antonio Roberts says:
In fact, here’s an old version of the game http://www.hellocatfood.com/pminspace/pminspace.swf
Hack Session: 26th August | fizzPOP says:
[...] There’s been some recent discussion about starting a ‘chain game’ using either Processing or Scratch. If that takes your fancy read more here [...]
Spining Dogs, Flashing Cogs and Processing | fizzPOP says:
[...] way of working reminds me quite a lot the Processing workshop by Steph Thirion that Tigershungry showed us last year. In that workshop participants, who had little experience of coding, were given [...]
Myself and Ben carried on hacking the code for that game. We got somewhere but just need to study it more. I once made a crappy game that combines pacman and asteroids in actionscript. If all else fails I’m happy to attempt rewriting it in processing for use in this project.
Perhaps you should post this to the mailing list too