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.