Users > “drivers” of software

I’ve finally had a chance to sit down and comment on John Naughton’s article in the Guardian and it’s manifesto addressed to the education secretary The Rt Hon Michael Gove MP on computer education in the UK. This joins an avalanche of recognition that programming – or “coding” – is suddenly a Good Thing for People To Know.

It is wonderful to read a major media publication pouring scorn on the old idea that “computers are like cars”, “users are drivers” which has dogged perceptions of computers for years. There is a new philosophy here focusing on hacking, in the original sense – an algorithmic literacy of processes which now mediate every aspect of our lives. This is seen as good as a general life skill, and of course good for the economy for encouraging the kind of independent thinking needed for successful startup companies.

This avalanche has to be credited to some extent to game designer David Braben and his Raspberry Pi project, and an extensive PR campaign tweaking people’s memories (including an increasing number of politicians in their 30’s and 40’s) who remember school computers like the BBC micro, and their later influence on what these same politicians like to call the “creative industries”. This of course all seems instinctively good sense for those of us who have been closely watching the boom in popularity of arduino, processing and free software methodologies in hacklabs and fablabs.

However, an approach organised on this scale is unlikely to support such generalist and creative philosophies we are used to. A few days prior to this article we had an announcement of £575m for kitting out schools with computing infrastructure from familiar public sector contractors including Serco and Capita, and a bit more detail on Staffordshire county council who are spending £28m on “Apple products under the iOS lot including iMacs, Mac Books, iPods, iPads, Mac Minis and Lion Server.”

The problem here is that a rejection of “users as drivers” is a rejection of iOS (and to a lesser extent Android) and the app store philosophy. App stores are extremely successful at promoting the idea of phones as appliances (never computers in their own right) and software as small digestible “apps” encapsulated in locked down environments generally marketed as a kind of protection for users. If these models of computing are to grow as expected – they are completely at odds with an accessible understanding we need for this change in education approach, and the creative literacy of algorithms which would follow.

When I’ve interviewed graduates for creative programming jobs the thing which is really most valuable (much more so than knowing the relevant programming language) is exactly the thing that having an “edit source code” button on every app would encourage (as included on OLPC’s sugar, another older example of an education targeted effort). What is needed is a creative lack of respect for software, a cheerful abandonment of the fear that “breaking something” will be your fault rather than that of the system.

Germination X graph of solutions

Last week I posted the big graph of problems based on feedback from the Falmouth Loading Bar focus test. I went through each area building up a list of possible solutions – the general idea being to find solutions that might solve more than one problem at a time.

I now have quite a reasonable todo list for another code sprint. Hopefully there will be some new things implemented, based on this – we will see how it goes.

Here is an image of a mass of feedback post-its neatly arranged into lines:

SuperCollider Symposium

I had a great couple of days at the SuperCollider symposium, starting with a gameboy performance with Till Bovermann and ending with a talk on BetaBlocker with him and Tom Hall. As an outsider to the community (I have contributed code, but I’m not a regular user of Supercollider) it was interesting to pick up on the threads and burning issues of the scene.

Our performance went well, and I found it oddly satisfying to continually dismantle all repetitive dancable structures as they emerged in order to keep up with Till’s more fluid style. We were both running the Betablocker virtual machine, but using it in very different ways – I was running a single one at 4 or 5 cycles per second inside the DS, Till was running many at 44100 cycles per second inside Supercollider.


Photos by Steve Welburn

I also had a chance to experience Benoit and the Mandelbrots for the first time – both in livecoding performance and finding out more about their software during their talk. It seems that livecoding is very active with a lot of new approaches being tried – for example extensive use of text chat for communication during performances. Also I found out about BeeNoir an amazing hexagonal beehive sound installation made by the Mandelbrots which was inspired by Al Jazari!

One of the hightlights of the event was Takeko Akamatsu of CraftWife fame initiating a 5 minute code-off competition between Click Nilson, MCLD, redfrik and Juan Mandelbrot (including a fully loaded water pistol) during her keynote talk.

