George Buckenham

Some people have asked me for advice on how to get started making videogames, usually in the context of the gamejam I'm organizing. (which makes me so happy -- one of the main reasons I'm organizing them is to get people who haven't made games making games). This is my opinion and not gospel, so if you find something else works better for you, do that instead! You should also check out youcanmakevideogames.com, as it's a fantastic resource, and more comprehensive than this blog post. And also the big list of game making resources.

The first thing to say is that game design is entirely beyond the scope of this post. There are good places you can go to learn that (you could do worse than reading these), but what works best is trying things and seeing if they work. The next best thing is playing games and seeing how they work. It's a wonderful, endless, frustrating journey. But to start on it, you need to be able to make games.

Secondly, videogames are a tiny part of games. If you want to make games, you should definitely at least consider not making videogames. It's by no means less valid to make a boardgame, or to write the rules for a game that people play without any bits at all. It's even a good way to test out videogame ideas. You've still made games, I think games are wonderful and more people should make them, so we all win. 

But if you want to make videogames, then okay. I completely understand - I do too. Let's talk about that. The best way to start is to make small games. Make a small game, and finish it, and then make another. Start with a tiny scope, the smallest thing you can think of that will still be a game. 

Similarly, try to minimize the amount of stuff you have to learn, unless your aim is to learn stuff. Don't write your own engine, if you haven't before. Focus on the game part. Don't know how to use Photoshop? Use Paint instead. Can't compose music? Me neither - use other people's music, or make silly noises into a microphone. Don't be afraid of constraints, and of scaling your design to fit your time and knowledge - it's often to the benefit of your design.

Which isn't to say you should be afraid of having to do something new if it's necessary. Dive into it with confidence. Some stuff can be surprisingly doable, if you don't let it see your fear.

Shall we get a bit more practical now?

What tools would I recommend you use?

If you know a tool (if you are a programmer normally, for instance) then that is the best place to start. Minimize what you have to learn, and all that. So if you're a Java dev, look at Java libraries. If you can do web design well, you can make games in web pages, or if you're ace at JS, try out making a canvas thing. If you can draw, make that the focus of your games. Even if your skill is crosstitch, you can use that (if your skill is crossstitch, please make that the focus of your game, I would love to play a game with the graphics done in crosstitch).

But if not, then here's what I'd recommend for programming your game:

If you have programming experience, and want to do something 3D: Unity3D. 

It's quick to get something working, it's powerful enough that I'm employed to use it all day, and it's simple and modular enough that you don't have to read all the (really quite decent) documentation before anything will work. You script in .Net, in C#, or in something that looks like Javascript but isn't, or in something that looks like Python but isn't. It can export to a web player that you can embed on any web page. The free version will suffice for the purpose of making a game, but you'll have to pay for luxuries like it running on an iPhone or getting to do heavy hacking on the engine itself. The downside is that it's a 3D engine and you'll have to either stick to primitive shapes or model and rig and UV unwrap and texture and animate your characters. You can use it for 2D stuff, but it's a hack you'll have to perpetrate yourself.

If you have programming experience, and want to do something 2D: Flash/AS3. 

People keep claiming it's dead, but it isn't. Not for games. AS3 is a decent Java-ey language, that's pleasant to work in. And the Flash plugin is installed in every web browser, and AIR lets you hit mobiles, and make standalone apps. My advice would be to get FlashDevelop (free!), download FlashPunk or Flixel, and work through the documentation. It'll get the basics of 2D games running, and you'll pick up Actionscript as you go. Alternatively, if you want to just write stuff in the browser, wonder.fl is a strange kind of magic.

If you don't have programming experience, but can write and/or draw: Ren'py

I've never actually used this! I am writing out of ignorance! But I've heard it's pretty close to writing normally, and having a (text-heavy) game result. It's designed to make visual novels, for examples of which I am obliged to refer you to Christine Love. The underlying language is Python, which is the programming language I would recommend to people who would like to be able to program. If your game fits it's constraints, then it seems like the best thing. I plan to use this this weekend, and will report back.

If you like the web, and choose your own adventure books: Twine

I have also not used this. I am not the best person to be writing this blog post. But I want to use it! It looks simple to use, comprehensible, and it spits out webpages as a result. Accessibility : win.

