New game design

I’m working on a new game as an art/science collaboration, and thought that it might be interesting to try the technique of making a board game first. The idea is not so much to make it work first time, but use physical pieces to figure out possible rules and try them without thinking about limitations of screen or interface.

It seems to work quite well as a way of working together as it’s simple to make situations as questions, change the meaning of pieces by drawing on them – or play with the physical arrangement. It probably bears some relation to design processes like bodystorming or lego serious play.

Truffle Blocks

A new project running here that brings together Germination X’s HTML5 game engine with Google’s Blockly in the spirit of Fluxus and particularly Scheme Bricks.

I’ve had a plan for working on a visual programming language for browser based games (and got someway to implementing Scheme Bricks with the Naked on Pluto art installation). Blockly has saved me a lot of time, and is inspired in turn by Scratch from MIT and it has some really nice additional tricks – like being able to add comments and collapse blocks. This is approaching the way I’d really like to be able to program these kinds of games, in terms of rapid prototyping but also one day perhaps full development.

Truffle Blocks is only a few days old and very proof of concept at the moment – the underlying game engine still needs a lot of work as it’s a port from the HaXE/flash version, and although it’s not been designed for this kind of programming it was pretty fast to get something fairly usable running.

Blockly is quite different from Scheme Bricks – which is very freeform but requires you to remember how the syntax works to build up more complex forms (as in Lispy dialects generally). Scratch and Blockly build a lot of this syntax information into the structure of their blocks, making it great for teaching programming. One of the things about Blockly which is going to be useful is the ability to modify blocks themselves in a similar editor – for example this screenshot of modifying the if block to include arbitrary numbers of elseif and a final else section:

All the source is hosted on gitorious here.

Localised sound, from a distance (part 3)

Work has been continuing on “The swamp that was… a bike opera” with Kaffe Matthews and TimeLab Ghent. We now have a running system that’s playing sounds on the bikes, although we’re experiencing some harsh restrictions due to the combination of lowish BeagleBoard memory and slow SD card reading times. I’m considering a kind of distance related caching strategy for the samples – perhaps prioritising loading samples you are cycling towards.

Thanks to Kaffe for the pics.

Location based sound, part two

Our first public test for the The swamp that was, a bicycle opera takes place next weekend, so I’ve been working on the on-bike software and getting more experience with the BeagleBoard while Kaffe builds up the sound pieces. In order to test the software, I’ve made a local map I can play with:

Each coloured zone represents a different audio sample. We are also experimenting with direction, panning each sound depending on your direction and that of the sound source. For example it’s possible to set a sound to come from the north, which pans it to the left if you are heading in an easterly direction and the reverse. Using this test map, I can run the system on battery while out walking the dog: