Sloth wasteth the sluggish body

You may have noticed that there have been no updates on the game development section of the blog for an embarrassingly long time now. I can make the usual excuses - I'm planning a wedding; I've got five essays and a book to write over the next three weeks; I'm too exhausted from work and am putting my free time into Hearthstone instead - but to be honest it's more because I'm lacking certainty in my convictions.

The problem is that I'm making a game where I should really be making a prototype. The foundations are all there, but currently the only way to actually play test mechanics is to code them in and then try them. This works, but takes a lot of time and effort because adding even quite a simple mechanic (e.g. an absorption effect) requires the alteration of a huge amount of existing code in addition to the new stuff piled on top. Oh, there are ways of mitigating the damage, which I've done, but the problem is that rapid prototyping just isn't really do-able with my skill-set and time restraints.

The solution to this, I've decided, is to take the game out of the computer and model it as a board game instead. There are, I think, a number of advantages to this approach. First, it makes rapid prototyping much easier. Instead of spending an hour unpicking my dearly-devised code I can simply print some more cards. Second, it forces me to simplify. There are always some mechanics which are better suited to a computer, even in turn-based games, but when you're having to map things physically it really forces you to question their necessity. For example, I'm currently running with nine (nine!) debuff categories, which can surely be consolidated. Third, it means that instead of having to worry about interfaces and so on (I know they're important but I don't want to be having to code an interface just to know if Frostbolt works as a mechanic) I can focus purely on the mechanics. Finally, it makes it easier for me to get my fiancée involved, and I value her opinion highly.

So, I'm going to go away and have a think about it, and get some cards and counters drawn up, and then when it's running I'll take photos and so on and show you all how it works.

~Roxton.

Patch Notes or: How I Learned to Stop Worrying and Love the Metagame

So right now there's a lot of wailing and gnashing of teeth going on because Blizzard have released their most recent patch notes for Hearthstone, and instead of fixing what the people on Reddit think is broken today, they've tried to fix what people on Reddit thought was broken yesterday. In particular, lots of people are angry about Mages, and Mages didn't get nerfed. In fact, claim some of the subreddit's more brilliant minds, the fact that things were nerfed that were not Mages means that Mages are actually being buffed.

As usual, the internet is overreacting, and here's why.

