TOM FRANCIS
REGRETS THIS ALREADY

Gunpoint: The Setting

Wow. Response to my badly made video has been crazy, a whole order of magnitude more positive than I’d hoped. Actually slightly nervous now.

The best result of this is that a whole load of really talented people have offered their services, and many have already done great samples. There have also been a lot of very reasonable questions that made me realise my last post didn’t adequately define what I’m after. I called the current art a ‘rough guide’ without saying what about it should guide and what should be ignored.

So here’s a bit more about the idea for Gunpoint’s setting, look and mood.

Gunpoint is set in a big, largely empty city – or at least a largely empty part of a big city. It’s only about 20 years ahead of present day, so most technology is the same.

You’re a freelance spy. You get jobs from a site that lets agents choose from briefs written by anonymous clients. You wear a long coat and hat, and because you’re a spy, I would rather your face is either not clearly visible or has no recognisable features.

You’re the sort of person who acts very relaxed until he really needs to do something quickly, at which point you’re a flurry of motion and then back to trying to look nonchalant. I haven’t finalised your movement yet, but there’s a chance you may need to go from a casual shuffle/saunter/mosey into a semi-urgent run as you accelerate.

Through the agency, you buy a few rare high-tech gadgets to help with your work.

Hypertrousers: I always forget to tell people about the Hypertrousers. Compressed air actuators let you jump ridiculously far.

Gluon gloves: let you climb on any wall or ceiling. Adhesion does not actually use gluons. Gluon is a trademark of GluCorp and quantum physics is now a patent violation.

Crosslink: lets you connect any two electronic devices so that one triggers the other. Actually a cheap, widely available app for your phone, but so poorly marketed that only a handful of agents know it exists.

I want Gunpoint to have laughs, but it’s not set in a crazy world of whacky characters. People die suddenly and undeservedly, there are truly nasty people about, and justice is not always done. If you’ve seen Kiss Kiss Bang Bang, that’s the kind of tone: there are funny people in it, but they’re out of their depth in a dangerous underworld.

Every mission takes place at night. It’ll also rain a lot. The main visual motif is meant to be the warm orange glow of a lit office block in the cold blue of a city at night. I have done a pretty lousy job of capturing that.

I’m fairly easy about style, but guards shouldn’t have too much individual personality, because there’ll often be a lot of them on screen at once.

The main restriction is that people have to be between 20 and 30 pixels tall. I said before that they could go over 24 if it’s part of a whole makeover for the scale of the game, but looking into it, even a makeover wouldn’t work with a 50 pixel tall character. Here’s the problem:

It’s nice and clear, but where the hell is my jump going to land me? The character needs to be small so the jumps can be big. And I want Gunpoint to work on a typical netbook res, 1024×600, all the way up to 1920×1200. The art challenge is to make a low-res character clear and appealing.

Thanks so much to everyone who’s put effort into the awesome samples I’ve seen so far. They’re giving me ideas already, so even the ones that don’t go in will have an effect.

Let Me Mumble You Through An Early Version Of Gunpoint

The game I’m making, Gunpoint, is an infiltration game that lets you rewire its levels to mess with your enemies. It is ugly and has no animation.

I’ve learnt to do a lot of new things while making this, but art always takes me ten times as long as it should, and ends up… well, look at it. So I’d like to find someone who’s willing to help out with the visual side, particularly with animating the characters. There are only a few, it’s pretty simple.

In case anyone is interested, I thought I should talk you through what the game’s actually about so you can see if it’s something you’d want to be involved in. And for everyone else, I’d just like to give a better idea of what it does. I will probably regret this.

Here’s me, talking you through a very early prototype of the game as I play it. This is also my first stab at making a video, which is why it’s barely visible at anything less than 720p, everything’s tiny, I’m really quiet and the game sound drowns me out a few times. Enjoy!

YouTube (HD) – Direct Download (80MB .avi)

The e-mail address is pentadact@gmail.com. Let me know what you think in the comments, and fling the link around if you found it interesting. This is a lot more than I’ve shown publicly before, so I’m interested in whether it seems appealing.

The catch is I can’t pay you – I’m making this in a small portion of my free time, it’ll be free when it’s done, and my budget is zero. So I’m looking for someone who wants to help out for fun, practice and experience.

I’d love to see what you want it to look like. You don’t have to have any experience or qualifications, but if you could do a mockup of one character and their walking animation, that would be awesome. You can post it in the comments here or e-mail me.

Characters are about 24 pixels tall currently, but you can stray from that if you want to give the whole game a makeover – all the level objects and stuff.

There’s a pretty good chance no-one’s going to be up for this, in which case I’ll just do it myself once the rest of the game’s done, but it’s worth asking. I’ll still finish it, it’ll just be later and uglier.

The art that’s in there right now is a vague guide at best: I want the main character to have a long coat and a hat, but everything else is up to someone with actual ideas in their brain. The guards aren’t supposed to be grey – this guy was originally a deranged civilian but I cut that role.