If you can't program, you hate writing, and you have patience : Stencyl

I have used this, and I hated using it. But that's because I can program, so I found having to not program frustrating. If you can't program, you may also find it frustrating to use, as the concepts underlying using it are the same as needed for real programming. But you'll be less lost in a sea of syntax errors, incomprehensible jargon, and vast libraries of functionality you don't understand. The setup is less onerous, and it outputs to Flash.

I should also give a shoutout to Oh My Game here, as it looks like it might be similar, but better. But despite being developed by a friend of mine (hello Erlend!) I still haven't tried it out. So this is a cautious nod.

There are lots of other tools out there. If you have one I should add to this list, let me know, and I'll add it.

As I said above, this is pretty programming centric. This is because I am basically a programmer. There's a nice index of how to produce other resources on youcanmakevideogames.com.

Other bits of advice:

Lots of people have source online for their games in any of these languages. Increpare has source for lots of Flash and Unity3D games, right next to the download links. Anna Anthropy has all her Twine sources up. Wonder.fl shows you everyone's source, right next to the player. Stencyl will show you the generated AS3 code for any game you make in it. Most Ren'py games I've downloaded seem to have the source embedded in them (Don't take it personally, babe, it just ain't your story does, I noticed). If you want to see the source to a famous Flash game, Canabalt is open source. An obligatory reminder: just because it's available to look at doesn't mean you can just copy-paste wholesale. This stuff is variously licensed, check first. But it's all good to learn from.

If you want to make something good, it's better to be consistent than to be ambitious. If you can't draw, lay things out nicely and pick good colours, and you'll get away with it (if you design it well). If you can't program, limit the complexity of the interactions that can happen. If you can't write, write as little as you can.

And if you get stuck, ask for help. Specifically, you can bug me. Or, there's excellent communities - on tigsource, on Super Friendship Club, on Way of the Pixel, on IRC, on Twitter and just generally the Internet. Most people will happily help someone who wants to learn something (but not someone who wants their homework done). And, even more marvellous is meeting other game creators in person at things like London Indies. Or, indeed, at gamejams.

Right! That's your lot. Now go and make videogames! All it requires is lots of hard work!

There's a lot of arguing about story in games recently. There was this, then this, and then this. Each one kicks up a bit of argument, and then later someone come back with another tack. So here's me, butting in.

So as I see it, there are two basic ways stories and games can happen together.

• Games can be used to tell stories.
• You can tell stories about games.

The two can happen at the same time, and they can be blended, so it's not always easy to tell them apart, but they're clearly not the same thing. This isn't going to be a exhaustive study of either one, because either could be a lifetimes work.

I find holding in my head that these are two separate things clears up a lot of discussions on stories in games. So often people argue against one, and for another, or use examples of one to support a claim for the necessity of the other. But they're different things!

So now let's muddy the waters, and try to find the limits of each. This is necessarily a brief overview, as each would offer many lifetimes of study.

It's easy to think of clear-cut examples of either one. The froth generated by LARPing[1], that's a story about a game, that's when meaning is imposed onto a possibly incoherent experience. If I was running a LARP, one of my big criteria for success would be whether the LARP generated stories worth telling. For a videogame perspective -- I've spent many happy hours reading stories generated by Dwarf Fortress and I've never played the game. Or epic tales from Eve of galaxy-spanning deceit and betrayal. What these obvious examples have in common is the wide degree of player agency. And the uncertain outcomes. Bow, Nigger[2] is a wonderful story told of a game -- it happened in a space with more tightly constrained agency, but the captivating part was the part that was entirely human, was the part that coincided exactly with the the player's freedom. But I don't think a open, unscripted world is necessary to produce stories -- although it does make the ones that get told more worth listening to. If people can happily recount the plot of soap operas, then a scripted game can produce stories for telling (or retelling, I guess). And similarly a game of Tetris can be told as a story, but it's gonna be a terrible story. The point of that game lies elsewhere (although I do have a theory about similarities between narrative structure and pacing -- but now is not the time). The crucial point here is it's a shit story if it's telling you stuff you could hear elsewhere, or in this case, is the same one you'd tell if you played the game too. Or is just a rubbish story.

