In 1903, the Georgist Lizzie Magie applied for a patent on a game called The Landlord’s Game with the object of showing that rents enriched property owners and impoverished tenants. She knew that some people would find it hard to understand the logic behind the idea, and she thought that if the rent problem and the Georgist solution to it were put into the concrete form of a game, it might be easier to demonstrate. She was granted the patent for the game in January 1904. The Landlord’s Game became one of the first board games to use a “continuous path,” without clearly defined start and end spaces on its board. A copy of Magie’s game, dating from 1903–1904, was discovered for the PBS series History Detectives. This copy featured property groups, organized by letters, later a major feature of Monopoly as published by Parker Brothers.

While the official history on the Hasbro monopoly website picks up the story a little bit later on, and leaves off all details of its original, critical nature:

It was 1934, the height of the Great Depression, when Charles B. Darrow of Germantown, Pennsylvania, showed what he called the MONOPOLY game to the executives at Parker Brothers. Can you believe it, they rejected the game due to “52 design errors”! But Mr. Darrow wasn’t daunted. Like many other Americans, he was unemployed at the time, and the game’s exciting promise of fame and fortune inspired him to produce the game on his own.

Heres an image from Lizzie’s original patent:

Code here

The day after arriving, Gabor and I did our best to introduce our workshop participants to livecoding and fluxus, from the basics of scheme to some more visually juicy aspects:

The next day the roles were reversed as we took part in workshops lead by some of the previous day’s participants. This was the ’speed geeking’ event, we had 30 minutes to learn about a new project and contribute something towards it before moving on to the next. We looked at games as explorations of the struggle between supermarkets and open markets, by playing and helping to refine the rules of a boardgame prototype designed by Selena Savic. There was also a creative strategy involving recycling digital trash by Loredana Bontempi called ddump. I recycled a presentation using open office into a glorious piece of digital art. Then Emanuele Bonetti showed us a new way of sharing image references called pickpic which promoted online collaboration. This was a good format for fast presentation of ideas – I think the time was short enough to keep it slightly chaotic and therefore giving it a fresh, informal feeling.

The evening ended with ‘Petcha Gnucha’ mixing up presentations of work from the Piet Zwart Institute with Groningen’s Frank Mohr Institute.

On Saturday there were talks themed around ‘Hocus Pocus’. Martin Howse discussed the concepts surrounding his island2 installation which was being shown in the sign gallery. He took us on a journey through ideas of protected or hidden spaces including stenography, kernel security rings and software design tied to themes of vampirism, pornography, plague and classical concepts of concealment. Dmytri Kleiner gave a talk looking at how political ideologies tend to attach to different network topologies, what it could mean to be a venture communist and why the world needs them. Finally Florian Cramer made a passionate call for digital art to return to the critical, comparing the work of Constant Dullaart (superb name for an artist, can’t be real) with Heath Bunting’s Own, Be Owned, or Remain Invisible.

In the evening it was our turn (IOhannes Zmölnig, no copy paste and I) to livecode for the enjoyment of those equipped with headphones at the placard concert.

I have some footage of my performance, but it’ll have to wait for the moment. I should also mention Breakfast club – which was an approach to try and document discussions about the previous day’s events the morning after. The theory being that you can lure people into a situation involving cameras and microphones by the deployment of freshly baked croissants first thing in the morning. This worked well to get discussion going between the different groups, and is something I’d like to see used more at other events.

At Sign gallery Groningen, the Netherlands. I’m going to be doing a fluxus workshop with Gabor and a scheme bricks placard performance – the first one I’ve tried solo, I think!

chmod +x art The computer as theatre, as writer of love letters, the computer as world, a place for revolution, art as executable. chmod +x art presents artists that turn our ideas, dreams and fantasies about machines and code up side down and show programming as an infinitely intriguing way of creating. Code is a medium. Whether it is used to formulate instructions for a machine, ideas for people or both. The writing of it influences and shapes the creative process of the artist. For that reason, ghost programmers may be left at home. Besides the importance of writing code yourself, it is essential to show that code. Without source, software art remains a magic trick. Do It Yourself and show us your sh*t!

