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.

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!

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.


Robots In Disguise

August 29th, 2007

Everyone my age remembers Transformers from their youth. Everyone young today remembers Transformers from the recent film.

So that's everyone then.

I was quite the fan when young. I had lots of the toys. I saw the films. I watched the TV series. I read the comics. Whenever you fondly remember something from your youth you tend to have a sort of predetermined distaste for any attempt to revive and modernise the concept. Imagine then my horror when I learned they were making a new Transformers film, and that I'd be working on a microsite promoting the line of new toys.

How could the new stuff possibly compare to the nostalgia-enhanced awesomeness of my childhood?

Luckily the new film is pretty damn good. It is pitched at just the right balance between serious, cool and self-deprecating humour.

Even better, the new toys are damn good too. We only had the big Optimus Prime and Megatron toys in, but both are pretty impressive. The Megatron toy is the lesser of the two and only transforms into a sort of alien airplane thing. The Optimus Prime toy changes into a very nice truck model via a really complex series of transforms. You keep spotting new bits about it that are cunning. For example, you split, pull out then twist part of the truck grill to become the feet. As you're doing that internal mechanisms move another part of the feet into position for you. There are similar nice touches all over the model, including hands adjustable fingers and thumb.

Anyhow, that's enough of a free advert for them. Now for the one they paid me to make. Click below to play out the Autobots Vs Decepticons in cool street-fighter stylee action.

I'm fairly pleased with a few aspects of this game. Since we started from the Turtles game we built a while back, we could afford to enhance a few features.

  • AI tuned separately for each character. Each enemy in Turtles was essentially the same AI bashing the keys of the other characters.
  • Mild element of learning in the AI. Use the same special over and over and it'll learn to counter effectively.
  • AI self tuning. If it starts to thrash you it lets up and plays a bit easier for a bit. If you kick its ass it gets more aggressive.
  • Better specials - from projectiles to transformation specials, there's more imagination to enjoy.
  • Matched characters. As part of testing I put both characters on AI mode at quadruple speed and let them slog it out. Over 60 rounds later, the results were too even to call!

Bristol Motor Club August AutoSolo

August 17th, 2007

For those who don't know, AutoSolo is a competitive motorsport event. Its a sort of cross between a slow Sprint and fast AutoTest minus the reversing sections. Americans run a similar style event called Autocross, not to be confused with grass track racing in the UK.

Competitors are only allowed to use road cars that have been driven to the event. Each car is timed around several tight courses made from cones. The total time for each car is added up with any penalties incurred for hitting cones, taking the wrong route and so on.

Having not driven competitively for over six months, my first run was a little on the enthusiastic side, with plenty of sideways action. I turned in a respectable time nonetheless, and pushed harder in the second run. Unfortunately the rigours of everybody's first efforts had taken its toll on a section of the tarmac, which had now turned to gravel. Hitting this whilst still overdriving sent me into a rapid spin, filling the car with clouds of dust. With my time spoiled I had fun sliding about on the remainder of the run, and resolved to tone it down for the rest of the day.

Toning everything down worked wonders for my times (it always does) and my next two goes were the fastest of anybody's on the same course. Despite that my overall time for the course was still beaten by the very experienced Carl Streatfield in his bright yellow Elise.

As the day progressed my lack of recent practice manifested itself in somewhat inconsistent times, although I had no more disastrous spins. Another couple of fastest individual runs put me first in class, although first place overall was taken by Carl who drove consistently well the entire day to end up just under 2 seconds ahead of my time.

It was an unusually busy day as a marshal too. In AutoSolo, the competitors take it in turn to marshal each others' runs, and on my first stint I was stood near the hairpin bend. You don't really expect to have to do much marshaling on a Solo. You just have to call in the odd penalty when people tap cones or go the wrong way. There's usually just about nothing to crash into, and cars run by themselves so shouldn't end up in collisions.

A tiny bike-engined Sylva Riot shot past and disappeared out of sight at the corner. After a few seconds I realised everything had gone suspiciously quiet and poked my head out expecting to see the car stalled and unable to restart. Instead I was greeted with the sight of a completely empty track. I briefly questioned if I'd imagined the car passing, before realising where it must have ended up - in the thick bramble bush on the left. I ran to help and found the car lodged right up to the wheels in brambles, but on the wrong side of the bush! It had found its way clean through a gap in the hedge and continued to turn until crashing into the back of the brambles. Thankfully the driver and car were both fine, although it took a little while to dig them out.

Later a Mini slowed in front of my marshal post and rolled to a stop on the grass next to me. After futile efforts to get it running again we had to push it back to the pits over rough grass. Quite a work out in the summer sun!