It's also worth noticing that the story comes afterwards. That's a process that occurs when reflecting on the game, integrating your experiences into a coherent narrative. I assume this is because the human brain is really good at remembering and reasoning about stories, particularly ones about the actions of things having human-like agency. But I was a Cognitive Scientist slightly too long ago to link to anything interesting on the topic, or indeed speak with authority on it. Running with the supposition does imply that if you're wanting to make people learn something from a game, giving them a story to tell afterwards with the lesson embedded in it is probably a good way to go about it. And it's furthermore worth noting that you don't actually have to tell a story to someone else for it to be a story -- you just have to have assembled it and made sense of it. The Oppenheimer quote "the best way to learn is to teach" comes to mind, as does the way writing this post has sharpened and cleared my thoughts on this very topic.

Similarly, it's pretty well established that you can tell stories in games. You can have a single plotline one merely advances through in an unbroken line. You can have branching choices. You can have choices made earlier having subtle consequences throughout the entire game. You can do far more interesting things, in hugely emotionally affecting ways. It's a noble goal to tell a story -- as I said above, it's the basic way humans make sense of the world, so it's strong stuff. Ultimately, though, these stories don't come from the player's agency. It's something done to them, not what they do. Of course, they have to be involved, or it's not a game. But for a game creator to be telling a story, it has to be their story, or possible stories, not one that the player has created.

For example:

"At heart, pulling off a tragedy in a game is about manipulating the player into accepting a situation they don’t want while still making them feel responsible for it. This is no small feat, but it’s not impossible by any means. None of the examples I listed are really immune to the basic “reload and fix it” issue that threatens to rob game tragedy of its impact, but they all suggest methods for making that solution less desirable."

 -- Line Hollis talking about tragedies in videogame stories

Here, she's directly saying : to create a feeling of tragedy, we need to trick someone into thinking they have agency, when they don't. And the biggest problem we have is that they can always take the nuclear option and metagame their way back into having agency. And if they have agency, why would they submit to your tragedy? [3]

Sidenote: Can you tell a story that is entirely generative? Sorry, that question is nonsensical. Can a story be told that is entirely generative? I think I'm obliged by my belief in strong AI to say yes. For a story to be told somebody has to be telling it -- if that person is actually a computer, does it count as a story? Only if the computer can impute meaning to it's (sorry, their -- I think this is a criteria for personhood) words. Else it only becomes story when it reaches the players head. Am I making up this condition, that only people can tell stories? I'm aware this is a silly distinction -- but it's by reaching for the stupid scenarios that we can see the real limits of things. If you made a game that made me believe a computer was telling me a story it had invented, I would be more impressed by your accomplishment than wanting to quibble with your terms.

 

---

 

None of this is original thought from me, of course. Here's an excerpt from a recent Electron Dance interview with Richard Hofmeier, creator of Cart Life.

Electron Dance: "I see lots of discussions online about people who believe games should be all about rules, right, rather than narrative"

Richard Hofmeier: "It's troubling to me, right, when I was making my failed attamept at games journalism. I said, in not only the Drawf Fortress peiece, but also something I wrote about Snakes of Avalon (which is another Adventure Games Studio piece) is that the only reason to play any game is it's story. And I guess I meant that, and I still feel that way, I do. And I think it's either the deliberate intentional narrative of the developers, or, in the case of something best represented by Drawf Fortress, or Spelunkey even, something more emergent. I think that as a player, we can't engage with either system without creating a narrative for our own enjoyment of it. So we create a story from a Dwarf Fortress playthrough. And for me that's -- Tarn Adams calls them the "After Action Reports" -- but these epic tales of histories of populations and the -- it's fantastic. And they're entirely in the head of the person playing the game. And it says more about the games player than it does, I think, about how well made that game is. Maybe it's easier for me to say that after having spoken with him about it, and his kind of disinterest in posing his own visions on a player, and really it's just a tool for soliciting imaginative work from the people playing -- it's really interesting for me that he does that, but it doesn't change my mind about the only reason to play it is for the story and so whether it's game, or Cart Life, or Dwarf Fortress or Spelunkey, I think that narrative is the only game mechanic. That might not go for something like Tetris, or maybe Sim City, or something -- those toys. I tkind of deteriorates with that dynamic - it's just a semantic problem that we call them all games, when of course some are games, and some are toys, and some are more like movies. I guess in a perfect world we'd have a term for thme -- I don't want to be childish about it, but for me the semantic problem is hugely consequential, and if we had a term for -- I guess it's all interactive fiction really, and that would be one host, one hemisphere, anfd then maybe games could be more precisely used, that term. Interactive fiction is too many syllables, it's very pretentious and academic, we don't have a good word for it, like "movies" is a great word which is fun to say, and it describes a uniting characterist of a whole spectrum of propositions, and they're all united in that they're moving pictures, and games are just interactive - they're not games, they're just interactive, and that goes for board games and card games and videogames is just awful, just a really blunt instrument of language to use to describe shit that has no buisness being called a videogame, you know what I mean?"

