And in the showing-games part, there was Dry Ice: a top-down local multiplayer game in which all four of you control craft that go invisible – even to you – until you fire.

(I talk more about both these things in the latest Crate and Crowbar podcast)

I was there partly to show both the games I’m working on, get people to play them, and ask them which they preferred. That forced me to get both in suitable shape to be played by strangers: as soon as I committed to doing it, I realised the grappling hook game needed objectives to make the co-operative movement useful, and Heat Signature needed visibility tweaks and player guidance to make it comprehensible.

Once I had a build of each ready for IndieCade, I made videos to show their current states to the internet too. The internet spoke pretty clearly: the grappling hook game’s video has about 3,000 views, and Heat Signature’s now has 27,000 and got coverage on big gaming sites.

At IndieCade, though, the first three people to play both prototypes all said they liked the grappling hook game more. Two people said they were more excited by Heat Signature at first, but changed their vote after playing the grappling hook game. And after around ten people had played or seen both games, the votes were about 60% in favour of the grappling hook game.

That’s not a significant lead, and a tiny sample size compared to the internet, but it’s alleviated my worry that the grappling hook game might have been really far from working. The build I showed has lots of extremely awkward control problems, and I think with a few simple fixes it would have got an even better response. As with Gunpoint at the IGF in 2012, lots of these were things I knew were problems, but wasn’t 100% sure how to solve until I saw people struggle with them right in front of me.

It’s always been the plan to make both games, and it still is. I was showing the two partly to force myself to focus on what each one truly needed to be playable, partly to see if either one of them was just not going to work for people, and partly to see which one it makes sense to finish first.

It seems like they both work, but Heat Signature will be a lot quicker to finish. I’ll keep working on Grappling Hook Game in between – I’m excited about making those tweaks – but I have a clearer picture of how to prioritise them now.

Speaking of which, I talked a bit about both games, and story in Heat Signature, and the appeal of sudden death, in this here interview.

Here are some more photos of IndieCade and New York.

Thought I’d take a break from programming talk to get into game design, and how I approach it. I am aware my mug is ridiculous – it’s an old GTA III promo one.

I’m bad at shutting up once I get talking about this stuff, so I’ll also summarise the basic points in this post. Not all of this stuff is in the video and not all of the video is in this – good summary Tom.

Starting

I usually have an idea for a game when I’m excited about something else. With Gunpoint, it was thinking of cool ways to infiltrate buildings in Deus Ex.

For the Grappling Hook Game, I was watching a great Chinese/Korean heist movie where they use a lot of ropes (it’s on Netflix: The Thieves), and it clicked with all the rope-related moments I’d loved in Worms and Chaos Theory co-op and Rainbow Six: Vegas.

And for Heat Signature, it was an old idea I’d had for a triple-A 3D roguelike, which I’d always assumed to be impossible. I got talking to Graham about how it might work in 2D, and the more we talked about it the more doable it seemed, and the less I felt it needed to be anything else.

With all these, what turns it from ‘something I’m excited about’ to ‘something I want to make a game about’ is a conviction that this exciting, magical thing can be compressed down to a simple set of rules. Rules that wouldn’t just be a crude shadow of what’s cool about these things, but actually condense what makes them exciting, and generate that excitement again and again.

Making Things Modular

When there are big sweeping unknowns in how I’m going to handle something in a game, they usually get cleared up when I find some way to classify what needs to fill that gap, to summarise it as a simple template that can be varied and repeated to create things that’ll be interestingly different.

In Gunpoint, the question of “What kind of things can you hack?” was answered when I figured out how to define these things: each one is an electrical device, each one can be connected to any other, and each one can trigger whatever else it’s connected to. From that template, I can fill the levels with these crosslinkable ‘modules’: light switches, electronically locked doors, security cameras, trapdoors, etc.

How that same principle applied to Heat Signature is what I talk about in the video above.

Leaving Flexible Gaps

It’s very hard to answer all the unknowns in a plan all at once, and it doesn’t really make sense to – you need to make some of it to really bring into focus what it’s missing or what it would benefit from. So it’s good to leave these gaps flexible: I try never to say things like, “And I’ll have to come up with a full text parser to make AI-driven conversations work.”

It works out better if you keep that gap flexible: “And then you’ll talk to these characters, but I’ll decide how in depth and interactive we make that when I come to build it – anything from completely pre-scripted text boxes to dialogue trees to the nutty text-parsing thing.”

Having A Plan And Not Sticking To It

I do plan, a lot, but it’s more like navigation than a strict design document. I hate to waste time, and making things work is very time consuming, whereas purely theoretical design is very easy. Purely theoretical design can’t fully predict what the finished system will feel like or what the consequences of it will be, but it can foresee some problems, and when it does, it’s usually right.