To be clear, here’s what’ll ultimately need doing:

• Walking, climbing and ceiling-climbing animations for the main character.
• Walking and running animations for guards, armoured guards, and professional killers.
• Walking and running animations for some kind of civilian dude, and slight variations of him.
• A few miscellaneous combat interactions.
• A bunch of stuff I’ve forgotten.
• Optionally, any environment and character art you can improve on. Lord knows it sucks right now.

The very loose time frame is about two to three months. The game may end up taking longer than that – I’d like to have it out by the end of July, but even that’s not a hard deadline. Yay development!

How I Am Working

Gunpoint is going amazingly well. I’ve been splitting what’s left to do into little monthly task lists, and I’ve already finished everything I had down for March. I started making the game in May last year, and said I didn’t want it to take more than a year. So my aim is to release it this May. Expect it in July.

I typically only work on it about one weekend a month, and I forgot about it completely for two months last year. The two days I spent on it during the holidays shot it forwards to a really exciting point, and the feedback from testers on that version was amazing. So lately I’ve been spending about a third of my spare time on it – what we in the lazy industry call ‘crunch’. Continued

Gunpoint: The Mechanic

The game I’m making is about infiltration, but I’ve held off mentioning the way you do it until it’s actually in the game. It is now, and on Saturday night I sent it to around one hundred testers who kindly agreed to try it out. This was a little nerve wracking.

Before I go any further, if you signed up to test the latest version but haven’t played it yet, I’d really like you to play it before you read this. The reason I haven’t mentioned it before is that I wanted the first people to play it to do so fresh, to see if it makes sense without any external explanation.

It’s a tool called the Crosslink, which lets you rewire any device in the level to any other. So if there’s an electronically locked security door you want to open, you can use the Crosslink to wire a light switch to it, then press the switch to open the door.

But you don’t have to be the one who presses the switch: guards will use security hand scanners to open those doors, and hit light switches if they find themselves in the dark. So you can rewire those things to screw with them: a guard tries to turn the lights back on and finds it slams a door shut and traps him in the room. Trying to open it unlocks another door halfway across the level, letting the player into the building.

The idea is to give the player a lot of freedom to tinker with their environment and fuck with people. I wanted a system that gives you enough power that you can be creative, think of approaches that I hadn’t considered, and come up with your own way of playing. And I wanted a game where killing a guy is not the most interesting thing you can do to him.

Games that funnel you down a single path seem to be made from a perspective of, “What if the player is stupid? How can we make sure he can complete this?” I wanted to start from the question, “What if the player is smarter than me? How can I make something even he’ll enjoy?” I still want the barrier to entry to be low, but I don’t want it to double as a ceiling on the intricacy of what you can do.

The results are making me very happy. I built a crude demo record/playback function into this prototype, so testers can send me a replay of their first attempt at the game, and I can watch how they dealt with each level. My plan was to see where the stumbling blocks were, what players tried to do but couldn’t, or didn’t try but could have. But it also shows the awesome solutions they came up with.

In the last one I watched, the player seems to rewire a building all wrong. I’m scratching my head when he hits a lightswitch, which isn’t connected to anything more interesting than a light. But a guard on that floor is by another switch, which he hits.

Instead of turning the light back on, it turns off the light on the top floor, causing the guard up there to open several security doors on the way to turn it back on. When he finally presses it, instead of the light coming back on, the door slams and locks behind him. The player just shuffles up the stairs and hacks the terminal he was trying to get to, while every guard on the level is trapped in a different darkened room.

That’s not the quickest or easiest way to do that level, nor one I’d ever tried, but it’s awesome to see people come up with their own plans. Early on, I’m happy for them to do that in a sort of sandbox context: it’s not necessary but it’s fun. Later on, I want to complicate the mechanic slightly so that this kind of ingenuity is actually necessary – putting devices on incompatible circuits so you have to trick the AI into bridging the gap for you.

Before I started thinking about this stuff, Irrational Games’ Steve Gaynor posted a great analysis of what leads to emergent game experiences. His conclusion is that meaningful state change is at the heart of it.

I totally agree, but I also wanted to come up with a more comprehensive list of the elements that make a game like Deus Ex so endlessly entertaining to me. Whether you want to call it emergence or something else, I decided on the components a game needs to have that kind of excitement:

1. State change. I must be able to change the state of important elements of the game between more interesting conditions than ‘alive’ and ‘dead’.

2. Connectedness. Elements should be able to affect each other, not just me.

3. True obstacles. The most direct and simple path cannot be viable, at least not for the ideal outcome.

4. Significance. Some elements must be obviously powerful, valuable, or consequential.

I’m satisfied I’ve covered 1 and 2 in Gunpoint now. 3 is sort of in there, in that you can’t open most stuff directly, but the simplest Crosslinks are usually viable solutions right now. That will change when I make incompatible circuits. 4 is less nailed down – it might come in the form of your objectives, VIPs and the like, it might be to do with the cops or rival agents showing up, or it might just be about guns and who has them.