You can read about some of the other things at the conference on this BBC article. Thanks to Dan Stowell and the team for all the hard work putting on the symposium.

Germination X graph of problems

During the Germination X focus test I asked the participants a set of questions in 4 areas based on work we had done at SICS mobile life in Stockholm. This was useful as although there was a lot of information (and a load more free form feedback after the questions) – at least there was a structure to help understand it later.

Despite the glowing words of the post-event review, the important thing is to look at all of the criticisms from the post-it notes to create an depressing “graph of badness” – in order to pinpoint the areas needing urgent attention.

The game world

The main problems with the general game world seem to be a lack of distinction between the different elements – telling the fruit/seeds apart from the plants, how did the plant spirits relate to things. One tester found it very difficult to get plants to react to what they were doing, and therefore got very frustrated.

The Plant Spirits

Perhaps the most unusual, and certainly the most challenging aspect of the game, the plant spirits caused a lot of negative feedback. Some testers felt that they were random, and even aimless – zooming around and popping in and out of existence from player to player. The FAtiMA fixes had also caused them to over react to so many people playing at once – so they were moving too fast for people to even read their messages.

Even when they were understood, a well meaning but disastrous last minute ‘tweak’ made them ask people to help other players by planting plants they couldn’t pick yet, which lead people to think they were taunting them!

This prevented most players from interpreting any useful meanings from their actions (a lot ignoring them). It was only later when people went back to playing in a less intensive way (which I was pleased that a lot did over the following days) that they were reacting more normally.

Other players

The main problems flagged up when asked about their relationship with other players was the lack of a visible physical presence – no avatars. Other player’s actions were noticed quite strongly, but only indirectly – and not entirely helpfully. The lack of a map or overall view came up here too. Although the gifting mechanic was added to the tutorial only a couple of players tried it out, the others either didn’t notice it or forgot to try it.

Ownership

The problems of ownership were related mainly to the problems with the game world, differentiation between elements – also some players didn’t notice the “glow” around their plants (which isn’t in the tutorial). More interestingly, some players found that being restricted to a single action – “planting” with no follow up meant they didn’t care as much about their plants as they could.

Predictably perhaps, this was also an area with a noticeable differences between the gamers and non-gamers, the ones more used to gaming felt their role was to “create the best garden” while the others tended to feel that they should be “helping each other to create a balanced world”.

The next Germination X post will be about solutions to some of these problems!

Betablocker @ SC2012 livecoding night

I’m travelling to London this weekend to appear as a guest performer with Till Bovermann at the SuperCollider Symposium livecoding night, alongside livecoding all stars Benoit and the Mandelbrots, Thor Magnusson, Alo Allik and Yota Morimoto.

Till and I will be collaboratively performing using the betablocker virtual machine, Till running it at audio rate inside Supercollider, while I’ll be livecoding it at much slower beat time on a GameBoy DS – projecting it’s screen via close up webcam.

Fast HTML5 sprite rendering

After quite a lot of experimentation with HTML5 canvas, I’ve figured out a way to use it with the kind of big isometric game worlds used for Germination X which are built from hundreds of overlapping sprites. There are lots of good resources out there on low level optimisations, but I needed to rethink my general approach in order to get some of these working.

It was quite obvious from the start that the simple clear screen & redraw everything way was going to be far too slow. Luckily HTML5 canvas gives us quite a lot of options for building less naive strategies.

A debug view of the game with 10 frames of changes shown with two plant spirits and one butterfly moving around.

The secret is only drawing the changes for each frame (called partial re-rendering in the link above). To do this we can calculate sprites which have changed and the ones they overlap with. The complication is maintaining the draw order and using clipping to keep the depth correct without needing to redraw everything else too.

In the game update we need to tag all the sprites which change position, rotation, scale, bitmap image, transparency etc.

