Tagged: Monthly Game Project

MGP: Children’s Games

Starting January 2016, I made a game or more a month for the whole year. I continued this until 2018, creating a corpus of 39 card or board games, including Looking For Group, Senpai Notice Me, and Dog Bear. Starting in 2019, I wanted to write about this experience, and advice I gained from doing it for you. Articles about the MGP are about that experience, the Monthly Game Project.

Making games for kids is a challenge.

Continue reading

MGP – The Mistake Of Chin Music

Starting January 2016, I made a game or more a month for the whole year. I continued this until 2018, creating a corpus of 39 card or board games, including Looking For Group, Senpai Notice Me, and Dog Bear. Starting in 2019, I wanted to write about this experience, and advice I gained from doing it for you. Articles about the MGP are about that experience, the Monthly Game Project.

When I made Chin Music, there were three basic things coming together. First, the idea was to try and make a game that wanted to be played quickly, but wasn’t real time. Real time rules can be challenging to make work, but the purpose of real-time play is usually some degree of tension. The idea that came together was of a game that evoked a fight, and which I could produce quickly and easily without calling on an artist.

Now, I want to make it clear if you think I’m rubbishing Chin Music. I love Chin Music. It’s one of my favourite games I’ve made. I like how it looks and I like how it plays. But there are two Chin Musics – a beta model that was printed, and a proper version that you can buy now.

The basic mechanic of Chin Music is a bit like Snap. You lay down cards with sound effects on them, and list the sound effects in a row of the stack so far. Then, when you messed up, players flipped the stack over, checked how powerful the gang of hooligans outside you’d antagonised, and then you won or lost points based on that. Players could see the back of other players’ cards, so you’d know generally how dangerous the gang would be. The real-time aspect of the game is that the longer you take on your turn, the harder it gets to remember the stack of cards. You want to pass the turn as fast as possible just as a function of memory.

Here’s the problem: That second mechanic sucks for a game that wants to move fast, and it jerks the whole game to a halt when you need to check it. The mechanic that replaced it was much simpler: When you mess up, another player can call you out for it, and if you did mess up, you shuffle those cards and put them into your own deck. This meant that there needed to be a few more cards, and that meant the card backs needed to be cleaned up, and then since the deck got a bit bigger, I could put the game into a cardboard tuckbox (technology we didn’t really embrace fully until 2018). Overall, this means that early versions of Chin Music are, while perfectly functional, really not as good as the final versions of it, and that bums me out.

But I still put the first version up for sale, in a rush, because I didn’t want to miss making ‘a game a month.’ This was a bad decision, because if I’d postponed it a week or two, nobody would have really noticed. I’d have gotten the first version, found the problem, been willing to address it then, and just delayed the game.

This is one of the ways the printing time kicked me in the butt. My first prototypes of this game were made with playing cards and I found the awkwardness of the scoring system was – in my mind – tied more to my handwriting and the cheapness of the prototype than the actual problem in the game.

I wanted to release a game a month, and since I was doing it without a plan or a contingency, and doing it without clearly defined boundaries of what did or did not count as a release, or any way to recover from mistakes, I now have stock of a kinda-bad version of a game I really like. Let that be a lesson for you: If you’re going to do a project like mine, give yourself defined limits and boundaries, and ways to recognise and handle failure.

MGP – Confronting My Limits

Starting January 2016, I made a game or more a month for the whole year. I continued this until 2018, creating a corpus of 39 card or board games, including Looking For Group, Senpai Notice Me, and Dog Bear. Starting in 2019, I wanted to write about this experience, and advice I gained from doing it for you. Articles about the MGP are about that experience, the Monthly Game Project.

I’ve remarked, but not made explicitly clear, that the game-a-month plan had some problems. In the past I’ve talked about some general problems, like lead times and the awy the Pacific Ocean imposes itself between me and my goal of Making More Stuff. But rather than present that as my problem, I want to talk to you about your problem, if you want to try this same project.

There’s this idea in media making (and a lot of other places) that gets brought up called agility. Agility is the measure of how quickly or how well you can do… things. It’s often used as  a shorthand for how quickly you can shift from doing one thing to doing another, different thing, or how quickly your thing can implement major changes. You might hear the term pivot get used.

I’ve remarked that making card games has a problem with prototyping. It’s just a mechanical concern; if you want to make a game like Magic: The Gathering, it’s not as simple as making a bunch of proxies; you kind of need some way to bulk create pieces to playtest with. Often that can make prototype printings, and that means that these games require a certain scale.

It’s very hard to get to that scale fast.

There are a bunch of games I’ve made that I couldn’t playtest at the scale, and I couldn’t prototype properly. Then, to hit the convention schedule, those games got rushed, and as a result, the games were… well, a bit weak. Just the truth of it: The games were a little worse than they should have been, which is a thing that I really regret now. Playtesting is hard, scope problems make it harder, and I flew real fast, real hard and sometimes it didn’t work.

That’s the problem: What’s the solution for you?

I have three suggestions.

  1. EMBRACE PRINT-AND-PLAY. Make your games for smaller spaces. Don’t think of bouquet card games, at least not for your first games. You can put a PDF out there in the world, made as simply as possible, which is just meant to give people a way to get the game pices working. You can do a lot with print-and-play – boards, sheets, cards, all that stuff. You might learn that ‘shuffling’ is hard, but you still get the basics of how a game works done. Players who make Print-and-Play are really good at knowing how much work they want to put in.
  2. BOOKLET SUPPLEMENTS. You’re one person, working small and experimenting with mechanics. Use existing systems and make single-page variants. Make booklet mods. Make a game that only needs to work for a little while, or maybe make a booklet mod for a board game – like I’ve joked about doing for Monopoly.
  3. MAKE THEM FREE. One of the games I’ve made that’s most successful in terms of distribution is Simon’s Schism. It’s also one of the games with the most feedback… and it’s also free. There’s a fear to missing out on sales for your free games, but you won’t make a lot of sales, and when you’re not charging people for your time, you don’t have to feel bad about making edits or updates to these games. This is your first period making games: Make a corpus of games that are more about showing people your work than it is about making money off them.