The nice thing about the Crosslink mechanic is that it adds a lot of value to whatever else I put in, so it’s easier to justify spending some time on a new device. I’m always open to ideas for those – I’m planning some kind of metal detector or security camera, something triggered merely by presence, and an alarm that’ll summon guards to a particular floor when triggered. Any others?

Gunpoint: Tripping Up

Okay, so neither of us have quite mastered the door technology yet.

I’ve gone back to working on the infiltration-themed platformer I’m making, Gunpoint. I’d planned to take two days out of the winter break to binge on it, but after a few interruptions I’ve decided four half-days might be more doable, and less exhausting.

The plan is to rapidly impliment the last few features it needs before the main mechanic can make sense, without slowing down to fine tune their operation or tweak the look. So far I’ve got security doors and light switches working, and I’ve almost got the AI interacting with them correctly: only guards can pass through security doors, and they’ll turn on lights if they find them off. Next it’s the main mechanic, then a few last fundamentals that may end up being important.

It’s fun to be making fast progress again. It was a huge mistake to bother putting elevators in before the rest of the basics were working, and the ridiculous time that took added to the ridiculous time AI took is the main reason I ground to a halt on the whole thing.

I now have a game that is ugly, broken and crude in every way except the lifts, which are the most magnificently smooth, reliable and satisfying vertical transportation in the history of interactive entertainment. And I’m about one month behind where I would have been if I’d stuck to stairs. It started to feel hard.

It isn’t, really, but a few things do trip me up repeatedly. I want to make a note of them here on the offchance it gets any of it through my skull, so the rest of this post will make no sense to anyone who doesn’t use Game Maker (the tool I’m making the game with).

• When you store an instance in a variable – remembering which wall I’ve just collided with, for example – don’t. Store its .id property. Sometimes, even though what you want to reference is a property of that thing, you have to pretend it’s a property of that thing’s id, even though that makes no sense. Otherwise, you get shit like light switches that toggle their own existence on and off instead of changing the light level.
• The Create event is a handy place to put any code that should be executed when the object is created. DON’T EVER FUCKING USE IT FOR THAT. Why? Because the objects in the game at start up are created in an arbitrary, unreadable, undeterminable and randomly changing order.

  You have no idea what code has already been done and what hasn’t when any given Create event is executed. So when one tiny change to something suddenly breaks everything in your entire game, including a bunch of stuff it had absolutely nothing to do with, it’s because the Creation order has changed arbitrarily.

  Only ever use Create to set initial variables, then use Alarm events to trigger actual code. That way you can set those alarms to go off in the order you specify.

• Often you want one object to ‘trigger’ an event for another object. The reason the method you just tried isn’t working is that it’s getting re-triggered repeatedly sixty times a second all the time that the conditions are fulfilled, usually reversing the effect and/or delaying alarm events indefinitely.

  The best way I’ve found to do triggers like this is to have it set an Activate property on the target object. The target object checks this Activate property every step, and the moment it’s ‘true’, it sets it to false, does its work, then tells the trigger object not to bother it again until it needs to.

• Relatedly, attach code to the object it affects, rather than the object that executes it. A button shouldn’t open a door, even if that’s the only thing it’s ever going to do. It should just say “Open!” to the door, and the door itself should contain the code for how to do that. That way, if you ever need other objects to open the door, they can just say “Open!” too and it won’t cause any conflicts or require any repeated code.

Pretty goddamn fascinating, I think you’ll agree. The truth is that most of the problems you encounter creating a game aren’t as frustrating as playing the average shooter. You don’t expect to succeed. You’re wrestling a ridiculous tangle of logical statements into something that functions as a comprehensible world, which is an insane and extraordinary thing to do – even when the results are drab, glitchy and artless. In other words, I’m enjoying it again.

By the end of this sprint I plan to at least be able to show you a video of it in action, and possibly send out a new prototype version to testers. If you’d like to try it when the next version’s ready for testing, and haven’t already mailed me about it, mention Gunpoint in a mail to pentadact@gmail.com.

Gunpoint And The Other Game

I had an idea for another game, recently. It’s an RTS that would solve a lot of my main frustrations with RTSs, with a few fairly simple mechanics. And it’s an idea that keeps spawning other, smaller ideas, and suggesting parts of itself I might like to cut out to make it even simpler and better.

It’s gamey in a way that Gunpoint isn’t, in that it’s really just a few basic systems: no context, story or even content would be necessary for it to work on a basic level. And it might actually appeal to people outside of my skull, in a way that Gunpoint probably won’t. No logic or thought went into my choice of a jumpy platformer about a private detective for my first game, it was just the first idea that interested me. The RTS feels like something worth making, and something that someone else will probably make if I don’t.

