Trying Tim's Vermeer

July 6th, 2014

I'm a regular listener of Penn's Sunday School, an excellent podcast by Penn Jillette of Penn & Teller fame. For a while he's been talking about a documentary film they've created called Tim's Vermeer. I got to see it a few weeks back.

It's a film about inventor Tim Jenison, and his 5 year obsession to paint a perfect replica of Vermeer's painting, The Music Lesson. Tim invents a technique/device he created, and shows how Vermeer probably used something rather similar. It's a great film, I suggest you watch it for yourself. In one scene, Tim comments casually that anyone could use his technique...

So I thought I'd give it a go. Now, I'm no painter. I can't sketch. I can't make anything look lifelike with any kind of image creation tools! I've never even touched oil paint before.

I wasn't expecting very good results, but I nipped to the shops and bought a couple of cheap canvasses, a tube of black and white oil paint, a cheap pack of brushes and a cheap compact makeup mirror. I cut and bent some wire into a crude stand and blu-tack'd the mirror to it. I printed out a B&W photo of my father to use as the original, and selotaped it to an old cardboard cat food box. I wasn't trying very hard to make the perfect setup.

I spent an evening setting this up and painting my first attempt. It just looked like a mess. Utterly discouraging to work on, and at the end of the night I just had a smudgy mess of nothing that didn't even match the original in image proportion, let alone look like a person.

The next morning I happened to catch sight of the painting I'd made from across the room. At an extreme angle, suddenly my brain recognised the face of my father. It was hard to see, but it was definitely there. I realised that there's a part of the technique the film doesn't mention - you have to move the mirror. I'd been keeping it as still as possible, assuming that touching it would ruin the painting. That's not the case though. You have to raise/lower it to scan different parts of the source image. What I'd done was squash it dramatically in the Y axis, so it was only about one quarter the height of the original.

The next night I had another go, painting directly over the squished version. I blocked in the frame of the picture first, then filled in reference points like eyes, nose, mouth. Then over the next 5 hours or so applied Tim's technique slowly and carefully. I learned how to change the shade of paint at any one point by adding black/white and mixing it right there on the canvas, or by mixing it first and applying it. I learned how to do detail with a fine brush, manipulating the paint by pushing it around rather than painting anew.

The results astonished me. Now, this is not a patch on what Tim achieved in any of his paintings, but does the technique work? Can any talentless fool with patience do it? Yup!

There are flaws. I got tired and impatient at the shirt, so didn't really follow the technique there and just freehanded it behind the mirror. The head shape isn't quite right and the placement of each feature is a little shifted. I think I'm still introducing a bit of skew overall by not moving my mirror often enough, and not looking straight enough into the setup. The painting isn't central in the canvas, and it is mirrored left-to-right (something I didn't notice until I'd finished).

The technique isn't perfect, or easy. It's not hard to follow, but it is back-breaking leaning over the apparatus while controlling a brush, and it's hard on the eyes. I had to shut one eye most of the time, and it's still difficult. It takes a lot of time and patience overall too, and shows soul-destroyingly little progress until you're a long way into it. Controlling the parallax skew is the hardest part for me so far, although with better thought-out equipment I'm sure I could get round that bit. I have a suspicion a much smaller mirror and an easily adjustable stand might help, as I'd be happier to move it more often.

Game Cartography

September 11th, 2009

I spent an evening recently looking at old computer game maps. Sounds dull, but if you can find a game you played, you get a huge sense of nostalgia and see the game from a different perspective. Take a look at this site to see what I'm talking about:

The bit about different perspective got me thinking. For some of the games I've built, there's no overview map. Not in the game, or in the source files. The levels are generated dynamically at runtime from data, not stored as a big image. Would I get an interesting new perspective building maps of my own games?

Well, you decide:
Iron Maiden: A Matter of Life and Death

Wall Street Journal Interview

August 1st, 2009

A few weeks ago, out of the blue, the Wall Street Journal interviewed me about my game Hanna in a Choppa. I'm still not entirely sure why, but you can read their edited article here.

The article is quite cut down from the responses I gave, and modified to make little sense in a couple of places, so here's the full unedited text, for the terminally bored:

WSJ: Do you have a minute to talk about your game? Thanks!

I think I could manage a minute for you, yes.