[1] Please can we not argue about whether LARPing is a game or not?

[2] I'm aware I'm about a decade too late to make this criticism, but a problem with New Games Journalism is that it privileged games that make for cool stories, rather than games that tell cool stories. Thus Kieron Gillen, lover of Deus Ex and hater of Zelda. You could have the most fantastic time with a game, but if it makes for a shit story...

[3] I'm echoing Pippin Barr here. ie -- some players will choose tragedy, given agency. So let them have agency.

This morning, I was in the shower, and I realized to my delight that I'd made a game which involves splitting your attention to multiple different places. It's called A Bastard, and you should probably go play it a little to see how it works before moving on with this post (although it's a two player game, so go find a friend).

(You shoot automatically after each movement, the controls remap each time you press them, and the winner is the player who shoots the other player first)

There are at least three places you'll want to put your attention for play -- the 3D view, which shows whether there are barriers in front of you, the current controls for your dude, and the keyboard (to find the keys). Normally the keyboard wouldn't be a source of attention, as you know where the keys are, but when you're suddenly sharing a keyboard, then you can't let your fingers rest in the normal positions. So you need to pay attention there, and suddenly go hunt and peck again. In your head you need to keep track of what key you're about to press - it's a sensible thing to do to say it out loud as you play - "Y!", "SEVEN!", "O OR ZERO!" (I should change the font). This just puts it more easily in the phonological loop of memory, since there's a new key to recall approximately every 0.7 seconds. And then there are extra optional places to put attention -- the minimap, if your enemy isn't immediately in sight, or you just want an overview of the battle. But that doesn't show blockers, so you can't just focus there and ignore the 3D view. And then there's your opponent's 3D view, which can sometimes tell you if they've just fired, which could save you in tense spots. And then the keys they're shouting out -- it would be totally possible to pay attention to those and see what they're about to do, if you were superhuman. And of course, you need to pay attention to them shoving you, to getting their fingers out of the way of yours to press a button, to the fact that they're trying to press your button and make you lose.

So yeah, lots of places to put attention. But all of the locations you need to focus on you can attend to serially, which is what makes it a fun process rather than a terrible one. 

For contrast, take a terrible game I made, SPHERES. You've got to dodge the cubes and shoot the spheres. But when you're shooting, you're not attending to the cubes, and then one come out and whomps you and it feels unfair. Or you focus on dodging the cubes, and ignore the spheres -- and now you get a terrible score, and would be having more fun playing CUBES again. There's no easy way to attend to all the things serially, and it feels really bad.

(In CUBES you only have to attend to one thing, containing multiple things -- the optic flow of the cubes is enough for you to track their positions and velocities. Your focus is always on the center of the screen, more or less -- which is why the timer is there.)

To serially attend, you need to know where next to put your attention at all times (or most of the time). That moment of "the fuck should I be looking?" -- it's powerful confusion, and should be used very sparingly, if at all. In A Bastard, you attend : view of battle, keys bindings, keyboard, repeat, with interruptions from your opponent's elbows. Get the rhythm down to below .7 seconds, and you're killing it. In the movement phase, you have time to assess your position on the field of battle. There's a rhythm to where you attend. In SPHERES, there's no rhythm, just multiple things demanding attention at once.

In what I think was the only part of the film that talked about game design[1], Jonathan Blow talked in Indie Game The Movie about how you should make each mechanic you put in have multiple effects, multiple consequences. Anything else is just inefficient. Which I can empathize with, as a game designer who also tends to think in terms of systems.

And now I find myself playing Mother 3 again. I've just finished the first chapter, and it was as powerful as the first time I played it (I never finished it the first time, to my shame). And Mother 3 is a game overflowing with mechanics that aren't used to their fullest potential, code put in especially for single cases.

To take a few examples I've hit in the last minute or two of play: locked in a jail cell, you try the door. "The lock is rusty" the text tells you. But you can't do anything. But after a while, your son comes in. "I got you an apple", he says. "Make sure you eat the core, though it might be very hard". So you pick it up, and biting in find a file. I've not played through the rest, but I'm willing to bet that you never again need to use a file to open a door in the game. But it's such a compelling emotional moment, I could never consider it inefficient. 

or : If you find nuts, wandering around, you can take them to a neighbours house, and they'll make Nut Bread and Nut Cookies. These heal only a small amount of health, but knowing that I'm carrying around something made with kindness by a neighbour -- that makes me feel so much more part of the community. Again, I don't think I'll come across any other baking parts, or mini-currencies like this later in the game. It's a generosity that makes the game so much more. And ultimately, generosity is the most important thing you can put into your games.

And that's without getting into the amazing things that Earthbound did with one-off game mechanics and moments. There's a reason the logo for The Best Game Design is Ness riding his bicycle through a swamp. And, of course, the "Pray" move. I'm going to stop now before I spoiler anything, or just gush about how good they are for 2 pages. But they are so good!

"You play a babysitter, you turn up and the baby is made of cardboard. Would you stay? I want games to start asking more ethical questions"

-- https://twitter.com/#!/petermolydeux/status/143052751784525824

This is a game me and Alan Hazelden just sketched up at Molyjam London. I was trying to bully him into making a game, and we clicked througha few at random til we came across this, which seemed so very ripe for making as a kind of theatrical piece. So we went and found some cardboard, and made the game:

• The baby is literally made of cardboard. It's swaddled in a hoodie, and held as a baby because it is.
• One person is the parent, who starts with the baby. 
• The babysitter comes round, and the parent and the babysitter roleplay handing off the baby.
• "You've got my number, we'll be back at 11, everything should be fine, ring me if there are any problems" etc
• After a certain point, the parent leaves.
• The babysitters score is how long they continue holding the baby after this happens.
• I don't know if they should be told there's a scoring system in advance.

It's super creepy and awkward to play. And really funny, as all the best bizarre things are. It reminds me of the Plumber Baby sketch in Jam, a bit. Mind you, we've only tested it between ourselves, as no-one else wants to play. Can't think why.

It ultimately only ends when the magic circle wears off. Which is sustained while you're roleplaying, but afterwards fades quickly. Leaving you holding the baby. Which is actually just an empty Krispy Kreme box. Called "Jamie".

Bennett Foddy was bitching about tutorial sections on Twitter, and I wanted to respond but was too lazy to tweet. So, blog:

Sometimes tutorial sections are necessary. If it's an explicitly multiplayer competitive game, then you might ultimately need or want a singleplayer section just to teach you the fucking thing before you waste your friend's time. Fighting game practice rooms. The "training" mode in Pole Riders. But if all these are are explicitly tutorials (not just mainly), then they almost certainly suck, and you should do better. For instance, Pole Riders has you vaulting double decker buses. Trials Evolution's Licence sections are hard, as well as explicitly teaching you how to perform things you're going to need to know.

Walls of text telling you what to do are probably not great design. But they can be. The joy of poring over a manual, of reading the Minecraft wiki, or hell, visual novels or a blurb telling you how to use the parser in IF, these can be good things. I hate being prescriptive. There are always exceptions. Just go look at the "Instructions" menu item in Fez to see how best to do this. (although I seem to recall that was only inserted at Microsoft's insistence. It's certainly unnecessary. But delightful and charming and effective, etc. The game pretty much explains itself - I could hand my brother the controls deep into it, tell him what the buttons did and he got it entirely.)

Organically building teaching into your game is clearly better than having a rigid tutorial section. A lot of the joy in games comes in learning and mastering systems. See James Paul Gee for reference on this. So you're teaching the whole time, but this section is the special teaching section... It's game structure basics : teach people the mechanics one by one, let them explore and then see their powers in combination with other powers (again : I hate being prescriptive, but this is a good technique that is used everywhere). A lot of games are dead once you've understood the system and the mechanics. In Portal, once you've solved the puzzles (ie worked out the implications of the portal gun in fullness) the game is over bar the robotic lady singing.

So one thing I did love was the opening to Portal 2. It told you how to operate an FPS. How mouselook worked. That "E" was the use key. I love Valve for that. I didn't need it, but it's clearly going to have taught lots of people how to use a mouselook FPS. Which is a nice thing to do for them, a good business decision, and excellent for the industry. It wasn't a separate tutorial section, but it served that function pretty heavily. It also went heavy on the humor and the spectacle to keep those who didn't need it engaged. Because most people who played didn't need it, to be honest.

Which is the most important thing -- the reason tutorials suck is because they do the teaching thing games do so well, but because they're focused on that they fail to be fun. Or if not fun, to evoke the affect intended. If they did that well, then they magically become not a tutorial section any more. Just "the first bit", or "some nice level design", or "Licence challenges" or "The bit at the start where you get woken out of suspended animation". Suddenly we're all happy.

So a few weeks ago I made a game!

It's pretty good, if I say so myself. 

Go play/download it here 

If you're interested, here's the updates I made as it happened

Let's tell the story of it's creation first. Back when #7dfps was being discussed on Twitter, I had the idea. As I do when I get an idea for a game, I put it down on a Google Doc called "Terrible Game Ideas". Someday I should write a blog post about how great having such a list is. The idea sprang pretty much fully formed into my head back then. Let's see what I wrote, hey?

underwater FPS.

• bubbles rise constantly, unless you hold the "hold breath" button.
• go up/down too fast and you get the bends
• get near the surface, and you get machinegunned from the boats circling above.
• getting shot in the tank jets you away, makes you lose all your air
• air gauge - breathe heavier, have less time alive.
• harpoons. slow reload, little ammo. slow travelling
• stealth.
• multiplayer
• shit.
• little/no sound
• clouds of silt kicked up from the surface

Not all of that made it in, but that that didn't are still good ideas that would fit into the game.

So. I was excited as anything for 7DFPS to start. I deliberately marked it off on my calendar and didn't make plans all week. When the weekend rolled round, I got cracking as soon as the clock ticked past 1am.

The game unfortunately needed netcode written, as well as some custom modelling done. I had not done either of these before. So I was unsure what I would manage to get done. So I dug around and started off getting this Photon Bootcamp Demo. I took it, and I just started ripping bits out, left right and center. Until I was left with the very least that still did networking. And the terrain. FUN FACT: The plants in Silt are the same as the plants in the Bootcamp scene, just recoloured. Same positions, same everything. This approach paid off pretty well -- I feel like I can now deal with netcode from scratch, and I managed to make a game without ever falling too deep down a rabbit hole of tech issues. A basic scene with all this stuff setup would still be totally useful -- I know there's a whole bunch of useless state being synced across with this build.

So Saturday I got some stuff done, Sunday I spent a lot of time fucking about avoiding working on it, but I remember thinking I'd have something basically feature complete by the end of Tuesday. Which I more or less did. All this week , I've been staying up til like 2 or 3 am, which it turns out makes you incredibly tired if you're also waking up in the morning to go to work. I hate caffeine, so I was being powered by orange juice. Sugar rushes ahoy. 

I think it was Sunday I first played it with someone else -- and even at that point a fun thing happened -- Alice tried to shoot me, missed, and from that I noticed she was coming at me, so I managed to shoot her. Simple, but neat, and nothing I had explicitly planned for. Which is ace!

Wednesday's first playtesting revealed a whole bunch of balance issues that make the game a different one to the one I wanted. Basically, as a result I slowed the whole thing right the fuck down -- halving movement speeds, doubling reload times on harpoons. So I fixed those up, and playested it with people from the net -- this time almost all the feedback I got was about howshonky the chat system (which I hadn't touched at all) was awful and required firing harpoons to send messages. Plus, people saying it was cool, which is always nice.