In other words, everything’s been telling me to just stop making Gunpoint, learn Unity, and switch to this newer, better, more potentially successful idea.

I’m not going to. Abandoning an old idea doesn’t solve the problem of forever having newer, better ideas. They’re always going to come faster than you can make them, and for a while, they’re always going to make your old ones seem less exciting. Whatever you do in response to that is what you’re always going to do, so if I ditch Gunpoint to make this RTS, I’d ditch the RTS to make the RPG idea I’m inevitably going to have in six week’s time.

But going back to Gunpoint is harder now. Not because it’s an unexciting idea – the thing at the heart of Gunpoint, which I haven’t really talked about yet, still gets me totally fired up. But looking at it after this gleamingly simple, efficient new idea, it looked incredibly flabby, unfocused, and most of all daunting. I just don’t know how I’m going to do half this stuff, and some of it doesn’t seem very connected to what I’ve done so far.

I’ve tried to simplify Gunpoint lots of times, but I’ve never really questioned that it was going to be story-driven. It couldn’t just be missions, it had to be punctuated with scripted sequences, major characters and predetermined developments.

But that wasn’t really a design choice. I just automatically included it because I’d already written a bunch of scenes, dialogue and characters to flesh out the world in my head. It’s instinctive to write that kind of stuff when you’re thinking up a new world, and useful too. But I should have taken an extra step back and thought, “OK, why do I need to tell these stories to the player? And how much work is it going to be?”

I don’t have any new screenshots to show you. Here are some horses.

Now that I take a more squinty-eyed look at the roadmap ahead, I start to see just how much coding each one of these things is, and how little it adds to the game as a game. Making non-interactive scenes on top of your interactive ones is like making a second game – a shitty game no-one can play. And I know from editing GTA IV movies that I’m an obsessively redactive director: I’d never quite be happy with the way they played out.

So I’m scrapping all the non-interactive stuff. There’ll still be story context for each mission, but it’ll be the text of the briefing you choose from some kind of job listings site, and text message conversations with the client.

Oddly, since restricting myself to this for practical reasons, I’ve found it also makes more story sense: you’re a private agent specialising in illegal activities, so you probably would get your jobs from an anonymous site rather than walk-in clients, and communicate by text rather than in person.

It was an easy choice to make – I don’t have to delete anything, because the stuff I’m scrapping is stuff I haven’t made yet. I probably would have given up on a lot of it when I did come to build it. But what the other game has helped me do is clear it out now, while I’m working on the cool stuff. I had to make Gunpoint a more appealing thing to work on, and that meant cutting reams of big wibbly translucent flab until I could see the route to completing it. It clears the head, brings the game into focus, and makes it feel achievable.

Shrug.

I’m always asking developers what they’ve learned from previous games, and sometimes they draw a blank. So I might start ending my Gunpoint diaries with a summary of what I’ve finally figured out.

Writers shouldn’t write games. Designers should give them a little box to write in, and they should write in that. I left my writer hat on way too long after coming up with a vague idea for the world of Gunpoint, and started writing the actual game. “This happens, then this happens, then you get this item-” Shut up! Games aren’t just first person movies, Tom. Design a thing that is fun, then write whatever story context that design needs.

‘Hard to do’ and ‘easy to do’ are irrelevant, ‘good value’ and ‘bad value’ are what matters. I say the story stuff was going to be hard to implement – it wouldn’t be, really. Not as hard as the central mechanic I’ve yet to start on. The difference is, if the central mechanic works, it’ll lead to dozens or even hundreds of fun interactions for each player. The story stuff would be fun a maximum of one time per player, likely not even that. It’s phenomenally bad value. If you’re Valve, and there’s some reason you really want to push this stuff, you can afford that. But if you’re one guy with no experience making games, you can’t.

Unrelatedly: Machine of Death day is in about eight hours. I’ve put together a post about how you can get it, what the postage will cost, and what other forms it’s going to be available in. That’ll go up once it’s officially MOD-Day.

Gunpoint: AI

On some level, my game is going to be about fucking with people. When you get down to it, the reason I like Deus Ex isn’t because I have the choice of using a multitool or shooting a guy. It’s that I can trick the guy into doing what I want. If I don’t have the key to a door with a guard on the other side, I can just shoot a wall, and he’ll unlock it for me when he comes to investigate the noise.

People coming to investigate, in fact, seems to be the core rule in the most enjoyable deceptive play – whether it’s in Deus Ex, Thief or Hitman. So that was my one requirement for Gunpoint AI: you must be able to knowingly misdirect the AI. The fact that investigating suspicious noises is also semi convincing, semi effective behaviour for a guard is just a nice bonus.

I had a feeling this would be hard, and I knew it was probably a little too involved for a first project. But I was looking forward to trying, because AI is one of those nice juicy problems that’s too big to tackle. You have to break it down, and breaking things down in ways that make sense is one of my favourite things to do. I took philosophy and maths at university, so it’s about the only common thread in my voluntary education.

