Saturday 29 September 2012


As we learn a game, we construct a mental model of how it works. Sometimes our model turns out to be inaccurate, and we have to modify it to take into account new information. A game should not refrain from presenting evidence that will disprove false models of it.

In a multiplayer game, some of the responsibility for disproving our models belongs to our opponents. If I believe that Rock is a superior choice and always pick it, you can select Paper to confront me with the falsity of this belief. But our opponents will have inaccuracies in their own models as well; Frank Lantz describes the process of finding and exploiting inaccuracies in your opponent's understanding of a game while they're simultaneously trying to exploit your own as maneuvering in donkeyspace.

Situations can arise, especially with board games where there are typically small local groups of players, where all players share some of the same false beliefs and thus are never confronted with their falsity - "groupthink". We all believe that X is the most efficient, so we all always pick X, so we never learn we're wrong - unless perhaps someone from a different group joins us and shows us how X can be beaten.

Now, this isn't necessarily a problem. If a group of players settles into something that's interesting to them, it doesn't matter if they're playing poorly on an absolute scale. But if groups falsely conclude that a game is unbalanced or uninteresting and give up on it before they really understand it, if groupthink is reducing what they get out of the game, then that's something for the designer to be concerned about.

A groupthink problem has come up in a game I'm working on. It's a two-player local ipad game, like Glitch Tank, so there are the same risks as with board games for groups of isolated players. Some people are getting it fine, others aren't - they settle on a style of play that mostly involves trying to prevent their opponent doing anything, while only accumulating points very slowly themselves. This is an unstable equilibrium; if one player focused more on scoring they could get ahead, but as long as both players are doing the same groupthink prevails. It's also a less fun way to play it. One tester has reported that the rounds last a bit too long - and he's right, I agree with him, with the way he's playing it does take too long. The game ends when one player reaches a target score, so if you're accumulating points more slowly than usual the game takes longer. But tuning the target score to make those games an appropriate length would make it far too short for my preferred style of play.

Not sure what I'll do. It might be solved by the measures I'm taking to try to communicate the scoring mechanics more clearly, or it might not; once someone believes they know something it's quite hard to change their mind. I've considered different ending conditions (time limit, number of balls collected), but nothing else really seems satisfactory. Possibly I'll just relax and ignore it, and try not to mind if some people decide they don't like the game based on false assumptions about it - I should be getting used to that by now.

Sunday 9 September 2012


So this is something we're doing now: game mixtapes.

cool mix

I'm not convinced the analogy quite works; games - even very small ones - tend to be bigger and more self-complete than songs are. Ideally I'd like to pull out a bunch of individual sections from different games and string them together to make something much more closely approximating a mixtape - a track from Soul Brother, a room from Cave Story, one level of Brogue.. this isn't so easy to do with existing games.

I've dug into the idea of albums of games in the past, with Idiolect (which I never finished) and Kompendium. Specifically designing games to be joined together as an album; more distinct than individual levels of a single game, but more coherent than a series of separate games. L mentioned the idea of an album of games from different authors earlier today. I think this kind of approach is more likely to yield something that makes sense as a whole. But a big part of the mixtape idea is just to introduce people to stuff they might find interesting, akin to the Pickford Bros' "games we like" initiative; they don't necessarily have to fit together.

Anyway, here's a mixtape.

side 1:
Kenta Cho - a7xpg
Linley Henzell - Excellent Bifurcation
Chris Morris - Linerogue
Christoffer Hedborg - Cathode Rays

side 2:
Jonathan Whiting - NiƱa Nueve
Jonas Kyratzes - Alphaland
Robert Yang, Mohini Dutta, Ben Norskov - Souvenir
Stephen Lavelle - The Rose Garden

Thursday 6 September 2012

hidden costs of independent game development

Sometimes I can make a game in a month, then sell it to make $1000 or so. Maybe that's not great by most people's standards, but if I could do that every month I'd be pretty happy, that's enough to live on.

But most of the time it doesn't work out so well. Making games quickly requires quite an intense level of effort that isn't really sustainable long-term. Sometimes I get sick, and while that might not prevent me working, it limits my potential. Sometimes things break; computer hardware isn't very stable under immersion in liquids or high-speed collisions, and repairs or replacements can be pretty costly. And sometimes I'm an utter fool and write over a month's work that I haven't backed up.


Running some disc recovery software now and hoping it can rescue things.

And other times, I can spend months prototyping various ideas that sound cool in my head but don't actually work. Some simply don't work at all, but others seem quite close to working, if I can just think of the right way to bring their pieces together. Trying out new ideas takes a lot of time and gives a lot of failures. I can see why some prefer to stick to variations on an established formula; trying out new things takes a lot longer and tends to be less favourably received.

When I make a game in a month and it works I feel pretty amazing. I feel like I could do that every month no trouble. But I can't, because there are all these hidden costs that I don't perceive at that point in time. Those months are a few among many. Just counting the development time of a game from when I started working on that particular game until when it was released misses a lot: the risks of accidents happening that didn't happen to occur in that time, the time spent on failed games that mapped out the way to that one, the time spent fixing bugs and trying to convince anyone to review the game afterwards, the subsequent period of exhaustion from overwork. It's not enough for a game's sales to just cover the time spent making it.

I'm very lucky to be able to continue making games for now. Lucky to have had a game on Steam and the Indie Royale bundle, that actually made enough to pay off my student loan and live on for a bit. Extremely lucky that my wife has a job at the moment that pays enough to support us both. I feel kind of bad that I sometimes complain about not having much income from games when there are others in genuine need. But if there comes a time where I need to choose between trying to support myself entirely from making games or going out and getting a real job this is something that I'll need to remember: I can't consistently make games as quickly as I think I can, I have to take into account these hidden costs.