I’ve managed to get the script loading gui working, fix a load of crash bugs and most importantly get the more advanced rendering code working – here’s a screenshot of the GLSL shader example script running:

Edit – finally managed to upload a video of this…

The gnome character map was very useful, as was this website which includes a bit more information.

Firstly the history of how text is dealt with is a rather shameful mess of assumptions and out of date compromises. With higher level programming languages this is almost a solved problem, but in C++ it’s not at all. It would also possibly be less of an issue if we could use an editor widget from a normal windowing toolkit, but we can’t as we need to render text in OpenGL with all sorts of whizzbang livecoding zooming effects.

It’s an often told story, first there was ascii, and assumptions of everyone speaking english, and 8bit having to be enough (actually 7bits) for all characters needed in text. Then a whole host of ascii extensions for different parts of the world, using the unused top 127 values of ascii for special characters, while the Japanese for example having their own system entirely called Shift_JIS.

Then in an effort to sort out this mess, lots of committees were formed and Unicode was the result – with the following aim: “Unicode provides a unique number for every character, no matter what the platform, no matter what the program, no matter what the language.”

In order to do this, unicode needs to support 107,000 possible characters – enough for all the languages ever spoken (including exotic scripts such as ancient Egyptian hieroglyphics, Canadian Aboriginal syllabics and Byzantine music scripts) and lots of room for new ones too. In order to do this, you need at least 32 bits, on their own 16, and obviously 8 bits are not enough.

The problem is that ascii is so prevalent, and 32bits per character is a lot for embedded devices, so unicode comprises multiple encoding formats. utf-32 is the easy, but memory eating one, where all characters are the same size, and there is utf-16 and utf-8 which encode variable length characters to save space. utf-8 has the interesting extra property of being compatible with ascii, it reserves the single byte ascii codes and uses the upper 128 values as control codes to signify multibyte chars. For this reason, utf-8 has become the text encoding of the internet, and therefore a standard for plain text files pretty much everywhere.

In the fluxus scratchpad, I decided to use utf-32 for all internal strings – using the std::wstring class, and encode from and to utf-8 at all points of input and output. The reason for this is that fairly simple operations like finding the length of a string, or moving back a single character is complicated with utf-8 – you need to detect the multibyte characters at each point. Using utf-32 it’s much simpler, but you also need to be able to read and write utf8/ascii files.

Ok, that’s the strategy, and you’d think there would be lots of code online to do conversions between these formats – or even standard libraries in C++ to do this. No. The only code I found was buggy (a ‘>’ instead of a ‘>>’ which took me too long to find) but some working code is here. In those functions string is assumed to contain ascii or utf-8 and wstrings are assumed to be utf-32 (even this is going to have to change on the windows version where wstrings are 16bit, sigh).

So, a big search replace for string to wstring in the scratchpad code with conversions in the loading, saving and entry and exit points for the PLT Scheme interpreter, and all was good…

Except keyboard input. I’m still trying to get to the bottom of this and find out what is an artifact of using GLUT and what is the underlying operating system, but at the moment it looks like the mac sends utf-8 keyboard codes, so multiple calls to the glutKeyboardFunc callback per keypress for multibyte chars. On Linux it seems like just the first utf-8 byte gets through, I can’t find where the others get stashed. The minimal information online seems to indicate that this is stretching the abilities of the GLUT toolkit somewhat so I’ve given up for now at least.

The last thing to do was switch the fluxus editor font from the minimal Bitstream Vera Sans Mono to the more characterful Deja Vu Sans Mono which other than having many more glyphs looks exactly the same.

Portuguese help in fluxus – from utf-8 in the code doc comments, to a utf-8 helpstrings file, read in by the scheme interpreter, converted by the scratchpad to utf-32 and rendered by fluxus’s OpenGL glyph renderer.