I wanted guards in office blocks to head to the source of suspicious noises, like gunshots or glass breaking, even if they weren’t on the same floor. It sounds dangerously like pathfinding, a famously sticky area, but I didn’t think it would come to anything like that. I can just break it down into a) how do I get to somewhere on my floor? and b) am I going to the sound itself or the stairs?

What I’m learning, increasingly, is that conceptual stuff is not the hard bit. Every high-level idea you have for how to translate a design concept into chunks of algorithmic code will probably work, and in fact is pretty easy to write. The hard part is a part I didn’t even realise was a part: order.

“I wanted guards in office blocks to head to the source of suspicious noises” – really? Did I want dead guards to respond to suspicious noises? Did I want guards to walk right past the player himself on his way back from breaking a window, in order to investigate the breaking of the window? Did I want guards who are being blown out of a window by the force of an explosion to stop, mid-air, and tell the others: “Oh hey, I’m closest to that broken window I was just flung through, I’ll go check out what caused it”? Did I want the guard who just shot you to run to your dead body and try to solve your murder?

Actually I kind of do, but that’s probably another game.

It’s easy to code what you want. But you don’t really know what you want until you’ve tried to explain it to a very, very stupid person. That was Socrates’ thing, in fact: he acted like an idiot to make people explain themselves to him on the most basic level, which usually revealed they didn’t truly understand their own beliefs. These days we have silicon hyperidiots to explain things to. They’re able to be much more stupid, many more times a second, than Socrates ever was. Coding is the Socratic method as an extreme sport.

Because the concept behind my AI system was simple, scripting it was getting increasingly complex. Every time I said something like, “Set this guard’s state to ‘alert’,” I had to first check that he wasn’t dead, or stuck, or in a lift, or being punched. And it wasn’t going to get any less fiddly: every time I added a new situation, I’d had to go back and add new exceptions to every line of code it could influence.

The only way I could make it simpler to code was to make it more complex to think about. It turns out that the nitty gritty of how an idea works in practice is a much more unwieldy beast than the high concept of what you want it to achieve, and it’s the former you really need to simplify.

So now I have an intricate system of connected timers, tracking five or so independent properties of the AI’s mental and physical state, and it’s a mess to think about. But in code, it’s remarkably straightforward. I’ve turned every sub-problem into a separate function with a human-readable name, replacing stuff like:

if ((sprite_index=sGunman && oPlayer.x > x) or (sprite_index=sGunmanLeft && x > oPlayer.x))

With: if HesInFrontOfUs

The top level code is now just this – the pink things are functions I’ve written that call in other chunks of code:

And after a lot of tinkering, and a few maddening variable-definition errors I never really got to the bottom of, it actually works. You can lure guards from their posts, hide the other side of the stairs and jump them when they come out. Or you can make a noise on one floor, then travel to another while the guard there runs to the one you just left. It’ll get more interesting once you have more of a toolset: right now all you can do in Gunpoint is jump on people and whale on them. But it’s already actual fun to screw with the AI, so I’m pretty excited about what I can do with it from here.

By the way, Spelunky creator Derek Yu put up a great guide about what stops people finishing games, and how to avoid it. Since he inspired me to start this, it’s nice of him to also inspire me to try and finish it.

Lastly, I need opinions: man-sized air vents are a cliche. But are they an annoying one, or just a tool that ultimately makes a game more fun? In some ways they’d fit with Gunpoint’s movement system, since they wouldn’t have to be floor-level for you to get to them. But I don’t know how sigh-worthy people find them these days.

Gunpoint: Making The Jump

What? He’s reading a health and safety poster.

I had a chance to work on my game in my week off, the one I was going to call Private Dick. That name is increasingly pissing me off, so I’m calling it Gunpoint for now. How relevant that title becomes will depend a bit on how much fun it really is to be at gunpoint, or have other people there, and what kind of options I can reasonably code for those situations. Currently everyone with a gun shoots you in the face the instant they see you, and there’s a certain comforting reliability in that.

I’m almost at Milestone 2 – they’re really yard stones, these things, because I can’t have spent much more than ten hours on this thing since Milestone 1. Here’s the plan:

Milestone 1: movement fully working, however horrible it looks and shitty it feels.
Milestone 2: one hostile who shoots on sight, and can be pounced on and beaten unconscious.
Milestone 3: two devices that are interactible. I’ll talk about devices once I’ve got them working.
Milestone 4: one fully working level that’s fun.
Milestone 5: a dialogue system why not?
Milestone 6: narrative reduces grown men to hopeless fits of sobbing.
Milestone 7: the Citizen Kane of games.

So I’m not really thinking clearly more than two or three milestones ahead – my plans change too much with each one for that to be worthwhile, and anyway it’s kind of daunting.

About ten of the people who signed up to test my game played Milestone 1 and told me what they thought of it. This was awesome. Not least because most thought it was a lot less horrible-looking and shitty-feeling than I was expecting.

