How did Sherlock live?

I've recently started watching the BBC's rather good New Tricks, in which a bunch of retired policemen solve old, unclosed cases. I've decided to do something rather similar - solve an old (by internet standards), unclosed BBC case. Namely, how did Sherlock survive the fall from the roof of St. Bartholomew's Hospital? In doing so, I'm either fashionably late to the discussion, or perhaps just an avant-garde of the inevitable renewal that will come ahead of Series 3 being released at some point in the relatively near future.

Before I begin speculating wildly, though, we probably ought to work out just what happened. I'm starting my description at what on my DVD is about 1:18:07, when Moriarty has just topped himself and Sherlock is spinning around in circles chasing his sleeve. Or something. 

Review: Kingdom Rush

This review was conducted on a Samsung Galaxy SIII running Android 4.1.2.

 Kingdom Rush is a fantasy tower-defence game for Android. No, wait, come back. I know we've seen a lot of these, but really, it's rather good. It's not original in any way, but it's got great artwork, doesn't take itself too seriously, and, most importantly, it understands its platform (but more on that later).

By now explaining the mechanics of a tower defence game is perhaps a bit unnecessary - we all know the rules, as Paxman might say - but it's probably worth pinning down the game's idiosyncrasies. KR eschews ideas of mazing (that is, placing towers freely in such a way that the enemies must take a longer path to navigate around them) and instead opts for pre-set paths and tower positions. There are four such towers: archers, who fire rapidly but do small amounts of physical damage; mages, who fire slowly but do large amounts of magical damage; artillery, which does large amounts of area-of-effect physical damage; and barracks, which produce hapless troops sent out to engage and slow the invaders. Each of these towers can be built and upgraded a number of times with gold picked from the pockets of fallen foes (automatically, mind - no Plants vs Zombies coin-clicking). At the highest upgrade level, you can choose one of two final destinations into which your tower can morph - for example, the barracks can become either a temple producing durable paladins, or a hut producing high-damage barbarians. Each of these final-level upgrades have themselves a number of abilities that must be unlocked for each tower - instantly disintegrating an enemy, for instance, or a large-area carpet bomb. While these additions (eight towers and around sixteen abilities) are hardly overwhelming in their complexity, they're enough to keep the levels lively and avoid  the needless over-complication often seen in games with a more dizzying variety of towers.

First Impressions: Sir, You Are Being Hunted

While this may carry a review tag, it's not really. Because, you see, Sir, You Are Being Hunted is currently in pay-to-enter pre-release alpha. So everything written below will probably be irrelevant before too long, much like everything else I write.

I'm sprinting through the Fens, clutching a stolen shotgun and carrying a rucksack full of tea and chocolate biscuits. I approach a rusting fishing boat lying on its side and clamber aboard to ransack the tiny cabin. Two dead rats, a lump of stilton and a bag of mints. I haven't eaten for a while so I start with the stilton and finish with the mints, in case I meet someone I'd prefer not to suffocate. I leave the rats and take the opportunity to look around me.

It's a grim Norfolk morning and the rising mist means I can't see far. Just on the edge of my vision there's a cluster of cottages so I head off, running at full speed through the long grass. I can't shake the feeling that something's not quite right. It looks like Norfolk, but there's a sense of unease and sadness - more so than usual, I mean - and every so often I see a ball of blue light flit away over the marshes. I round the corner of the cottages and run straight into a group of murderous robot gamekeepers dressed in tweed and sporting shotguns of their own. Ah. Definitely not Norfolk. They've all got the right number of limbs.

Class Reveal #1: Mage

I think it's time to start rolling out the class abilities. This week it's the Mage, a physically weak spell caster with an arsenal of ranged attacks and a tiny health-pool which demands that the player avoid damage wherever possible. What I'll be doing here is providing an annotated run-down of the character sheet (comments are shown C-style), and a short discussion below.

Developer Diary: Week 1

I had originally intended to give you the abilities and talents of one of the starting classes this week, but the original artwork that I wanted to provide with them has been delayed, so I'm postponing that till next week. If I haven't got the art by then I'll go ahead anyway. For now, though, you're stuck with my words; poor, monochrome substitutes for the glorious watercolours to come.

What I'm supposed to do here is talk about what I've done this week in the game, but doing so would be extremely dull as it's been mostly underlying engine tweaks and changes. There was one horrible moment when I realised that my entire approach to input-handling was wrong and thought I'd have to re-write from scratch, but after a pot of panic-coffee realised that I could fix it with three lines of code. So I did. But most of the time it's been very dull and sporadic because I've had to work rather hard on paying for the dull things like food and rent, and so I'd rather talk about mechanics and systems instead.

As this is the first post, let's talk about first principles. Originally I had a long list of these, but while I was writing them I realised that they were effectively all derived from two design ideals. So here they are.

1. Skill, not luck
I can understand, just about, why developers feel the need to include randomised elements in single-player content. If the player is performing a repetitive task, such as killing a large number of creatures, then random number generators (RNG) can provide a way to add mechanical diversity without having to actually make lots of new mechanics. Things like critical strikes and blocks and so on mean that players cannot perfectly predict what their actions, and the actions of their enemies, will do, and so have to play reactively to some degree - they can't just do the same things over and over again and get the same results. Similarly, randomly-occurring events, such as an ability having a chance to stun the enemy or give the player a buff, mean that the player has to stay on their toes to make the most of such opportunities.

That's all well and good, but in a multiplayer game it simply shouldn't be necessary. When I go up against another player, I automatically face the uncertainty that a basic, scripted computer creature has to introduce with RNG. Making an educated guess at what your opponent is going to do next is part of the skill of most games, and RNG destroys that because you simply just don't know if you're going to get unlucky with that 30% daze proc. And on the other side, it's extremely painful to be waiting for that daze that never comes.

I realise that many of the games that involve RNG of this nature often provide some way to modulate it by controlling player stats through gear and other abilities, but as this game is not stat- or loot-based I don't think it's relevant. Therefore, my aim will be this: I will not allow any element of chance to enter game mechanics unless doing otherwise would severely damage the mechanics.

2. Counter Play
In their episode on counter play, the Extra Credits team (drawing on ideas by Riot's Tom Cadwell) defined it as the principle that 'a mechanic or ability in a multiplayer game should increase the number of meaningful choices available to both the player using it and the player it's being used on'. This is a deceptively complex statement with which I do not entirely agree, and so I intend to give it a full examination in another post, or set of posts (I'd also like to cover the idea of 'fun v anti-fun'). For now, I think I'll simplify my interpretation of it into two statements:

I will not implement any un-counterable abilities.
Here I'm thinking of things like a WoW Paladin's bubble or a Hunter's deterrence - untouchable immunities (I know you can dispel bubble; that's not the point because hardly anyone can) - or things like a Monk's Touch of Karma where the opposing player's choices are effectively reduced to 'stand still and take it' or 'run away and take it from behind'. I'm aware that there are ways around all of these abilities, but I think people understand my point: actions which drastically reduce the target's number of meaningful choices for a significant period of time should simply not exist without an extremely good reason. And if that reason is balance related then your balance is broken already.

Having your meaningful choices significantly reduced should be a fail state.
By which I mean that if you're in a long-duration stun and can't get out, it's because you've played a long game of cooldown chess and lost, rather than it simply being part of the usual play. I'm thinking about things like forks in chess where you have to move your king because of check, but doing so means they can take one of your pieces with impunity. If you're in that situation it's because they've been clever or you've been stupid; the situation is unpleasant but it's your fault, not the game's. Losing control should not be taken lightly and should be a BIG DEAL rather than a standard occurrence.

Ok, I think that will do. The next update will be class mechanics, with or without artwork.

~Roxton.

Game Development Blog up

The development blog for my new game, Fight to the Death (working title!) is up at www.fighttothedeathgame.blogspot.com. You can also reach it from the link in the bar above. As soon as I have slightly less negative money I'll start hosting it properly but for now this will do.

~Roxton.

A wild game appears

I've been working - when I haven't been working on actual, paid work, or trawling medieval manuscripts for Arthuriana, or bothering the wildlife in the Outer Hebridees - on a new game, born from the ashes of my previous efforts. I'd like to properly document this, and so as soon as I've decided on a suitable name I'm going to start up a new blog specifically for that. This one, I think, will do for odds and ends such as the old Tribes guides and bits of code and reviews and so on, but I don't really want people to have to trawl through all of that. It's rather tempting to delete it all and start from scratch, but I can't quite bring myself to do it, so a new site it is. Vanity is like student politics - all the more intense when the stakes are lowest.

~Roxton.

Speech Recognition Macros 2: The Uploadening

So over a year ago I uploaded a video demonstrating some macros I had written using the Windows Speech Recognition setup. Quite a few people have asked for the files, and my plan was originally to upload them once I'd finished polishing them. However, then my hard-drive died and I lost them all because apparently I'm too stupid to do proper backups. It's only now, with a double library paper unstarted with its deadline 5 days away, that I'm desperately procrastinating enough to start from scratch.

So, here are the files.

HOWEVER

There are a few caveats that you really ought to read.

• These are not complete: some of the functionality shown in the video (though far from all of it) is missing because it required more complex code that I couldn't work out.
• Case in point: I spent ages trying to remember how I'd made the paragraph selection work; it's not there except for some failed code.
• Instructions on how to install the files and what the commands mean can be found here.
• You're going to have to resign the macros for security purposes. Instructions on how can be found on the website linked above.
• Open the macros using notepad or whatever your favourite text editor is and have a look at the files. If you see Click coordinates anywhere then you're going to have to change those to fit your screen (they were taken on an old 1024 monitor). I would do something cleverer but I just don't have the time right now, sorry. You can find your mouse coordinates using free software such as PointPos.
• When I first wrote the macros I hadn't thought about it, but it occurs to me now that you could get much greater functionality by using something like AutoIt, compile the script it produces to a .exe and then call that using the WSR macros.
• PLEASE DO READ THE FILES. These were written very quickly and while I have tested them on my machine you are going to have to work on them yourself. The code is pretty self-explanatory.

Maybe, when I finally get some free time again, I can sit down and write these out properly.

~Roxton.

Yakslapper: are the WvW titles unreasonable?

There was a thread on /r/GuildWars2 earlier today in which the poster lamented the fact that getting the Yakslapper achievement does not, in fact, reward you with the title "Yakslapper", but rather the much less interesting "Ultimate Interceptor". One of the comments there mentioned that the requirement was 1,000,000 kills.

One million kills.

That struck me as pretty damn high, so I went to check. GW2Wiki confirms this number, but doesn't give its sources, and I can't find any other . The problem with the GW2 achievement system is that it doesn't show you what the numbers are for higher tiers (nor the current tier, but that can be easily guessed), and so this figure seems to be based on pure extrapolation from the surrounding achievements. For example, I'm on Tier 2 of 5 at the moment, with 256 kills. You can tell that Tier 2 is probably 1,000 kills.

1,000 doylak kills, while high, is hardly unachievable given that the game has been out for several months now, and therefore I feel that I have to trust the figure for the next tier of 10,000. So far, so good.

At this point we hit the real problem with that wiki page: we simply do not know whether the next figures of 10,000 and 1,000,000 are accurate. That the wiki doesn't have the achievement point rankings for Tiers 4 and 5 is irrelevant because it doesn't have it for Tier 3 either, which we've already assumed to be accurate.

For now, let's assume that the page is correct and that to get the title requires 1,000,000 dolyak kills. Is this even possible?

First of all, how fast can one kill a dolyak? I'm going to set a really, really high estimate at 1 per minute. Let's say that you're a dagger/dagger Elementalist with Lightning Flash, permaswiftness and a full dps-burst spec. This would just about let you travel from camp to camp, killing a Dolyak at each, in about a minute. Hell, let's say that all you have to do is tag the doylak and another group travelling behind you will finish it off. We're stretching it here, but this is a possible, if not plausible, scenario.

According to the NHS, the average adult needs between six and nine hours of sleep a night. Let's assume that our would-be-Yakslapper falls at the lower end of that spectrum, and let's add an extra hour a day for meals and exercise and the like (yes, this is below the recommended amount for healthy living, but, let's face it, the majority of people working office jobs probably fail that requirement anyway). This leaves us with 17 hours a day with which to kill dolyaks. That's 1020 kills a day.

If the target is one million kills, that's 980 days, or roughly two years and eight months. Two years and eight months, doing nothing else whatsoever except kill dolyaks at an impossibly fast rate.

As a point of comparison, let's look at some other achievements you could get in the same time.

Excluding holidays, of course. It's also probably more expensive than killing Dolyaks, but on the other hand the government won't give you a loan to help you with your dream of getting a title in an MMO (I think).

Assuming that everyone you marry dies on their wedding night, and allowing one day for the ceremony itself, you can get married in the UK every 16 days.

This achievement is arguably more difficult, as it requires a wet-nurse (or some other way around the postnatal infertility), and, presumably, to be female.

Again, this requires you to be in England or Wales, and your victim must not die. Pleading guilty may also help you here.

Walking form Ulaanbaatar to Paris also counts towards this achievement.

So, yeah. It's probably not worth it.

~Roxton.

Bootnote:

All this is of course assuming that the 1,000,000 figure is correct, which we can't be sure of. And even if it is, there's always the possibility that ANet might lower it. But as it stands, it's a horrible, horrible achievement which should not ever be completed.

By the way, if one ran a bot which played continuously at the rate calculated above, it would still take almost two years.

Tribes: Ascend - The Generator Problem

Full disclosure: for a number of reasons I never played any of the previous Tribes games. While obviously this means that I can never be a proski or good at Tribes: Ascend (hereafter T:A), I think this just means that I can view T:A objectively.

There's been a lot of talk on the T:A forums and community sites about the role of the generator in Capture the Flag. Views range from 'the generator is completely useless and anyone who ever goes near it is terrible' to 'whenever we have the generator up we steamroll them; whenever it's down we get steamrolled'. As is often the case in these kinds of arguments, both sides contain part of the truth.

Let's start with the basics. The generator is located inside the base, though in a different place from the flag stand, and powers the base turrets and radar station as well as that team's pack deployables such as light turrets, force fields and jammer packs. It also powers the vehicle station (you can still drive existing vehicles if the generator is down, but not get new ones) and the core inventory stations (ones that have been called in still function without the generator).

All of this makes the generator appear to be pretty important. Without radar, you can only see opponents who are within a certain range and in line-of-sight, which makes spotting incoming flag cappers and other enemies much more difficult. The base turrets can two-shot a light class and most of the time can target enemies actually on the flag stand. Vehicles are cheap and easy to use, and can do a fair amount of damage. Likewise, force fields and light turrets are excellent at defending the flag and  generator, and without the jammer pack the Sentinel can have a really hard time staying undetected, especially if the opposition have their radar up. And for technicians and other defensive classes, inventory stations are extremely useful for replenishing ammo and forcing health regeneration.

The problem is that all these things cease to be true once you and/or your team reach a certain level of ability. If your Sentinel is doing their job and spotting targets (possibly tagging them as well) then you won't be as reliant on radar. Base turrets are too slow to hit a flag capper going at a decent speed, and in any case are easily taken out from the other side of the map with tactical strikes or mortars. Vehicles look like fun, but there is nothing they can do that a player of the right class can't do better (more on that later), with the possible exception of Shrikes - and, of course, they cost credits to use. Deployables are easily destroyed with strikes or shelling, both of which have the advantage of potentially dealing damage to (or indeed killing) defenders. Oh, and if a Sentinel is given away by a downed jammer pack  then they aren't moving around anywhere near as much as they should. Finally, suicide is an excellent substitute for the inventory stations, and can be one of the most useful abilities in the game if used correctly.

At the moment, most of the benefits of the generator being up, such as vehicles, fall under the umbrella of First Order Optimal Strategies, or FOO strategies. Extra Credits, who invented the term, define these as 'gameplay choices or strategies with a low ratio of skill in to power out'. Basically, they're things like the zergling rush or the Protoss deathball in StarCraft II or the noob tube (grenade launcher) in Call of Duty - techniques that are easy to execute but hard to counter. While to an inexperienced player they appear unbalanced, in reality they rarely affect high-level play, because by that point people know how to deal with them and have progressed to more difficult but more effective strategies. An example from T:A would be the motion-detector-turret placement in the generator room of Temple Ruins that I demonstrated in a previous video, which is extremely easy to set up but difficult for new Infiltrators to counter because they're not expecting it. Perhaps a better example is the Beowulf tank. It's extremely good at clearing base turrets and flag defences from a distance (depending on the map), and when one comes out new players are often hesitant to engage, because, well, it's a tank. However, they're not really any better than a Juggernaut at shelling the enemy base, and are much easier to kill because they're slower, bigger, and (this is important), much worse at flying. The difference is that tanks are much easier to use than Juggernauts, and you don't have to spend time upgrading them or learning how to play them. A good player who is not scared of the tank can solo it almost every time, meaning that at higher levels tanks become much less useful. (The exception to this is, of course, parking a tank in the generator room in Sunstar, because that's just hilarious).

That's not to say that these things have no place in the game: FOO strategies are vital for giving new players a sporting chance and giving them something to do other than give free credits to the other side. The problem is that almost everything the generator supplies is used in a FOO strategy, and at high levels can all be replaced by a mixture of the right classes and player skill. At that point, defending and repairing it becomes relatively pointless, and it makes more sense to replace your Technicians (the class most strongly tied to the generator) with Pathfinders or Juggernauts and just play straight-up Capture the Flag.

However, in public games people don't always have the skill level required to counter FOO strategies or replace them, and so the generator is much more important. Of course, what happens then is that one or both sides overcommit to generator play, pulling vital resources away from the flag. You probably never really want more than one, maybe two people attacking it anyway, but there is at least some purpose to it provided that you don't overload on either offence or defence. The problem is that because there's no match-making system, you end up with a huge blend of player abilities, to the point where you can have one Technician holding off five or six people attacking the generator; or alternatively one skilled Infiltrator, Brute or Raider living in the enemy generator room and killing all the Technicians and Doombringers who come to repair it.

This naturally leads to arguments, claims of imbalance, and accusations of bad play: high-level players don't realise the importance of the generator to low-level teams and call them stupid for caring (which they're not); and low-level players don't realise its irrelevance in high-level play and call the high-level players elitist and arrogant (which they can be). The problem is exacerbated by a number of classes (most prominently the Technician, Infiltrator and Doombringer) being balanced to some degree around generator attack or defence. Not only does this imply that the generator is important (I've been given all these tools so presumably I ought to use them), but reducing the generator at high levels to a mere appendix hinting at a depth and complexity that might have been makes large parts of these classes redundant. After all, why would you take a Technician over a Soldier when the latter has more health, more energy and a spinfusor along with hitscan weapons, if the light turrets are always going to be dead and the repair gun is never going to be used?