I saw your tweet about Hanna in a Choppa by the way - you're too kind!

WSJ: When did you make this game and why?

Hanna in a Choppa begun life as a short experiment in physics, about 2 years ago. An idea for a fast-running physics engine just kind of sprung into my mind, and after a few hours was a basic working demo on the screen. That engine wasn't really for anything other than play at first, but it found its way into loads of projects I was working on. Each project would need something a bit different from the engine, so it slowly got upgraded over time. It grew more features, became easier to deploy and performed better and better.

One day I had inspiration for a feature that allowed flat surfaces in the physics world. After adding it, my test code included a sort of one-screen room with surfaces at all sorts of angles, and you could control a basic losenge shape to try out collisions against all the different angles, corner conditions and so on. It struck me as being a bit like being on a space hopper, which would be an interesting basis for a game. Being on a space hopper is clearly quite a silly way to spend time, so it would be have a quirky comedy angle. It's name would be Hannah on a Hopper, because it sounds silly and intreguing enough to draw people in.

Unfortunately, whilst it was a fun sounding concept, the gameplay prototypes just didn't play all that well. It seemed that whatever I tried there were big flaws in the way the hopper moved about and bounced that just didn't feel all that good to control. I shelved the idea, until inspiration struck again...

WSJ: Why choppers?

I was reminiscing about old games with a couple of friends, and brought up Zeewolf on the Amiga. It was a 3D helicopter game where you controlled the chopper with the mouse, and flew about completing wartime missions. I was wondering how you'd go about implementing such a thing in code (as all programmers do), when it struck me that the Hannah on a Hopper engine would actually cope with it really well. I put a prototype together that night, and it worked beautifully. Hanna was suddenly in a chopper. The quirky humour element remained in my mind, and persisted through to the final game. Likewise, the forgiving gameplay I was looking for in the space hopper game remained, and I was determined to build a helicopter game where you don't have to be careful of the walls and where you can make mistakes without penalty. For example, the helecopter is only destroyable due to a technical limit in the physics engine.

WSJ: Who's Hanna?

Back at the start, it struck my rather cynical mind that a girl on a space hopper would likely generate more clicks on the game than a boy. Hannah on a Hopper reads with a certain rythem and bounce that prepares you for the sillyness to follow. Dropping the 'h' and modifying the 'er' to 'a' helps emphasise the wordplay: Hanna on a Hoppa. And thus Hanna was invoked into the world.

If you look into the cabin of the chopper, you can see Hanna made up of very primative shapes. This is partly because the game as a whole deliberately uses that style for the graphics, but also because one of the gameplay prototypes of Hoppa portrayed Hanna as a sort of ragdoll with primative shapes for limbs. The idea was that she'd bounce around in a pretty silly way on top of the space hopper as you moved about the screen, but it didn't really work that well. I did like the way she looked there though, so transferred the style into Hanna in a Choppa.

WSJ: Have you ever ridden a helicopter before?

I have apparently ridden in a helicopter, but I honestly can't remember it at all. I was pretty young, although I'm told I was old enough that I should remember it. Plus it's something you'd expect to remember. I'm suspiscious that my mother made it all up. After all, she seems to invent new relatives I've never heard of quite frequently.

WSJ: And could you explain the color scheme?

There's not a lot to explain! There's a generous helping of black, and everything else is orange. Except the wonky border, which is meant to blend in with the site so the game window doesn't look square. The illusion is rather broken by Kongregate's big gray frame they put round it, but the idea was there. The simplicity of the colours came from trying to find something that would stand out and beg to be played, whilst also hiding my inability to draw properly. It's also quicker to produce monochrome graphics, and they render faster in Flash so everything plays smoother. One final bonus of monochrome graphics is that they help hide any overlapping objects when the physics engine throws a wobbly. Like a lot of physics engines, it doesn't deal with tall piles of things very well and items at the bottom can get crushed into the scenery.

Plus it's fun to think I've made over a million people see orange spots all day long! To anyone I've given eyestrain, erm, sorry.

WSJ: Also, I'd need your age, location, and occupation.

I'm 32ish (it's so easy to lose count), live near Bristol in the UK and am a freelance programmer. I specialise in games, but also do websites and other webby things.