There are an infinite number of things you could make – it doesn’t make sense to spend your time exploring ones that already seem problematic after a few minutes mapping them out in a text document.

But having that document doesn’t stop you from changing course when the thing you build turns out differently than you imagined. The plan for the Grappling Hook Game says only one character should have the grappling hook, to encourage co-operation. Now that I’ve built that much, playing as the non-grappling hook characters feels a bit paralysing, so now I’m figuring out if it’s viable to give them all grappling hooks in addition to their speciality gadget.

If that feels good, the whole game could become about latching onto friends and swinging off them mid-air to do ridiculous things. If it doesn’t, maybe the solution is just to improve on-foot movement or something. I don’t know yet, but the plan is always just ‘what seems most promising on paper – try this first’.

I’ve decided to let people play this prototype of my Grappling Hook Game at IndieCade East in New York next month, partly to force me to focus on what it really needs to be a playable game. After a week and a bit, here’s what I’ve got.

There’s now a second character who can cut through glass, and the grappling hook character can pull them up and swing them around to get them where they need to be.

The test level now has three buildings and five stealable objectives, just to give a feel for some situations and spaces that might come up. Obviously these buildings would have armed guards and staircases rather than holes in the floor. These won’t be the only two characters, either, though you won’t have to take them all to every job.

I don’t know if the game will be multiplayer – obviously that would be cool, but it all depends how hard that is to do. It will definitely be designed for single player first.

It’s starting to feel cool, now. Dangling from a rope to break glass or snatch things feels very heisty, and that’s the main thing I want to achieve at this point. It’s going to be interesting to balance that with the silliness: the grappling hook is just sort of inherently nuts, and leads to wacky stunts that don’t look realistic but are sort of hilarious. I’m not gonna worry about that clash until it really feels like a problem – there will be fall damage, and that might make some of these hilarious deaths rather than repeatable madness.

I’m posting occasional shots from development on Twitter.

I’m working on the grappling hook game again now, and I’ve got the rope wrapping nicely around things, going slack when it should, and even making sounds. In this video I show you how that looks, then – with fair warning – get into how the code works.

Sounds from freesound.org
Retract noise: eelke
Grapple impact noise: taylorsyoung

I’ve finally found the right blend of Unity’s built-in physics and my own custom equations to make the rope in my grappling-hook-game prototype feel strong, reliable and satisfying to use. I also added a lamp post and made some things blue.

If you want to hear about future updates, I’ll always post them on my Twitter.

For Gunpoint, I made a video about how fixed stories clash with interactive games, and how I was trying to avoid that:

My solution was to simply separate the two: the story is a pre-written thing that happens between the missions, and the missions are interactive playgrounds in which no plot events occur. The story is a bit interactive too, but only in certain limited ways I could easily account for.

Last week Terence Lee, of Dustforce fame, posted a huge examination of this topic on their blog, and over the weekend I finally finished reading it. It’s worth diving into if you like thinking about this stuff: its conclusions are familiar, but tracing the individual steps there lets you examine the issues in detail. I took about 800 words of notes while reading.

Adding that to my existing thoughts on the problem, here’s a summary of what the issue is, what the solutions might be, and which ones I think I’m going with for my next game.

The problem

• Stories are usually fixed. Usually a story ‘teller’ recounts a story that already exists in their mind, true or not.
• The unique thing about games is that they’re interactive: to some extent, the player decides what happens.
• If we let the player have a say in the story, it’s hard to account for all the things they might want to do.
• If we don’t, their actions feel irrelevant, the constraints we put on them feel artificial, and the game is less interesting to re-play.

The solutions

1. Fixed story: in a game like Half-Life 2, the player has no influence on the story at all. You either do what the characters tell you to and it works out the way the writer wrote it, or you die or stop. I pick Half-Life 2 because it makes this work: I loved the game and cared about the story. It doesn’t feel ideal, though. The story doesn’t add anything to the action or vice versa, it was an extraordinary amount of work to create, and the story gets less interesting each time you replay it.

2. Chooseable story: in a game like Mass Effect, all of the story is pre-written, but you often make big decisions about how it plays out. By the end of the series, there are a huge number of possible eventualities for the characters and races that come about convincingly from your decisions. But you’re still only choosing from a discrete number of eventualities that have all been catered for by the writers, which means a lot of work for them and limited possibilities for you.

3. Generate minimal story: in Spelunky, you’re an adventurer delving into some caves. Everything else is generated by the game’s systems, which are universally consistent and create new experiences every time. The trade-off is that what it generates is rather vague in story terms.