So, how can this be fixed? From the points above, the obvious plan would be to give the generator some ability that is useful (though not vital), and that cannot be replaced by high-level play. Tribes 2 did this by having the players spawn in the lightest armour and with the default weapons, forcing them to go to an inventory station to pick up their chosen loadout. While this probably can't be carried straight across for a number of reasons (no scavenging and a big spawn-flag distance would mean that losing the generator is basically a game over), it does form the basis for one possible solution, which would be to have players spawn with their chosen class and weapons, but completely un-upgraded. Going to an inventory station, in addition to its current effects, would upgrade the loadout to the level that the player has unlocked. This would actually be more important for high-level players, as they are more likely to have fully upgraded their class, while not impacting those with fewer unlocks to the same degree. It can also be scaled up or down by changing what items are granted by the default spawn (e.g. making the Pathfinder spawn with Thrust rather than Energy Recharge), which allows for more fine-grained control by the developers. There are lots of other solutions, from buffing vehicles to increasing the speed of base turret projectiles, but it's difficult to come up with something that doesn't push the balance inordinately towards the generator or break the game in some other way. Interestingly, a recently released competitive ruleset actually has the players spawning naked. We'll see how it plays out; as has been noted before, Hi Rez's general policy seems to be to implement first and fix later. This is a beta, after all.