It’s also a really exciting and eye-opening thing to have people interact with something you created, and have reactions you didn’t expect. People overwhelmingly wanted a certain move added that I’d intentionally left out. And they were right: I’ve added it now and it profoundly improves the feel of the game.

That milestone was all about the jump: the tiny freelance agent you play can leap preposterous distances in any direction, and cling to anything he hits. This milestone, number 2, is about using that jump to pounce on angry gunmen while they’re not looking, then punching them in the face while you have them pinned to the ground.

That part took minutes, really, and is immediately and profoundly enjoyable. I hadn’t really thought about it before I coded it, but there’s no reason to force the player to let the gunman go after he’s hit him in the face once. I just made the mouse click smack him in the face, then return to the about-to-smack-him-in-the-face pose. You can jump off if you like, but in a survey of playtesters called me, 100% felt the need to beat him again and again and again, sometimes tapping out semi-musical rhythms with their facebeatings.

What was trickier was making the jump good enough that you could bet your life on it. One of the biggest complaints from the first test, even without any threats, was that people had trouble judging where their jump would go. I hadn’t even put a charge-meter in, and the strength of your jump increased quadratically as you held the button. A player’s instinctive grasp of basic movement mechanics doesn’t necessarily model quadratics effectively.

This was not a surprise. I knew what I wanted, ideally: a visual projection of the exact arc your jump will take. But like most of my plans, I had a few much easier back ups that wouldn’t work as well. Any kind of charge meter, I thought, would probably do.

The reason I’ve only spent ten hours working on this since the last milestone 5 weeks ago is not actually free time. It’s guts. Doing everything yourself is sometimes daunting.

The fun stuff: design, requires some less fun and harder stuff: coding. And the still quite fun stuff: coding, requires some much less fun, much harder and miserably unsatisfying stuff: art. When I’m not working on my game, it’s because I’m exhausted or distracted or just not in the mood to take on something that may, at any time, kick my ass.

What I’ve learnt from the whole process is this: guts. I’m not accustomed to putting time and effort into something and having it turn out shit, but I’ve found that when I actually get down and do it, it doesn’t take that much time and effort and not everyone thinks it’s shit. Just do it. Accept that not everything you do is going to be met with a steady stream of praise, venture outside your comfort zone and grow up.

That’s true enough for art, but it’s particularly true for coding. Predicting the arc of a player’s jump meant simulating the engine’s own internal vector analysis precisely, so that I could do all the calculations involved with it in a single frame. In other words, the game would have to play the jump out in its head thirty times a second, exactly the same way it would happen at normal speed. It seemed like it would involve an awful lot of trigonometry, which is tricky to code and tricky to compute. Having the game do it thirty times a second seemed like it would destroy performance.

Long story short, it was easy. If you’re smart about it, no sines, cosines or tangents are needed, just basic multiplications. It’s high school mathematics to model a rigid body under acceleration and derive a generalised formula for its position. And once you’ve got that, you just plug increasing values of time into it and create a dot at that position until you hit something. There are ways to make it more precise and reliable, but it already works so well that it’s completely changed the way I play.

I still don’t have a charge meter – I changed the system so that if you want to go further, you just click further away. It means you can make small, precise jumps without time pressure, and great long arcing ones without delay. And it feels great to leap six stories, through a window, and into the back of someone’s head. Then punch them to the beat of Seven Nation Army.

I whined a while ago about wanting to get to the point where the question is “Is this fun?” rather than “Why doesn’t this fucking, fucking work?” I’m there now, and from here until I’m done with the game or give up on it, there’ll always be “Is this fun?” questions to answer. There’ll still be many more things that don’t fucking, fucking work, but I’m tantalisingly close to having most of the building blocks to make real levels out of. Once I’m there, it gets really interesting.

Edit: just as I finish this, Sophie Houlden posts the text of her talk at World of Love, and it’s basically telling me to realise what I just realised.

Edit 2: Once I’ve tweaked it a bit, I could use some more testers to help me figure out if this iteration is fun yet. Any more volunteers? Mail me if so.

Edit 3: Now with animated gif.

Art Failure

I put it off for as long as I could, but after a quick prototype for Solo Trenchcoat Triathalon proved inconclusive, I had to put a second character in my game. This meant picking an art style, which was a problem for two reasons. For one, games aren’t art, and I know from contacts in the industry that professional game artists devote a good few hours of every working day to wrestling with this contradiction. And for another, the only acceptable sprite I’d drawn so far – protagonist Mr Conway – has his proportions and body shape completely concealed by an oversized, nebulous trenchcoat.