Overall the day went really very well, and everyone seemed to be smiling lots. I'm booked on the RosSolo for this Sunday, but entry will depend on getting a punctured tyre repaired in time. It seems I've picked up a big chunk of metal in the back left tyre somehow. The rubber I use isn't easily available anymore so I won't be getting a replacement. With a bit of luck I'll be able to get the carcass repaired at a local garage however.

I took lots of photos at the event. Zips of the better ones are available below. Some of the expressions on the competitors faces are well worth the download! Some of the images of the tyres undergoing tarmac-torture are pretty impressive too. I took video of my runs as well, and I'll post these in another article soon.

Best photos (9mb zip)
Other good photos (37mb zip)
Official results (pdf)

Phut phut you're dead

July 22nd, 2007

I went paintballing on a mates stag do yesterday. This is where you split into teams and play wargames with airguns. The premise is pretty simple: Get shot with a ball of paint and you're out until the next game.

I got a bit lost finding the appropriate entrance and ended up riding my bike down a loose rubble farm road. I was in the right place, but at the wrong entrance. I began to realise this when I smelled the distinctive scent of recent explosives and smoke was floating over the road. Full realisation only occurred when I noticed people popping up out of the treeline on either side of the road with guns. No harm done - just a tricky 3-point turn with a backdrop of a fierce firefight and I was on the right track again.

I hadn't been paintballing before. I learned many things.

  • Good road bikes make bad off-road bikes
  • Its quite surreal to accidentally ride a motorbike into a gunfight
  • Wearing glasses under a protective mask is difficult and uncomfortable
  • For each and every lens you wear, your probability of misting up and becoming effectively blind quadruples
  • Running around, running crouched, crouching behind cover, jumping about and climbing muddy hills is physically hard work and makes your legs ache a lot the next day
  • Hiding in good yet obvious cover may seem clever at the time, but you'll regret it. See this classic Monty Python sketch for details.
  • When hiding in good yet obvious cover, make sure you watch the rear entrance in case the enemy decide to flank round the back.
  • Getting shot in the back hurts
  • Getting shot in the finger hurts
  • Getting shot in the leg hurts
  • Getting shot in the arm hurts
  • Getting shot in the face: Hurts surprisingly little due the protective gear. Its still a surprise when everything goes orange though
  • No matter how much ammo you have, you'll always need more
  • Ammo is expensive
  • No matter how much you promise yourself you'll conserve ammo before a battle, you'll always open fire like its unlimited
  • Spheres make poor shapes for projectiles (See the Magnus Effect for details)
  • Taking the time to take aim on someone is wasted effort when your gun fires every shot along a different path
  • Taking the time to take aim on someone also lets them take equivalent aim on you
  • Taking the time to take aim on someone also lets them fire multiple shots at you
  • Corollary: Taking aim on someone who can see you will probably make them shoot back lots. This principal seems to work over and over until your opponents runs out of ammo. You can then stroll over feeling smug and finally shoot him. Assuming he hasn't got any mates nearby at least
  • Playing paintball can give you some appreciation of what real war would be like

Most of that list is clearly rather flippant. The last point is serious however, and is is one of the reasons I hadn't played paintball before. As a boy all things war/fighting/guns were exciting and fun. That's the same for most boys of course, at least partly because at a younger age we don't really understand mortality.

As we grow older we appreciate the reality better. War is about a large group of people fighting to the death. Each soldier is a person, with tens of years of elapsed lifetime including growing up, forming social ties, education, work, play etc. Each is expected to try and cause injuries to the people in the opposing side such that they cannot continue fighting. Each is asked to risk everything they can ever have on the random chances involved in things like firefights.

I went into the paintball games thinking I was probably a bit better trained than most of the other newbie players (I was an army cadet a long time ago and have fired plenty of guns). I was thinking my experience might lead me to survive in the games for longer than others. Might help me make less silly mistakes, or to shoot more effectively.

I don't think it made any difference. Getting shot seemed pretty random. Mostly I was hit by people I couldn't have seen, or by lucky shots that caught something not entirely behind cover like my hand steadying the gun. If it were real war, I'd be dead several times over.

If it were real war, I'd also have killed several times over. In one game I found myself in a particularly effective position. I picked off five opponents before running out of ammo and getting shot. In real life I'd have killed five people. In peacetime that would qualify me as a serial murderer. In wartime a hero, but still deceased.

A paintball travels at 170mph, stings and leaves a welt when it hits. An assault rifle bullet travels at 1900mph and smashes through skin, bones and internal organs when it hits. Clearly paintballing isn't the same as fighting with real guns as you are not risking your life or taking others. I'm capable of separating the two mentally like any intelligent adult. The analogy is still painfully obvious whilst playing however.