Mandible Games

Here it is. Experimental Game #1.

(Download for Windows)

I've already shared this around to some friends, so I'm just going to post my postmortem right now.

It all comes down to my mom.

My mom is not very good at games. She's better than she thinks she is, but she has a real hard time working through any kind of roadblock. Super Mario World? Can't get to a save point – can't even beat the second level. Braid? Well . . . it turns out she's actually pretty dang good at Braid.

The difference is the "game over" screen. She hates the Game Over screen. She hates being told "well, you're doing better . . . but *not good enough*!" Super Mario World has that failure screen. Braid doesn't – you just hit the rewind button and try it again.

No Such Thing is impossible to lose.

Seriously. You cannot do it. If you get hit, you lose your current gun and instantly get a better gun. Eventually, you will kill the final boss, and win the game.

The challenge is in seeing how far you can make it without being hit, and it's self-balancing in the sense that, if you can sling more firepower around, you can avoid being hit better.

I'd hoped people – even people who were bad at games – would find this interesting enough to give the game a few playthroughs. I'd hoped people wouldn't be scared of it – sure, you got shot, but all you got was a better gun! No worries! Keep on truckin'!

In the end, the game took about five days to make. I considered adding one to three more levels but I couldn't think of any interesting level gimmicks that wouldn't take a solid day just to code (walls, for example, or enemies that couldn't be described easily as circles) and it just didn't seem worth it. The gimmick was the interesting part, and the game is developed enough to test the gimmick.

What Worked

The game design itself seems to be rather effective. People enjoy it, and seem to frequently try several times to get a better score. That's what I was hoping for! Even people who are traditionally very bad at action games seem to enjoy giving it a few shots – sure, they're bad at it, but they get better at it rapidly. And since they're competing against themselves, rather than against a fixed "ha ha you are terrible at games" metric, they can see their progress in a more useful way than moving from #722,857 to #618,004 on a gigantic leaderboard.

So the idea seems to be a success.

Another goal for this game was to try out the game framework I put together. The framework is also a success. All the game and UI logic is in Lua, and that worked stunningly. (Coroutines and upvalues are golden.) I was worried about performance issues, but I flat-out haven't had any – the only performance problem I had was when I had a bug keeping bullets from being culled, so every bullet you fired flew forever. I cannot recommend Lua enough. You should be using it.

The framework was a little rocky at times – there were inevitable bugs – but I probably spent only a day or so overall fixing them.

SFXR turned out to be great for sound, and I'm actually quite satisfied with the sound in this game. For the amount of time I spent on it, it's perfect.

What Didn't Work

Originally I'd planned for the weapon types to upgrade as well. It seems to be a common issue in my games that I end up changing "upgrade weapon types" into "upgrade firerate" – this is the second time I've done it. I tend to do it because it's easy to tell which weapons are better if you do it this way, and it's easier to make a level that behaves interestingly, but the character suffers as a result. I need to stop doing this. Varied weapon behavior is more fun than just turning a slow-fire weapon into a rapid-fire weapon.

My art, while better than I feared, is pretty damn awful. I need to work on that more. Practice will help.

I'm still, fundamentally, afraid of OpenGL. I think my next project may have to involve a lot more flashy OpenGL effects that cannot be expressed with "draw some sprites", because I'm basically limiting myself to "draw some sprites". As with my art, that's making the graphics suffer, and graphics are an important part of the experience.

I still need to figure out some better patterns for making Lua do what I want. Things went great until I set it up so you could start over, or start another level, and then they degenerated into murk. I've got some ideas to fix this also, but I'm going to have to research Lua semantics more than I'd hoped.

Speaking of Lua semantics, I had a constant war with getting useful stack traces. I'm going to have to sit down and make a good stack trace library so I can get Lua stacktraces easily. It all works great until you involve coroutines, and then it melts down. It's solvable – it'll just take a day or two.

Taking a week to do some other stuff, then working on my dev framework a little . . . then moving on to another game.

Let me know what you thought of this one.

A few months ago I went to GDC. Something came up surprisingly often at the Indie Game talks – a course at Carnegie Mellon called the Experimental Gameplay Project. The EGP is about making games. Lots of games. One person spending one week on a game as an experiment to see if it's even a good idea.

Usually, it isn't.

Sometimes, it is.

It turns out going through tons of games means, eventually, you get something extraordinary. It seems to take about a dozen tries in general. But you've got to start somewhere, right?

So I'm doing it. One game per month, one week per game. They'll all be posted here. Here's the rules I'm following, for the sake of future reference.

* For the sake of easy bookkeeping, games will be posted once per calendar month. If I post a game on the first of July, I'm not required to post another until the end of August. If I post a game on the last day of July, I'm still required to post another before the end of August. Easy to check.
* Only one game per calendar month counts. I can't post three games in a month and have that count for three months.
* A game's development will end, at most, exactly 168 hours after it begins. There are no excuses given for sleep, or being sick, or anything else. "PR materials", like screenshots or explanatory text, are not counted in this development budget, and bugs may be fixed after it as well, but game mechanics may not be changed unless I'm actually turning it into a full game.
* Games will be developed solely by me. I'm not making these games polished and gorgeous and perfect, and I don't want to deal with any kind of managerial issues. So. My games, one developer, me.
* A game must be technically playable and interactive in some sense. It does not, in any sense, have to be fun, or winnable, or have goals, either explicit or implicit. They're experimental, folks. Sometimes we're gonna have disasters.
* A game must be distributed publicly and for free. Otherwise, how can everyone laugh at it?
* Within two weeks of the game's release, I will must post at least a cursory postmortem of what was intended, what worked, and what didn't. The goal's to get better at writing games, not to release a bunch of crappy games! The delay is included so I can get commentary on it before having to guess at whether people will like it.
* Withdrawal from the Game Project must be announced at least two game releases in advance. I can't do "well I'm busy this month so no game, sorry guys", or "alright here's a game, by the way this is my last one!" If I do, I'm a sissy.

That's the plan.

Let's see how it works out.