Then in the render loop we build a list of all sprites that need redrawing, along with a list of bounding boxes for each overlapping sprite of the changed sprites that touch them. There may be more than one bounding box as a single sprite may need to be redrawn for multiple other changed sprites.

For each changed sprite:
    Get the bounding box for the changed sprite
    For each sprite which overlaps with this bounding box: 
        If overlapping sprite has already been stored:
            Add the bounding box to overlapping sprite's list 
        Else:
            Store overlapping sprite and current bounding box.
    Add the changed sprite to the list.

Assuming the sprites have been sorted into depth order, we now draw them using the list we have made (we would only need to loop over the redraw list if we built it in depth sorted order).

For each sprite:
    If it's in the redraw list:
        If it's not one of the originally changed sprites:
            Set a clipping rect for each bounding box.
        Draw the sprite.
        Turn off the clipping, if it was used.

With complex scenes and multiple moving objects, this algorithm means we only need to redraw a small percentage of the total sprites visible – and we start to approach Flash in terms of performance for games (I suspect that flash is doing something similar to this under the hood). The code is here, currently written in HaXE, but will probably end up being ported to Javascript.

Germination X: More on platform independence

More detail on yesterday’s HTML5 canvas version of Germination X. The game engine it uses (known in the source code as “truffle”) is carved up into several layers in order to allow it to make use of HaXe’s cross platform abilities. This is exactly the same concept as used with console games – you set up some standard interfaces to be used from the game code, and implement them for each target at the lower level. The main thing it to make sure you continually build and test both versions.

Here’s a diagram with rounded corners:

There are a few things in the game code I needed to go directly to flash for, one was the glow effect on the plants owned by the player – using a filter. The other was doing an image pixel colour lookup to get the emotional colours for the spirits – both of these are switched off in the canvas version, to be fixed later.

One of the things I’m most impressed by is the ability to send a HaXE closure to Javascript code, store and run it from there (for example on those pesky mouse events on sprites). Of course this works as it’s all Javascript in the end, it’s just one of those cool things that takes you by surprise.

Germination X in HTML5 canvas

I’ve spent a couple of days on an experimental not-quite-working-yet port of Germination X to HTML5. Port is probably a slightly misleading word, as it’s actually running exactly the same HaXE code, it’s just compiled to Javascript rather than swf with a load of extra Javascript filling in the stuff needed to replace Flash. The game engine that Germination X is built on is now officially cross platform! It’s great to finally have a non-proprietary browser option for the game, and HTML5 is much faster now than when I first tried it, but it’s still got a long way to go. Problems I’ve noticed so far:

It’s still slow. I’m aware of the limitations and background to browser tech, but it’s depressing that it’s somehow problematic drawing a few hundreds of sprites in 2012 while my ancient Gameboy DS can manage quite fine thankyouverymuch 🙂

Tinting images is quite a basic thing to do in order to efficiently use images and save bandwidth and memory. Why do I have to loop through pixels in javascript to do this? This is the main cause of slowness in the HTML5 version of the game ATM, hopefully a simple bitmap cache will fix this. There are also some neat ways to do it with offscreen bitmaps and blendmode tricks, but they seem even slower.

Having to write your own mouse event detection for sprite down/up/over/out. I guess this is one of the biggest reasons for the explosion of HTML5 game engines. It’s quite non-trivial and un-fun to set up properly. Actually getting the real mouse coordinates is also quite hard to do.

On the plus side, it’s a breath of fresh air to get back the control of immediate mode – it seems historically that this tends to be the optimal approach, give us the render loop!

Now you’ve got this far – here is some accidental art which happened this morning, and which I’m particularly proud of:

Hapstar version 0.7

Hapstar has achieved some popularity in the genetics community, the paper has currently racked up 13 citations, including one for it’s use to create a figure for a Nature paper.

This version addresses some requests from users, including the ability to save graphs midway though balancing. This means it’s easier to run them for long periods of time. It can be downloaded from the official page on the FoAM site.