Bootnote: This is the generator defence video:

How much energy does scrolling a mouse-wheel produce?

I've seen this image a few times in the last couple of days, and because I'm avoiding writing a research essay on Old English literature I thought I'd work out just how much energy scrolling a mouse-wheel actually generates.

The first thing to do is to work out how many times I scroll my mouse-wheel in a given period of time. To do this, I downloaded the Mousotron 7.0 from BlackSunSoftware, which records the number of mouse scrolls you make, along with a huge amount of other mouse-related data. I then tried to replicate an average use of my computer: I read Cracked.com; checked the news; replied to some emails; and did a little bit of work on my game. I also counted the number of mouse scroll 'clicks' (you know what I mean: the little bumps the wheel makes as it rotates) that were required to make a full rotation. I did this by putting a little highlighter ink on part of the wheel, and then counting the clicks as I rotated it. For my mouse, a Razor Naga, it took 24 LED-illuminated clicks before the highlighter ink reappeared.

After almost an hour of mucking around I stopped procrastinating and looked at the counter:

After 56 minutes the scroll-count stood at 1317, which is 54.875 full rotations - about 1 a minute, or 0.102 rad/s (1rps = 2*pi rad/s). Of course, I don't know if this is a usual figure for everyone, but, as I say, it was a pretty usual hour of slacking for me.

