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.

A report from a newbie web programmer

I have been recently trying to understand how multiplayer online worlds work, from the basic technical matters, to higher level game mechanics. This is a new area for me, and seems a bit of a black art so I thought I’d write some of the things I’ve discovered here for others following a similar path, or more likely, so people can tell me where I’m heading in the wrong direction.

I had to start with the complete and utter basics (as a recovering computer graphics guy) and to start with these games are split between a client and a server. The clients I’m interested in run in players browsers, and the server needs to be on a machine which is running all the time to provide the persistent world, and record the changes people make.

In terms of languages, when considering the client you are quite restricted as to what you can use. Every browser has a Javascript interpreter, and most people have flash – sidestepping the hot potato I’ve already written a bit about. Luckily for flash there is also haxe.

On the server it’s completely up to you what you use, as you can run pretty much anything in a webserver. I’m using a racket servlets so I can use Scheme.

Sending requests from the client to the server

In a game the client needs to issue requests to the server while the game is running, in order to get realtime feedback on what is going on. As far as a browser is concerned, it does this first to get the page, but as we also need a way to do this after the page has loaded. This technique is usually called AJAX, or “Asynchronous JavaScript and XML” and was a hot topic a few years ago due to the rise of Google maps and other websites that make heavy use of it. All it really means is that you can send a http request from a script running on a page, and get a result from the server. I’m skipping the XML part, but I think it’s the same idea.

In JavaScript you can do this with the popular jquery library, where a request looks something like this:

$.get("page.html", {argument1: 302, argument2: "hello"}, function(data) { do_something_with(data); } );

The page and arguments will result in a call to a url like this:

http://your-site.com/page.html?argument1=302&argument2=hello

When it’s returned, the result data will be passed to the function you pass in as the third argument. Notice that this function will be called “at some time in the future” – as it’s asynchronous. This means your script can do other things while it’s waiting for the data.

In Haxe you need to use a combination of things to do the same work:

// setup the loader
var Loader:URLLoader = new URLLoader();
Loader.addEventListener(Event.COMPLETE, CompleteHandler);
...
// define the callback for when the request has finished
function CompleteHandler(event:Event)
{
    DoSomethingWith(Loader.data);   
}
...
// set off the request
var request:URLRequest = new URLRequest("page.html?argument1=302&argument2=hello");
Loader.load(request);

Although I’m stuffing the parameters on the the url string myself, there is a URLVariables object which is supposed to do this cleanly – but I couldn’t get it to work.

Security issues

One thing you might notice is that we don’t specify the root of the url anywhere in the code, and this is for a very specific reason. The client code is restricted to only sending requests to the server which has served the page itself. This makes it hard to run a client from a location not controlled by the same people as the server – if this were possible, for example, a third party would be able to write a client that acted like the real one, but used your identity to do whatever it wanted. This is called the same origin policy.

A related issue crops up if it is possible for people to enter text which gets shown in the webpage of the game on other people’s computers. The problem here is that it may be possible for a third party to inject some code that gets executed into the website that gets sent to a player. This could result in all sorts of mayhem, for example inserting dialogs that look like they come from your website to extract personal information. This is called cross-site scripting (shortened to xss). There is no utterly foolproof way of preventing this, but a simple approach is to filter out special characters (such as angle brackets) from the input from your game as they come in to the server.

A third issue for security is to be careful of what you do with the requests you get – as while the users are protected from being tricked into running an altered client that looks like it comes from you, your server can still have requests sent to it from anyone.

For instance, it would be the easiest thing in the world to design an elegant and simple interface that directly ran code being sent to a server – eg a request such as:

http://mysite.com/myserver?func=display&param=hello

Could easily, even indirectly be run by some code like this:

(apply func (list param))

Which immediately opens your server up to people sending it calls such as

http://mysite.com/myserver?func=delete-file&param=server.scm

And presumably much worse.

So it’s important to use some indirection to verify that the commands you are being sent make sense, and come from a limited range of options controlled by you. Related to this, if you have command that create new objects somehow – it’s a good idea to have some limits imposed, to prevent some troublemaker writing a script that fills up the memory on your server.

Sending data from the server to the client

The data you send back as a result of requests can be of any form, but there are some useful standards here. I’ve chosen to use JSON which is another web programming four letter acronym that stands for JavaScript Object Notation. We saw a Javascript object earlier on, as part of the request being sent out, but they are just associative arrays. Here is another example that might come back from the server:

{
    player-id: 43,
    text: "destroy all humans",
    numbers: [3, 42, 32, 4, 1]
}

This can then be evaluated by the client and turned into an object that can be inspected by the game.

There is a risk from directly running eval on the text that comes from the server – as potentially this too could somehow be subverted to contain some executable data, although this is quite unlikely, it’s best to filter the text. Luckily there are lots of libraries to do this – I’ve used json2 before discovering that jquery has a getJSON call that does this for you.

Germination X version 1.0

I’ve set up a sneak preview of a multiplayer permaculture game running here, at the moment it simply allows you to plant plants with your name attached. I’m pretty excited about it though – anxiously awaiting rude words and troublemaking!

The raw data is viewable here. I’m going to write a little bit more about the technical details of this and naked on pluto, but for the moment the code is here.

Genetic programming music patterns #1

I have a problem when livecoding music, in that while I’m happy livecoding synth graphs to make sounds, I sometimes get a bit stuck coming up with patterns of notes for them to play. I generally start with something like (note (modulo clock 8)) and work my way fairly randomly from there.

In need of inspiration for making more complicated patterns with the minimum of code I thought I’d continue my sporadic ongoing mission to explore genetic programming (towards the much desired future of a machine programming itself). The idea is to use a fitness function to grow programs that make patterns I can specify. I could then use these programs as they are, generate them live, or steal ideas from the evolved code.

To give an example of a pattern, this is the first 13 notes of the famous techno number “mary had a little lamb” in major scale:

(2 1 0 1 2 2 2 1 1 1 2 4 4)

The first thing we need is an instruction set that can be used in machine generated programs. These need to be robust to any inputs, and rich enough to provide the sort of patterns we want to generate. I’ve started with a fairly minimal set:

(mod a b) : return modulo of a to b, or zero if b is zero.
(odd a) : return 1 if a is odd, 0 otherwise.
(even a) : return 1 if a is even, 0 otherwise.
(min a b) : return the minimum of a or b.
(max a b) : return the maxium of a or b.
(+ a b . . .) : addition.
(- a b . . .) : subtraction.
(* a b . . .) : multiplication.
(/ a b) : division – returns zero if b is zero

In order to drive the program we also need a (clock) function that returns the time – or more precisely, the place in the pattern we are in.

So the program: (+ (mod (time) 3) 2) repeated 5 times would result in the pattern (2 3 4 2 3) .

We also need a fitness function which will give us a measure of how close a pattern is to the one we are trying to find a program for. This could be the sum of the differences between each element of the generated pattern and that of the target pattern – where 0 is perfect and the bigger the number the worse the fit, eg:

(define (fitness pattern target)
    (foldl
        (lambda (a b r)
            (+ r (abs (- a b))))
        0 pattern target))

Lets try something simple to begin with – the pattern (50 0 50 0 50 0). We start with a population of 1000 randomly generated programs and pick the best one – hold on to your hats:

21

A complex program that surprisingly results in the pattern: (21 21 21 21 21 21). This has a fitness of 150 – and 21 is quite close to the average of 0 and 50, so although it’s disappointing, it makes sense.

We now create a new population, some of the individuals are new random programs, others are mutated versions of the previous best attempt (25%/75% if you really want to know). We also include the previous best attempt without mutation – this stops generations getting worse over time. Unfortunately in this run it takes 90 generations before a fitter individual is found:

(* 35 (even (clock)))

Which generates the pattern: (35 0 35 0 35 0) with a fitness of 45. Now it is only a matter of time, in fact the next 3 generations slowly home in:

(* 55 (even (clock)))
(* 52 (even (clock)))
(* 49 (even (clock)))

and then then on generation 104 we finally get:

(* 50 (even (clock)))

resulting in (50 0 50 0 50 0), with a fitness of 0.

More soon – code here.

The summer season

A new month, and the start of various new things around here. One is a slub residency with sketchpatch, where we write processing sketches and bounce them between us in a game of “sketch tennis” that lasts a month. We already have a bunch of sketches and it’s only the first day.

I’m also taking part in a collaboration with Marloes de Valk and Aymeric Mansoux involving social games, text adventures and far distant planets. This is quite a new direction for me, and it’s exciting to be forging new alliances. A bit more explanation coming soon!

On the groworld front, we are also doing some design and further development surrounding permaculture, in what could become quite a big game project. Again – more on that as it happens.