By Thursday I was basically too tired to work properly on it, so I coloured in the plants, fixed up a few bugs, and packaged it up and put it on the net. 

So last Saturday I was at Rezzed. Amongst playing games at the show and going to the pub, I spent an hour making a card game, then was abruptly yanked on stage to show it to hundreds of people. Which was a bit terrifying, it turns out.

So here how the game is played:

There are three types of cards : attack, defence and surprise cards. Each player is dealt 2 Attack cards, 2 Defence cards and 1 Surprise card. Each player also has 10 tokens.

The attack cards can be a machete or a shotgun. The defence cards can be a bulletproof vest (to ward off shotgun blasts) or a pan lid (to defend against machetes). The surprise cards can be either nothing, or a Resurrection card (of which there is only one).

The aim of the game is for all the players who don't have a resurrection card to kill the one player who does.

To attack, you place down an attack card, with a number of tokens on it, and attack someone. That player can either defend by placing the right defence card down with the same number of tokens on it, or counter attack by placing down an attack card and placing the same number of tokens plus some extra on it. If they do this, the original attack now has to defend against the extra tokens worth of attack (by defending or counter attacking yet more). The defender then picks the next player to go (including themselves).

If you can't defend or counter-attack, you die, and the attacker takes all your tokens. If you defend successfully (and just added this rule, it was not in place on stage) then you get all the attack tokens plus your defence tokens.