From here on I'm going to be showing my calculations in WolframAlpha, because that gives people a good way to check my maths. So, first of all, rotational kinetic energy:

This requires us to calculate the moment of inertia and the angular velocity of the mouse-wheel. The moment of inertia is

and uses the mass of the mouse-wheel and its radius. The diameter of the wheel is is almost exactly an inch, so the radius would be 0.0125m. I'm not really in the mood to dismantle my mouse to work out exactly what the mass is, but I'm guessing around 5g: a UK 2p coin is about 7g and has approximately the same diameter. It's thinner, but is also made of copper while the mouse-wheel is made of some kind of rubbery plastic. The width of the wheel is about 1cm. Therefore the moment of inertia is about 3.9 gcm².

Therefore the rotational kinetic energy generated by the mouse-wheel in a second is 2.0567*10^-9 J, or about 2 nanojoules. If we scale this up to an hour, that's about 7.4 microjoules, or the energy a mosquito needs to fly for about 46 seconds. To put that in perspective, my mouse requires about a quarter of a Watt to function: that's 0.25J/second, which is around 36,000 times more energy than the mouse-wheel produced in an hour of web-browsing.

Another example: if 9gag.com gets 5.5 million visitors per day, and each of those visitors spends a whole hour on the site, then the scrolling each day would generate around 40J, enough to power my mouse for two minutes and 40 seconds.

In conclusion, therefore, the energy used by scrolling the mouse-wheel is at best utterly insignificant. Yes, I'm aware that I'm missing the point.

Of course, these are all rough estimates. It's also worth noting that I've assumed a perfect conversion from kinetic to electrical energy, ignoring any inefficiencies that would boundless be present in the kind of tiny generator one would have to fit into a mouse to make this work at all. As far as I remember bike dynamos are around 80% efficient at best - I have no idea what kind of efficiencies are possible on such a small scale.

Game Maker Tip #1

instance_exists(obj) is a fantastic function that returns true if an instance of the object exists. You can use a general object index (for example o_player), a specific instance id (e.g. player or 100421) or keywords like all. I use it frequently to check if an instance still exists before executing code involving that instance.


However, be careful. instance_exists(0) will always return true, because it interprets the 0 as being a reference to the first object created. Therefore if you have variables in your create events or elsewhere which will be used to store instance ids, initialise them with name=noone rather than name=0.

Review: Phylo

Phylo is a browser-based colour/block matching game available to play here. Like the famous FoldIt, its aim is to 'recycle' the power of thousands of bored casual gamers to further a scientific objective, but while FoldIt concerned itself with protein sequencing (or manipulation or whatever the term is; I did engineering, damnit, not this namby-pamby squishy nonsense), Phylo has you sequencing (or matching, etc. etc.) genomes. If you're interested in the back-story Rock, Paper Shotgun has an interview with one of the scientists involved, but I'm concerning myself more with the actual gameplay.

The basic mechanics are extremely simple. You are given two rows of coloured blocks, and have to match them up with as few mis-matched colours or gaps in the sequence as possible. You can slide the blocks left and right (not up and down), but they can't change order and so shunt each other aside. As the game progresses more and more rows are added, and so it gets more and more challenging.

You gain points for correct matches, and lose points for gaps or mis-matches. Once you have arranged the rows so as to have more points than a computer-generated par, then you can add another row or finish the level if all the rows have been sorted. In some cases completing the level is easy, and the challenge lies in getting the highest possible score for bragging rights; in others simply reaching par is a challenge.

I found the hardest part of the game to be understanding the scoring. You get one point for every correct match; you lose one point for every mis-match; the first gap in a sequence loses you five points, with every subsequent gap losing you one more point; and you get more points for matching closely related species than unrelated ones. This last part is especially relevant once more rows are added, and prioritising which rows to match becomes important. The scoring is explained briefly in the tutorial, but you can't look it up while playing (thus violating one of the cardinal rules of tutorial design: that all information learned therein should be available at all times), and I couldn't find any explanation as to exactly how much more valuable closely related species matches were, which makes it much harder to work out what you should be doing.

It also took me an embarrassingly long time to understand how gaps work. It's not just about breaking a sequence: if you have one sequence longer than the other, then any space between the ends of the two rows also counts as a gap. So in the example above, the bottom row (the bat) has no gaps, but the top row (the cow) has two: one on the left (above the green bat square), and one on the right (from the orange to the green bat squares). Maybe I'm just really thick, but once I got onto four or more rows the scoring ended up feeling random and confusing, which made for a rather unenjoyable experience.