I am not an art guy. I feel visually dyslexic when I try to draw: I know the right shape when I see it, but I can’t visualise which pixel I need to change to make this deformed mess become that – even when it really is just one pixel. So I really struggle to depict what’s supposed to be going on under that trenchcoat. I have drawn Conway’s head big, monstrously big, a hangover from when he was to be a horrible space robot ineptly disguised as a human. Are his limbs similarly bloated? Can I really draw a head of that size without disguising it beneath a stylish hat? Can I balance a head of that size on a human body? Can I just set my game in a world where it’s considered indecent not to wear a trenchcoat?

All these things are problems because they resulted in this:

An armless, morose John Hodgman who just looks fat, awkward and wrong. Despite general murmurings of support on Twitter for the idea of a nightmarish Being John Hodgman world, I could see this wasn’t going to get good any time soon, so went in a completely different direction:

This would be a complete rethink, requiring a new treatment of the main character (not this douche), and a much more realistically-proportioned look. It might seem like more work, but stuff like this can be done pretty easily from photo reference. In fact, the fewer pixels you have to work with, the more artistry it takes to evoke something with them.

The trouble was Conway. Just as it was hard to extract a convincing human from the murky depths of his coat, it was almost impossible to drape the murky depths of his coat on a convincing human. Several takes ended up looking like Rincewind. And losing the outlines seemed to make every camel hue I picked for him look more and more like some kind of awful beige velour. I got as far as this before declaring it hopeless:

Doing a realistic-shaped guy from photo reference confirmed something I never realised about game art before I tried to butcher some myself: proportions, shape, size, colour, detail and expression are almost completely irrelevant. The thing that defines the feel of a character is pose. That’s why I haven’t been able to get rid of that lame original Conway sprite: everything about it is feeble and misjudged except the fact that he has his hands in his pockets.

Even that was a mistake: I just hadn’t got round to drawing his hands yet. But as soon as I saw it that way, it looked like the character I had in mind. Hodgman failed not because he looked like Hodgman – Hodgman is great – but because he was standing like a mannequin. I eventually solved my art style problem by realising art style doesn’t matter: the most basic possible shape would work fine so long as I could pose the limbs. So I just copy and pasted the original Conway, trimmed him a bit, and I had his first friend:

The relationship lasted as long as it took me to remember that the first character is meant to be an incensed gunman trying to kill you.

One or two people have very kindly offered to lend me their artistic talents. This is appreciated and noted, because if this gets anywhere I will almost certainly ask someone who knows what they’re doing to pretty it up. The reason I’m putting some effort into coming up with the basics myself is not because I expect them to endure, but because I need to decide on a tone. If I’d stuck with those slender realistic characters, the ludicrous super-jumping I’ve got right now might have needed rethinking. Now I know the game is allowed to be a little more cartoony, clean and simple.

Obviously now that there’s more than one person in the game, I’m thinking more specifically about combat. All my ideas for stuff like this have different modules: there’s a basic version I’m definitely going to try, then progressively fancier systems I could stack on top of it if it turns out to be interesting and fun.

That goes for the game itself, too: level 1 doesn’t need a combat system, level 2 doesn’t need a hacking system, level 3 doesn’t need a dialogue system, and none of the adapting plot stuff is relevant till after that. If one thing turns out to be cool enough to focus the game on, I’ll scrap whatever I haven’t made yet. That’s why I’m not worrying too much about the warnings about biting off more than I can chew: I haven’t bitten anything off yet, I’m just scoping it out.

The last thing I did was code the new guy to shoot you dead on sight, and already I’m liking him.

Collision

I’m only making a very basic game, and with a program that provides the base engine for you. But even so, that means hand-coding some pretty fundamental stuff, and it’s taught me that you can’t use the word ‘basic’ to describe anything you haven’t tried to code yet. I like to do stuff like The Hardest Logic Puzzle Ever in my spare time with a Google Docs spreadsheet (and xkcd’s The Hardest Logic Puzzle In The World in a text doc), but implimenting the most basic laws of game worlds is on a whole other level of complexity.

This bit of game logic, for instance:

Is impossible. I don’t mean hard, it’s just not the way algorithms work. You have to pretend it is, though, and the intricacies of that are what’s taken up most of my time.

The issue is that time progresses in discrete chunks in games, so just the word ‘when’ is problematic. Real life doesn’t really care if it’s not at exactly 1 second or 2 seconds that a man walks into a door, he just stops when he hits it. Code isn’t smooth, it has to re-examine and re-create the whole world sixty times a second, and there’s nothing in between these frames. Unless you want everything to move very slowly, some things are going to have to move more than one pixel at a time. That permits a nasty possibility: after 1 frame you haven’t hit anything, and after 2 you’ve already gone through it.

So collision logic fudges it one of two ways: the game either waits until you’ve already gone through something and pops you back out, or it looks ahead to see if you’re going to hit something and pretends you already have. The effect can be seemingly perfect, since these precautions are computed before the result is drawn on-screen, but it makes the underlying logic fiddlier than it ought to be.

Generally, though, it’s all fine so long as your character is a solid unchanging block.

Old-school platformer protagonists versus actual human proportions. Chick proportions not pictured.