If you liked Hanna in a Choppa, you might like it's spiritual successor developed in conjunction with Aardman Online: Invention Suspension.

WSJ: How far do you live from Aardman?

I'm really close to Aardman - their online department is in a studio in Bristol, and I live just on the outskirts of Bristol. It's maybe a quarter of an hour on the motorbike, tops. I've done a few games with them now, they're a brilliant bunch of people to work with.

Long overdue makeover

June 6th, 2009

Finally, I've got round to giving its much needed makeover. The new site is geared towards touting my freelance abilities instead of the random malarkey of the previous site. All the old content is still available, should you find yourself in desperate need of random malarkey.

The new site runs on WordPress (ooh, shiny), with a custom theme (ooh, pretty) and has just about all my previous webby-work in it (ooh, um, contenty). There's lots of tags and categories to help you find stuff you might like too, so take a look!

If you spot something broken, comment here or on the site, and I'll fix it. Probably.

A Brief History of Chris

May 6th, 2009

I wrote this for a forum entry. It wasn't meant to be this big, but since it is, I thought I could post it here too. Here we go then, with A Brief History of Chris. It was a programming forum, so it's focussed on my professional life rather than personal, if you see what I mean:

1. Faffed about with Amstrad CPCs waaaay back. Started by typing in listings from magazines. I remember typing the first one in without knowing that the enter key gave me a new line, so padded them out with spaces to look like it did in the mag. Needless to say my listing didn't work. I learned fast though, and could code a mean pile of spaghetti in Basic before too long.

2. Got into AMOS Basic on the Amiga. Suddenly there was actual power at my fingertips, which was just great. AMOS Basic was easy to use and gave
you all the hardware's power to do things like overscan scrolling, sprite manipulation, sound and so on really fast (for the time at least).

3. Went to uni doing Computer Science. It didn't teach me much about programming, but was did get me a string of really dull programming jobs afterwards. I'm the guy who programmed that little box of hardware that nobody ever sees that sits in a field reporting water levels. Fear my awesome fame! Ok, so it wasn't glamorous, but it did pay the bills.

4. Got intensely bored of writing code that I didn't care about, and learned Flash 6 then MX over about a few months of evenings. The intention was to make a dramatic career swerve into things I enjoyed doing, in a location that I liked. I got a job with Hyperlaunch (a digital marketing agency in Bristol). It was a sizeable drop in pay, but a massive hike in fun. It was also bloody hard work, but I ended up producing many many creative things (very often games) for big names that I'm pretty proud of.

5. Hyperlaunch's "way of the project" was to get things done as quick as possible. It was liberating in a way, but also often led to a feeling of not having given a good idea enough of a chance. It was also high pressure and low pay. I figured I could do high pressure and low pay all by myself and jacked it in to go freelance.

6. Freelance worked out pretty good so far! I had a couple of contracts right off the bat as I left Hyperlaunch, which gave me an encouraging kickstart. Then I sold my first private game, Hanna in a Choppa, to Kong for a decent chunk of money and it's been all go from there.

And that's pretty much it. When I went freelance my main concern was that I'd never find enough work to fill my time and pay the bills. Somehow though, I have even less free time. I have endless ideas I want to try out, but am struggling to find time for. Really must rebuild my ancient website too, and update my blog, and, and...

Skulduggery Quest Postmortem

September 15th, 2007

At work we recently built an RPG game promoting the children's book Skulduggery Pleasant. It is a bad game. You can play it if you like on the link below. Register and complete the game, and you might win a Wii even (chances are pretty good as not many people are going to qualify for it).

Since the book is based around a character who is dead, it seems appropriate to do a project postmortem. The company has spent a considerable amount of time making the game compared to how long most projects take for us at least. Overall it is a much larger undertaking than we normally attempt and it has multiple mini-games built in, each of which could be a typical game project in its own right:

Hub: Walk around in a vaguely Zelda-like fashion, exploring and picking stuff up. This is intended as a sort of story-led role-playing-game section that takes you through the other mini games.

Spot the difference: Just the basic spot the difference game transferred to a computer. You get a different puzzle made up each time so it doesn't become completely trivial to solve if you replay.

Magic Levitation: A physicsy lift 'em up. Not sure I've played anything quite like it before - you have a magical levitation ability that you have to train up until you can chuck the item you need out of the window.