It's not actually that hard to make a deck that can reliably beat a Mage. People have been doing it for a long time, and it usually comes down to a combination of weapon (or other direct) damage, healing, and large minions. If you don't believe me, go and get the Trolladin running and try it out. Hilarity will ensue. The problem with this, as I'm sure you've realised, is that these three components fare extremely badly against the current popular metagame, which revolves around large swarms of cheap minions (Curi's Warlock deck is probably the definitive example of this). Mages are one of the few decks that can really deal with the swarm meta because of their large numbers of freezes and board clears, and so we have a Rock-Paper-Scissors arrangement: Trolladin beats Mages, Mages beat Swarm, and Swarm beats Trolladin. Reddit is angry because they don't have a deck that beats Swarm and Mages.

This isn't quite as unreasonable as it might sound, because currently the number of Mages is too low to make it worth playing Trolladin, but high enough to significantly dent the win ratio of anyone playing Swarm. Add to this the dominance of Mages in a recent tournament and you can almost understand why people are crying. So, if there is a problem, how can we fix it?

Making a physical Hearthstone set

I've been playing a lot of Hearthstone recently, and while I love it dearly, I do feel the lack of the physical element that accompanies other board/card games. In particular, I can't play it with my fiancée because she doesn't have a beta key. And even if she did, playing a game like this on two separate screens or tablets just feels silly. So, how can I make a physical version of the game that we can enjoy together? No, I don't mean a box with a tablet in it, cool though that undoubtedly is. I mean a real actual card game with cards and counters and the like.

Before we start, let's lay down some ground rules.

1. No-one is allowed to say "but that's impossible". You can recreate the entire game with nothing more than a pen, (a lot of) paper, dice and a stop-watch. If you have a digital stopwatch you don't even need the dice.
2. However, we want to make it as simple and easy to play as possible without changing the mechanics. Paper and pen (or more likely a small wipe-clean board and marker) is a last resort for cases like Lightspawn being buffed to 80HP and so on. I'm aware that other, real TTG/CCGs like MTG have wonderful things like damage counters and indicate status through card orientation and so on. Ideally I'd rather have something more obvious, even if it requires extra gubbins, because I've never played any other games like that and neither has my fiancée.
3. Finally, we want to make it as cheap as possible. This is going to be horribly expensive and I don't want to declare bankruptcy until I've accumulated enough debt to really hurt the bank. Obviously this is in direct opposition to our second objective, so it will have to be something of a balancing act.

Right, let's get on with it.

Review: Atlantis

Atlantis is a new BBC One drama set in the eponymous city. The story, such as it is, follows a young man called Jason who is allegedly a marine archaeologist or somesuch nonsense but runs a profitable side-line smuggling live pigeons inside his pectoral muscles. One day when out looking for his dead father, his submarine gets sucked into a wormhole and he washes up in the mythical city wearing nothing but a novelty necklace and a grimace reminiscent of a particularly unpleasant bowel movement, which he retains for the rest of the program. Whether running for his life, pulling an arrow from his ridiculous bicep, flirting with Ariadne or fondling a young, geeky Pythagoras, he is steadfast in his refusal to exhibit any emotion beyond a kind of pained surprise.

Review: Trine 2

Along with several hundred thousand other people, I picked up Humble Bundle 9 a few weeks ago. Often the case with these bundles is that there's one game you actually want, with the others effectively acting as ricin-free sweeteners. For me, that game was Trine 2, developed by Frozenbyte. I bought the original Trine many years ago and enjoyed it very much. It was a solid, occasionally quirky 2.5D side-scrolling puzzle/action game in which you control a team of three fantasy archetypes trapped in one body by the machinations of some peculiar magical artefact, and could switch between them as you saw fit. Overall the game was a lot of fun, with great effort clearly having been put into the aesthetics, sound and level design. Its quality is further marked by its admittance into the very select list of games that my fiancée actually enjoyed.

However, it wasn't without its problems. Enemy design was repetitive, presumably due to the limitations of a small studio; there was a really obnoxious difficulty curve that was practically horizontal for most of the game before turning into the Cliffs of Insanity for the final level (I'm not sure I ever completed it); and too many puzzles could be completely circumvented by means of stacking crates or having the mage create floating platforms, neither of which is a particularly fun activity. Finally, while there was local co-op (in the sense of buying another keyboard), there wasn't any LAN or IP/TCP support, which was a bit of a problem.

So, how has Trine 2 fared in its attempt to fix the problems of its predecessor?

First class is in

So, yes, I've been a bit lax on the updates, but that's ok because no-one is reading this anyway. Anyway, the game is coming along well. The Mage class is now fully implemented, and I'm about to start work on the next - the Rogue. Currently the only game mode is Hot Seat, but I've been playing a few games and I'm pretty happy. Obviously with only one class, and with only one player per team it's not particularly gripping, but it's enough to check the basic mechanics and get an idea for how the plays I had in my mind actually work. There's a lot of tweaking of numbers to do as balance isn't quite right yet, but it's getting there.

The eventual plan is to have the main game be a team-based tactical arena - two teams of three, with each team controlled by one player - and so ultimately balance will revolve around that - but I dislike the idea of hand-waving away problems in 1v1 by claiming that teams fix it all. Obviously if there's no other solution I'll take it, but I'd rather have deep balance that runs all the way down.

The biggest problem at the moment is the lack of art. Most of this is just a cosmetic issue - changing sprites and icons and so on - but things such as spell effects and animations do require some underlying code. I would release an alpha as it is, but currently the art that's not from MS Paint is from other games and while I don't mind a pre-release containing placeholder assets I don't want it containing other people's work. As soon as I have a stable, non-copyrighted demo I'll let people have it.

~Roxton.

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.