It wouldn't be so bad if the scores were displayed in real time, giving you some feedback, but instead the score is calculated every five seconds with a little red timer bar and an irritating blip noise, which means that you either have to wait or manually click a button to see if your latest move has improved your score or ruined it. This disconnects the player from any sense of feedback and makes understanding the already complicated system ten times harder. In, say, Bejewelled, this wouldn't be such a problem, but here the score is everything: your only objective is to increase it. I really have no idea why a timed update was chosen over real-time. Maybe it's an optimisation decision, but I refuse to believe that it could really save any meaningful amount of processing over simply having it update each time the player makes a move.

The other big annoyance is that these challenges are timed, which means that a good proportion of players fail to complete the challenge at all, let alone in an optimal fashion. The difficulty curve is what I'd describe as 'exponential with wobbly bits': the basic levels with three rows are absurdly easy; four rows can be pretty tricky, and anything more than that has a good chance of being fiendishly hard, though occasionally you'll come across an eight-row puzzle that can be solved simply by stacking all the blocks to the left. This is exacerbated by the time limit, which, as far as I can tell, is the same for all difficulty levels: I started off doing some basic three-row puzzles, got bored, moved to the next level and ran out of time.

Of course, a lot of these problems are due to the nature of the project as opposed to bad design. The scoring system is odd and confusing, but I'm not a biologist and presumably the scoring reflects the way genomes should be matched. The timer is annoying and significantly detracts from the play experience, but maybe from the designer's perspective it makes more sense to have a lot of people playing a lot of puzzles and finding lots of good solutions, rather than having people play a few puzzles for a long time and finding the best solutions. I just don't know; I wasn't on the design team and I'm not going to be using any of the data produced by the game.

Having said that, there are also a lot of problems that are definitely due to bad design: the intermittent score updating; the way that useful stats are only shown when mousing over a certain button; or that there's no way of abandoning a level once started without logging out. And why the relative values of related species matches couldn't be explained I have no idea.

I'm probably being too harsh. It's a free game for a good cause, and even without the feel-good factor of progressing scientific knowledge and being part of a big, happy crowdsourcing experiment it's more challenging and worthwhile than Bejewelled (though it's definitely more frustrating). I'd recommend that you go and give it whirl, but I wouldn't blame you if you don't play for very long.

Rule #66

Never wear a shirt that's darker than your suit.

Burnout

For the last week or so I've done absolutely no work on the game at all. Why? Because I burnt out on it.

For the last month or so I've been doing almost nothing but coding, drawing and designing, and it had begun to take its toll on me. I'm not a professional; I have other commitments, and, to be honest, I'm an innately lazy person.

The straw that broke my idling, sloth-like back was the realisation (hardly a shocking one) that I have absolutely no artistic ability, talent or potential of any form, and that making background artwork was much harder than I thought it was going to be. To be honest, I still don't know exactly how I'm going to deal with it, but hey, that's a problem for future me, and I hate that guy. If the worst comes to the worst I'll have to go and stand outside the arts building and "persuade" the least irritating person there to do some art for me. That's a sign of my near-negative artistic talent: I don't even know what the verb for making art is: is it "making"? "Creating"? "Doing"? Who knows. I don't even own a beret. Or a Macbook. And I don't smoke, and prefer to be clean-shaven. Terrible.

Anyway, so I took a week off. I wrote an essay on the complexity of Gothic villains, a translation of The Tale of Balin from Malory's Le Morte d'Arthur, and a commentary on the recursive microcosms present in Balin. I also learnt a new card trick, discovered a secret passage in the university, and played a lot of Starcraft II. A lot. I went from Bronze league to Platinum, and then fell back down to Silver, all the space of three or four days. It was fun, but now I'm fed up with it and so am ready to return to the game.

Because I'm making so little progress on the art front, I decided to implement something that I had intended to save for much later in the development cycle: multiplayer. At the moment I'm working on getting support for up to four characters - while more could probably be added without causing too much lag, it's a bit of a balance issue. There's full friendly fire, so it will be sort of self balancing, but that doesn't scale perfectly by any stretch. Once it's done and all the artwork is original (even if it's atrocious: at the moment I'm just using sprites from Realm of the Mad God) I'll start releasing videos.