Cave Exploration: A bit like the old Amiga game Commandos. You have to find the final important game item whilst evading the sight of the guards.

Individually, each mini game is amusing for a bit. The big problem with the game as a whole however is the lack of cohesion. I think this stemmed from a lack of adequate planning in the early stages, leading to a fair bit of making-it-up-as-we-go as the deadline encroached. What we ended up with was a nice enough game engine for an RPG, but with no story or other characters to interact with. For a story driven game, having no story sounds like a bit of a deal breaker to me. And if there were a story, having no characters also sounds like a problem!

There's some neat code running under some of this, despite the lackadaisical gameplay experience.

Hub: Whilst walking around, you can pass both in front and behind most objects. I came up with a method to do this that doesn't require constantly swapping the depths of everything. There are two copies of the clip that contains all the scenery objects positioned directly at the same spot on screen, with your character sandwiched between them. Each item's position on screen is compared to the characters. If it is above the character then the back version is set to visible and the front invisible. If below, the other way round. Flash's _visible property works internally by simply skipping the object when rendering to screen, so its very efficient this way.

I wouldn't recommend you build a similar system however! There's a downside (isn't there always). Whilst it works really fast and reliably with one moving object, if you add any more you can't guarantee that its possible to sort things still!

Levitation: I've been developing a lightweight springs and masses engine for a while now. It was last in use on the Rant game, and before that to do a string effect on Paul Steel's site. Each iteration the springs get more stable, the masses collide more realistically and the efficiency of the engine improves. At some point I'll try and do a game purely based around this engine - I have something unusual and interesting in mind!

Anyhow, the physics engine grew a couple of features for this game. Attractor and repulsor masses for a start (to do the actual levitation bit). The game worked beautifully with an attractor mass - it was like trying to pick things up with a weak magnetic ball. It wasn't all that easy to play however so I made it a repulsor following the mouse position instead, and got a lovely floaty feel.

The collision engine got an overhaul too. It now has a concept of collision sets. This is a way of tagging a mass such that it knows not to check for certain types of collision that can't happen, or even that we don't want to compute to help the game effects. There's another major performance enhancement gained from sorting all the masses along the x-axis. The sort routine is built into Flash's runtime engine and hence almost free in terms of execution time. Most of the Flash built in stuff runs really well, but as soon as you try and do something complex and algorithmic in ActionScript (version 2 and below that is) the inherent sloth of the language's dynamic style means everything grinds to a halt. Anyhow, after the x-axis sorting, masses are only compared until one is found on an x-position that cannot collide no matter what. This runs in both directions from the mass in question and the search is culled beyond the discovered limits. This gives an impressive performance boost overall.

I've made pretty heavy use of Flash 8's new-ish bitmap processing for graphical effects. Push the light around with your magic, and watch the shadows. Its a subtle effect but the shadows move around depending where the light is coming from. Shadows get longer, fainter and adjust their position all in realtime. This is all done using the new drop-shadow filter on each of the graphical objects in the scene, and a bit of trivial trigonometry. A simple effect, but powerful, and I haven't seen anyone else doing it yet.

The graphical effect of the magic itself is scripted too, rather than an animation. Particles of magic are placed onto a bitmap each frame, then the bitmap is faded and colour transformed via yet more filter effects. Over multiple frames, moving things leave trails across the screen. Pretty.

Caves: The base engine for the caves section is identical to the hub. I can hear what you're thinking (if you're still awake). You're asking how it can have NPCs wondering around when the system can only cope with depth sorting against one moving object. You weren't asking that? Well you're getting the answer anyway.