You might do something mechanically interesting to save a damsel, but she’s just ‘a damsel’, a mindless placeholder for a person with no character or uniqueness. It does a great job of making you care about these elements for mechanical reasons, but the stories it generates read more like (good, complex) action scenes than anything with plot or character.

4. Generate rich story: a game like Galactic Civilizations 2 puts you in charge of a civilisation and gives you a lot of choice in how you deal with others: war, peace, trade, non-military rivalry, secret deals to screw over other civs, etc. From what I understand Crusader Kings 2 is even richer, letting you hatch assassination plots against particular members of particular royal families to shift the balance of power the way you want.

These games generate high-level story – ‘plot’ – through their mechanics, and express it through pre-written dialogues that may crop up multiple times. That means they might not be entirely convincing – every few turns, the Drengin in GalCiv2 threaten me with the same line of dialogue about demanding tribute. But there are at least named characters saying specific things, and in GalCiv they have a lot of personality.

These games are probably the closest we’ve got to merging interaction and story in a way where both really add something to each other. But they all tend to be about managing a civilisation, which is just one very particular kind of story.

For my next game

Gunpoint mostly used solution 1. After processing this for a few days, and writing a few thousand words of possible approaches and internal argument about them, I think for GHGC I’m going to aim for a combination of solutions 2 and 3: Mass Effect and Spelunky.

I won’t go into how exactly, until I’ve had a chance to try it and see if it works. But the upshot is, I won’t be doing anything completely radical to merge game and story. Just picking the bits I like from things that already work, and finding exciting ways that they click with the concept of this particular game.

Further thinking

I am still interested in ‘solving’ this problem, or at least coming up with a solution that doesn’t have the same drawbacks as the ones listed. But it really takes a game concept that was built specifically to tackle this. GHGC is a specific idea hatched with a very different goal, and one that fits really well with ways we already know game and story can co-exist.

I do have a game idea that would tackle it directly, though, which I hope to make at some point. It comes from questions like these:

• Why are most of the richest story generators about managing people instead of being one?
• If you never read the official Oblivion strategy guide, would you ever know about the orc who runs drugs from Cheydinhal to the Imperial City?
• What if we had solved how to generate cool stories, but we hadn’t solved how to let the player see them?

Yep, it’s got a grappling hook!

I have something in particular I want to do with grappling hooks that I’m not ready to talk about yet. But grappling hooking around is also part of a set of interactions that I hope are going to just feel really nice – to some extent this game would be about the pleasure of execution.

This is just a quick demo of how it’s working right now – shoddily, but well enough to give me an idea of how to refine it. I’m pretty pleased to have got this far in three days, despite still really struggling with some Unity stuff.

A question for experienced Unity users:

I’m having trouble understanding how I’m meant to make different components talk to each other.

I have one component that handles the ‘fire a grappling hook’ code.

In that component, I use a boolean variable called grappleAttached to keep track of whether we’re currently grappling.

Other components regularly need to know this information too.

The component that handles walking left and right, for example, needs to make those controls behave differently if we’re grappled onto something.

This is going to come up a lot – almost everything you can do will depend on whether you’re grappled or not.

The only way I know of having any other components access this variable is with GetComponent.

This seems to require three different lines of code: one variable declaration, one in Start to store the component as a variable, and then another wherever I want to check grappleAttached.

Is that really the best way to do it? It seems like a lot of mess, and a lot to change if I ever move that piece of code or rename the component (which seems to be difficult, but commonly necessary as I experiment with what each component should do). I’ve also been warned that GetComponent is slow.

Similarly, I’ve written a function to get the position of the cursor. Do I have to do this whole process in every script on every object that ever needs that information?

Thanks for any advice.

This is a brief look at the pathetic progress I made by the end of my first full day working on what might be my next game.

I have 5 different ideas I’d like to do, but one in particular has been really exciting me, so I’m prototyping that first. If the prototype is fun, it’ll turn into my next game. If it’s not, I’ll prototype something else. Part 2 below.

Most of what I’m doing right now is wrestling with learning C# and Unity, both of which are much harder than what I’m used to in Game Maker.

Here’s what I did on day 2:

I figured out how to get Unity to know where in a 3D space your 2D mouse cursor is pointing. It’s probably not the simplest or best way, but I’m terribly pleased with myself for getting it to work at all, so I made a video showing it off: raining blocks on the player and building little platforms for him.

Neither of these things will be in the game.

For anyone interested, I talk you through the code at the end, but you can skip that if you’re not interested in game programming. If you are, I will accept your scathing ridicule for everything I’ve done wrong in the comments below.

I don’t know how regular these will be, I won’t take you through every tiny chunk of code of course. It’s really just things I found interesting or am pleased with.

Subscribe to my YouTube channel or follow me on Twitter if you want to know when the next one goes up.