If you're dead, and you have the resurrection card, you can suddenly declare yourself alive again at any time. You get 10 more tokens, and you're back int he game.

The game ends when no-one can move, or all by one player is dead. If the player with the resurrection card is alive then, they win, if they're not, everyone else wins.

To be played by more than 3 players.

I'm not sure whether the game works -- I think the economy is pretty much fucked, and stalemates (running out of attack cards) are pretty common. But I still love the idea of winning by springing back to life with a hidden card after it seems like you're dead. I also like games where the turns are decided by players, and not in a fixed order -- it suddenly adds this element of capriciousness and unfairness and negotiation to the most basic question of "Who's next?" (this is inspired by So Long Sucker, which I've been thinking about remaking recently). The game never stirred up the Werewolf style questioning of player's attributes and motives it feels it needs -- there was never enough negotiation taking place. I'm not sure how to encourage that directly, except making the necessity for it more obvious. And maybe slowing the game down some.

One reason i chose to do a jam game that was made out of bits of paper was that I spend about 10/15 minutes at the start coming up with the ideas and starting making it. From then on, I was pretty much constantly in this immensely pleasurable playtest scenario. You play the game, and you propose rule changes, constantly. Anyone can suggest a fix, and trying each one out is usually instant, and at worst takes as long as it takes to write the new cards, or count out the counters.

The downside is there's nothing to download for people who come after, and it's a huge pain to demo on stage.

Anyway! If you play the game, don't take the rules as set! Try to fix them, and tell me how you did it. I'd love to play your version.

A jam game involving cards or bits of paper for 3 or more players.

Write at least (3 x numbers of players) words describing a person onto the back of cards of bits of paper.

Shuffle them, and deal them out face down three to each player. Each player picks one, and discards the rest.

Now the group decides on a person to share stories of, and commemorate their life. This is a wake. Raise a toast to dear departed Jimmy!

You gain a point for every time you use the word on your card in conversation.

Players can guess each others words. If they guess correctly, that player can't score points any more. You can't guess twice in a row (ie if you make a guess, someone else has to make a guess before you can guess again)

The round ends when there's only one person whose word hasn't been guessed. The winner is the person with the most points.

If you play another round, the winner gets to add a card or two without anyone else seeing them.

The game is hard, but pretty funny. It's probably breakable, but that's okay.

We played with words like:

• lazy
• crafty
• witty 
• charming
• sailor
• shadow
• filthy
• powerful

Another game made at the recent Tigjam. Some footage of it is available here: 

The rules:

•  Make a wall of dice. Stack them overlapping like bricks. Make the top layer a different colour.
•  Each player gets yet another colour of dice. And a spoon.
•  First round!
  • Try to insert your dice into the wall. You're only allowed to touch the dice with your spoon, and you're only allowed to touch the spoon with a single finger.
  • The round ends when all the top, differently coloured dice are touching the table.
• Rebuilding phase!
  • Any dice touching the table with nothing on top (that is from the wall originally) are piled up on top of other dice. You can score points this way. Take it in turns to place a dice.
• Repeat first round!

Whoever has the most dice on top of their dice wins (so a dice with three other dice on top of it scores three).

It's pretty simple and stupid to play. But it's maybe a bit unstructured. Appropriate dice can be found on Witzigs.

Let me know if you play it!