The NPCs follow a set path. They are at a set depth with respect to the walls etc, and are duplicated in the same way (in fact, they're just objects in the world like any other). If you pick their path and depth in the scene carefully, you can engineer it so that they don't look wrong. It just means you can't have an NPC wander about freely as they can't walk both behind and in front of an object without causing odd glitches. On the final screen the baddies do laps of an island-wall, which seems to break the engine's rules again. The trick is that the baddies don't actually go behind the wall at the top - they just stay above it a little. Look carefully and you might see their shadows glint above the wall rather than behind it.

Visual line of sight 'vision cones' were a challenge too. It isn't all that hard check if a particular point on screen is in sight of another particular point. You just cast a ray between them and see if you hit anything that blocks sight along the way. Or if you have the walls in vector form you can check for collisions mathematically with a line intersection check.

To show a cone of vision however, you have to run the above check for every pixel that might be in sight. That's generally a hulluvalotta pixels, and infeasible for realtime Flash games.

I'm fairly proud of the technique I invented to get sufficient performance here. I first cast a shadow off the back of each of the wall segments to the edge of the screen. This is done by simply projecting the end points of each segment out plenty of distance and joining the dots. This polygon is then drawn to a memory bitmap with the drawing API and clipped to the visible area. Flash is superb at doing this sort of manipulation as long as the shapes are simple, so there's only a minimal performance cost here.

Once the shadow of every wall is drawn (as if the enemy in question is a light source), we have a set of pixels that the baddie cannot see. A little bitmap magic to invert this, and we have a mask we can apply to its vision cone drawn complete. Job done - our baddie can't see through walls anymore.

One nice bonus with this technique is that we get almost free line of sight tests between the baddie and any point on screen. First do a hitTest against the complete vision cone shape. If the test succeeds, do a pixel colour lookup on the mask bitmap at the appropriate point. If that point is within a shadow, we're out of sight. If not, we're visible. HitTest and getPixel32 are both lightening fast.

This technique has a few unavoidable downsides. Firstly it uses two large bitmaps for every baddie. This means lots of memory allocation (bad for old machines) and lots of pixel setting (bad for any machine in Flash). Its setting all these pixels every frame that costs most of the time in this routine, even though those pixels aren't used directly on screen. There is also some kind of bug in the Flash player that leads to rapid memory leakage. Switch screens and you lose a meg or two of memory as the new baddies are generated. You also lose a smaller amount each frame. I eventually traced the leakage to a line that reads;

clip.cacheAsBitmap = true;

Without the line, no memory goes missing. With the line, megs per screen. Doesn't seem to matter if you turn the caching off later, you still lose the memory. This is something that the Flash player is meant to entirely manage internally, rather than it being the programmer's responsibility. The same behavior exists on the Mac player too, curiously.

Final lesson learned: On the PC Flash player, Key.isDown(1) is a fine way to read if the left mouse is pressed. Its a fine way to find out nothing at all on the Mac. That's the first really significant difference I've found cross-platform with Flash. A testament to just how well the player is built and tested!

Still here? How determined of you!

This week I are mostly been reading...

September 15th, 2007

A pretty book about mathematics and programming

An enlightening book about the mechanism of evolution

A beautifully written yet brutally filthy diary of a London call girl

And I can recommend them all!

Email Revolution

September 15th, 2007

You may be too new to the internet to remember email in the early days. Everyone now associates it with the chores of wading through spam, impersonal communication from your colleges and hoping your message doesn't get filtered by one of the many protective layers most companies have.

Time was, email functioned as a guaranteed way to get a message to someone you knew. If you sent an email, it would either arrive or you'd find out why not. If you had email waiting for you, it was exciting - like receiving a personal handwritten letter in the post from an old friend. Nowadays, the cherished personal email is likely to be destroyed automatically because the server decides it is spam. Actual spam is just as likely to arrive and take over your computer with a virus.

So with this in mind, I propose a new two part email manifesto:

Part A: Protocol

This is the stuff that runs underneath to pass email from place to place. You don't need to know about it, but your computer does. The current protocol system was built many years ago where the internet was filled mostly with geeks who didn't really want to harm anything, so it isn't appropriate now that the scam artists and marketers have moved in.

1. You can only send email if both you and your server can be strongly authenticated. At the moment more or less anyone can pretend to be more or less anyone else really rather easily. Strong authentication of your identity would fix this.

2. Your ability to send email can be revoked if you don't play nice. This would work at a user and server level, so if you act as an idiot then you can be banned from emailing people. Or if you run a dodgy server to send spam, that can be banned in its entirety. Be good, or try your scams elsewhere.

3. Email clients will encrypt sent messages using a key requested from the recipient beforehand. This also gives the recipient an ideal chance to not receive email from you if they don't want to - if they don't give you their encryption key, you can't talk to them. Tough.

4. Encryption keys shall only work for the authenticated person they were given to in the first place. Ie, if gives a key to, at least the ability to spam Bob can't be spread to

Part B: Email formats
Currently there's a mess of formats hacked over the basic original idea of sending simple text. You can send HTML, rich text, executable code, embedded video, links out to other resources and all sorts. Everything beyond text is open to some form of abuse, so your email client has to have loads of rubbish to reign in that usage. Things like the email client asking you if you want to download images because they could be used as tracking. That's the software manufacturer deferring their security responsibilities onto you by asking you a question you can't possibly hope to answer.

1. Plain text only. No you can't have that in bold. Nor italics or underlined. Tough. Get your point across with words, not fancy colours. And no proportional fonts either.

2. No attachments. If you want to send a file, you have to uuencode it. If you want to receive that file, you have to decode it yourself using the appropriate tools which may not be built into the client. If you don't know what uuencoding is (and won't find out for yourself) then you can't be trusted with a computer and shouldn't have access to whatever file was sent to you anyway. Take up knitting instead.