That’s why a lot of 2D games have very compact, boxy characters: the game can treat them as a simple rectangle regardless of what animation they’re playing. Real people change shape much more dramatically when they run, jump and hit things. If you want a human-like character to dive headfirst into a wall – and I do! – you have to solve this insoluable problem for a thing that keeps instantaneously and dramatically changing size and shape.

I won’t get into why this is even more complicated, difficult and annoying than it sounds, but suffice it to say that the next time I fall through the ground in the latest FPS and plummet into the infinite grey limbo below, I won’t be thinking “Why can’t these idiots fix shit like this?”

I will be thinking “Why don’t these idiots account for shit like this?” though, because it only took me a few days of tinkering to realise a fundamental law of coding.

So early on, when I had so many collision bugs to fix that it seemed daunting, I spent some time on an “Oh fuck, I’m stuck” subroutine. It’s a little spiralling algorithm that searches with increasing desperation for a nearby space to teleport you to, should you somehow get stuck in solid matter. I know I’ll never solve all the minor or rare collision glitches that could happen, so I feel I should at least try to make sure they don’t break the game when they do.

Getting collision logic stable and robust was the hardest thing I’ve had to do so far, and the most intricate stuff I have planned for the game now seems trivial by comparison. I’m looking forward to the point when I’ve done enough of the coding that the question becomes “Is this fun?” rather than “Why doesn’t this fucking, fucking, fucking work?”

Private Dick

I’m making a game! I will probably never finish it! But I thought I’d start talking about it anyway, to keep my goals straight and get feedback on my ideas as I go.

I’m doing it because Spelunky, one of my favourite games ever, was made by one guy in a program called Game Maker. Obviously it doesn’t follow that “If design/coding/art genius Derek Yu can do it, I can too!” But it does make you realise that game-making programs aren’t just for shitty test games. Since that was pretty much my last remaining excuse for not doing this thing I’ve had a constant urge to do most of my adult life, I started doing it.

My game is about a little dude in a trenchcoat who sorts out – or completely screws up – delicate problems like hostage situations, with a few pseudo-science special abilities. He’s sort of a drunk, asshole Inspector Gadget – hence the working title, Private Dick.

I wanted to see if, with little time, less talent and no experience, I could make a game that would achieve some of the things I’ve always wanted from the games I play. I want a game where:

A gun going off is a big deal. Existing games tend to be divided into ones where guns go off constantly, and ones where guns don’t exist. The latter don’t have enough guns for my tastes, and in the former guns become meaningless. You shot a man in Reno? I shot 384 men 7 times each in Vegas, and I still didn’t complete that game. The reason guns are an exciting element in a thriller is that they can enact sudden, massive, shocking, permanent change. I want to see them play that role in a game.

Failure isn’t terminal. In most games, you do what you’re supposed to or you die and retry. Even if you don’t physically die, failure means a restart. I want a game where life goes on if you fail the mission, and most of the ways you can fail don’t kill you. The story adapts to the outcome of your missions, and death is a rare, shocking, worst-case scenario. I don’t want anyone to have to repeat anything unless it makes no sense to continue. Edit: More on this in the comments.

You can change things in non-destructive ways. You can change them in destructive ones too, but that comes as standard in gaming. I don’t know if I can make anything you could meaningfully call emergent with my resources, but I want to make a game whose levels you can tinker with, reconfigure to your liking, and see those reconfigurations interact with each other – not just with you.

Movement is superhuman, but constrained by physics. I need it to be superhuman because I want getting around to be quick and satisfying, but I want it to be physically coherent. Most games don’t do this: almost all platformers let you move your guy around while he’s in the air, by some unexplained force. I’m not going to do anything fancy with physics in my game, and it’s not going to be primarily about movement the way platformers are, but I want the movement to make physical sense. Anything that doesn’t isn’t convincing to me, and that hurts a game’s feel.

It’s this last thing I’ve been working on so far, a few evenings a week. I’ve nearly got it FYS – Functional, Yet Shit. This is my standard for implimenting a mechanic before moving on – there’s no sense fine tuning or fully animating until I know how it fits in with everything else. Getting movement to that point will put me about 10% of the way to a playable level that includes all the main elements I want in this game. I’ll be surprised if it takes less than six months, sad if it takes more than a year, and amazed if I stick with it that long.

Writing about it here is one way I’m trying to improve its chances of reaching a playable stage. Explaining it to someone else forces me to keep my thinking clear, explaining it to you guys might be a good way to get feedback, and explaining it publicly makes giving up all the more embarrassing. So far I haven’t told you much, but if you’ve ever worked on a game I’d love to hear any general advice.

I’m already ignoring the golden rule: focus on one thing and do it well. I don’t know what I can do well yet, or what’s worth doing well, so I’m roughing out everything that might work and I’ll focus from there.

My plan is to talk more about what I’ve done so far than my future plans, so I’ll write about movement once it’s FYS.