3. Top-posters will be banned after three offenses. Relative newcomers to the internet don't know that it was once the height of bad manners to post your response to an email at the top of the mail. The proper technique is to let your email client indent your friend's text with greater-than symbols at the start of each line, then to write your responses just below the relevant bit. This works to preserve context, and everyone can remember what on earth they were all talking about in the first place.

This article is a rant of course. None of the things above are really workable because people are happy with their colourful fonts and top posting and trojan executable attachments. People are used to spam and forget that it wasn't always like that. People accept that every now and then their computer will be demolished by a virus.

Wouldn't it be nice to go back to the old ways though?

At least for aging computer geeks who can actually remember them.

Play with knowing the future

September 1st, 2007

This is an experimental gameplay simulation of pool. Don't expect a full finished game - its just a toy really - but you may still be surprised by the way this plays. This is Oracle Pool by Jonathan Blow:

The twist here is that you're playing pool with a superhuman ability to see the future. As you line up the shot (wasd to aim and set power, z/c for fine tuning) the computer quickly figures out the future of your prospective shot and displays the outcome for you.

Granted Team 17 did this with their Amiga pool game years ago, but computers then weren't powerful enough to see to the end of the shot that fast. They are now.

Things to try:

1. Aim at something and set the power to minimum. Gently increase the power and you'll see how the first collision happens. Fine tune the direction to instantly visualise how the direction is affected.

2. Line up an absurd trick shot. Use the above idea to aim the first colliding ball at a second. Adjust the power some more until the second ball is hit. Fine tune and repeat. Can you get all the balls in the corners in one go?

3. See how hard it is to set up a 4 ball cannon. We've all tried a cannon where you hit ball A, intending for it to hit ball B into a pocket. The more ambitious pool player may have tried to set up a 3 ball cannon where ball B then hits C into a pocket. How much harder is it to make the shot with each extra ball added in? Now you can get a feel for the probability of making those sorts of shots.

4. Search for the magic opening game winner shot. I've often wondered with some pool sims whether there's a particular shot that'll pot the black from the break. You'd imagine with the chaotic ill-conditioning of the balls' interactions, the possibility is there. Take a look. Is it? (use 1, 2, 3 keys to set different initial rackings)

5. Get a feeling for the chaos effect. Yes, small changes in the initial conditions will lead to large changes in the outcome. Usually. But line up a break with full power and use the fine tuner. It won't necessarily lead to as much variation in the final positions as you might expect. You'll often see pairs of balls end up in chaotic positions with small changes, but most of the rest of them seem to land more or less in the same place. You should be able to get a feel for how there are windows of continuous change, with singularities of sudden total change (presumably an early collision is now missed or similar). Wouldn't it be great to be able to try this with real life and test if the butterfly effect really exists!

6. Be surprised by still not really knowing the future. You can see how the balls end up, but you can't really see how they get there until you take the shot. Aim at a group of balls with plenty of power, and imagine how the interactions will take place. Take the shot and see if you were right. I bet you get it wrong more often than you nail it.

Snoozy Mario kicks ass

September 1st, 2007

I try to avoid posts that are just links to other things, but these are too good to miss. Cunningly designed levels for Super Mario World that are obscenely hard, unless you just sit back and do nothing on the controller. They start good, but get sillier and sillier as they go along. If you're short for time just see the last three or so.