Mandible Games

I'm having a tough time making a postmortem for this because almost nobody played it. C'mon, people! Gimme something to work with!

I had a few goals for this game.

First off, I wanted to piss off people who thought I was making a sexist game. I got a few bites on that front so I'm considering it a success. Sort-of-unfortunately, everyone laughed it off once they realized what was actually going on. I guess my friends are just too reasonable. I'm not really complaining about this aspect of things.

Second, I was trying to come up with a game that wasn't trivial to minmax. I made great strides in this direction and figured out the first really interesting scoring mechanism I feel I've managed. That, along with the "grades", made for a game where people were competing for highest score. Some of my early testers and most of the people who commented on it later, in fact. That's pretty cool! I thought score was a worthless mechanic, but I may have finally figured out a way to make it worthful: first, make it interesting to max out, and second, introduce goals so people know what they're shooting for. Doubling your score isn't motivating, but getting from a B to an A is damn motivating.

I'll probably write up more on my scoring mechanic later.

Third, I was doing more with 3d. Some of this was successful – the isometric viewpoint turned out pretty neat – but I had trouble getting stuff to work right. I need to learn more about 3d math and I just plain haven't. That's bad. It could have been much better.

Unfortunately, the rest of the game kind of fell flat. The entire thing – to me, at least – feels a bit sterile. I had trouble putting soul into it, like I have with several before, and I'm starting to feel like that's just sort of a random thing. Either it Works, or it Doesn't. K0R and Nieuwe Aarde worked. This one didn't. I'm going to be keeping a close eye on my future games to see what results in style and what results in no style, but that'll take quite a while to narrow down. On the list.

I'd say "it might have been that I had so little time available for this, it was really time-crunched" but I mean look at Nieuwe Aarde which was completely made in basically a state of constant panic, or K0R where I spent almost the entire game development process saying "goddamn, there is no way I'll get this done in time", and . . . well, honestly, being time-crunched generally seems to help. So I have no idea.

In terms of score, I broke fantastic new ground. In terms of everything else . . . well, needs some work, let's say.

Windows (.zip version available)
Mac OSX
Linux (32-bit only)

I told you guys I'd have a game this month, and by Jove I've got a game this month!

(For comedy value: check the timestamp of this post.)

The Experimental Gameplay Project theme this month is Boys And Girls. If we're a boy, we're challenged to make a game that girls will like, and vice-versa. I, of course, decided to make two games. One for each gender! How could this go wrong? I can appeal to everyone!

You should go play it immediately.

Windows (.zip version available)
Mac OSX
Linux (32-bit only)

A few months ago I did the first Reddit Game Jam. The theme was Opposites, and I managed to finish this shortly before falling asleep on the second day. That same month I'd done some other game (I'm thinking it might have been K0R) and so I never got around to posting this.

Luckily, the terms of the Monthly Game Project don't require that I post a project anywhere near the time of me finishing it! So I've been holding it in reserve for a month when I don't manage to complete a game otherwise. This month is that month, so here's Ramsgate!

Commentary, as always, welcome.

Speaking of the terms of the Monthly Game Project: I've got a few major things possibly coming up that are totally exciting. For example, I may be getting a job working on a commercial game that I think looks damn cool. And I'm putting a lot more time into making Robert Recurring into a commercial indie game.

Guess what I don't have time for anymore?

That's right: the Monthly Game Project.

I'm going to keep posting games when I can, but that might not be once per month. Things may slack off a bit. I'll try to compensate with more journal posts. We'll see how that goes. It is an adventure!

So, Chassis Commander. The result of Ludum Dare 18. For those who aren't familiar, Ludum Dare is a 48-hour game design contest. You get a theme the instant the timer starts ticking – this theme was "Enemies As Weapons" – and you get to make the best thing you can. Chassis Commander came out as a reasonably solid #37 out of 172 overall, which I think is a rather fair assessment.

And I find myself in a somewhat difficult position. Chassis Commander was fun, but it wasn't really notable. It was kind of average. Now, I'll admit that being able to churn out an average game in 48 hours is pretty goddamn awesome, but it makes it rather difficult to write a reasonable postmortem, since it's tough to say things that are . . . you know . . . interesting.

So here we go anyway.

What Worked: The basic gameplay came down to pretty much what I'd intended. Shoot things a lot, scoop guys up as you go, try to master the new crazy gun you just picked up, repeat. The idea I had was solid and turned out well.

There was a lot of tweaking as I went – you may or may not have noticed the gigantic words that flash up in the center of the screen, for example. Those turned out to be 100% necessary because without them I didn't notice when I was running low on ammo or whatever. Same with the color-coded flashing crosshairs. It's all well and good to say "the game was mediocre", but without some of those extremely critical tweaks the game would have been just plain bad, and I'm glad I noticed and fixed them.

One thing that's consistently amused me is how people tell me they've just been right-clicking on the big monsters to suck them up. Like they're breaking the game somehow. No, that's a strategy! I had intended that to work from the very beginning! Use it! The existence of strategies like this is, I feel, a sign of a not-terrible game. :)

What Didn't Work: There's a few issues that have come to light after release. First, I've had people tell me that the game should weight random pickups towards the item the player needs. Actually, it already does, to something like a tenfold weighting – and it's still not enough. Geesh. So, maybe that should be stronger? Or maybe the item pickup system should work a little differently, so you can build up a small buffer of items and not be so vulnerable to the vagaries of the random-number generator?

I'd intended for the player to be able to intentionally grab specific items to change their gun into something more useful. I've never seen anyone do that. People pretty much right-click on flashing things, or just right-click on monsters. There's not a lot of thought as to gun layout, and I feel like in some ways the game would be better if I got rid of the entire sucking-objects-up mechanic and just handed out guns randomly.

'Course, then it wouldn't conform to the Ludum Dare theme.

I've had some problem with people dying near the end of the level and having their death blast finish the level for them, to the point where I've had a few bug reports that dying makes you go to the next level. I didn't realize how common this would be. Kudos to me for balancing things so that players tend to die at the very end of a level as they're just barely overwhelmed, but I should have realized that would be a bigger problem. The original intention for that mechanic is that I didn't want a player to spawn literally on top of a monster and just die, but obviously the mechanic didn't work properly. I probably should have just blown up monsters around the entry point, or done a classic NES-style "ghost mode" for three seconds or so.

And a small thing, but an important one – it occured to me way too late that I never explained how the ammo types worked. Whoops! I was intending to make the ammo-type change something that had to be done a little intentionally, but at some point that just stopped happening, and I probably should have gotten rid of the ammo-type mechanic entirely.

On a larger level of failure, I'd wanted to have some kind of a "world map" a la Super Smash TV, so you could either beeline for the boss or take a longer route to get more points or coins or McGuffins or whatever. I just didn't have time for this – the final version was released about an hour before LD18 ended. Additionally, I wanted a boss, and I didn't have time for that either. More weapons would've been nice. Again, no time.

The Bottom Line: I made a good game, but there's something missing. I look at games like K0R or Nieuwe Aarde and there's a certain level of style and hook that pulls people in. Chassis Commander doesn't have that, and I'm not entirely sure why. I lost a bit of the design charm for this game and I'm gonna have to figure out what happened and how to fix it.

Windows (.zip version)
Mac OSX
Linux (32-bit only)

CHASSIS COMMANDER!

Marooned on an unknown planet!

CHASSIS COMMANDER!

His only weapon, a hoverbike with a malfunctioning weapon!

CHASSIS COMMANDER!

Besieged by a million unstoppable robots!

CHASSIS COMMANDER! (you should be imagining this with a significant amount of reverb btw, go back to the beginning and start again if you're not)

Can he use the robots to repair his vehicle? Can he muster up enough firepower to defeat them all? Can he learn how to use the over-100 unique weapons that he can cobble together from compressed robot parts? Can he survive this horrible onslaught?!

CHASSIS COMMANDER!

Play it today!

(Ludum Dare 18 submission. Made in 48 hours.)

So, I made this game. And – let's be fair – it sort of sucked.

I could go on at great length about how this is Box2D's fault, and thanks to issues integrating Box2D with Lua. There's some truth to that. There's still bugs in there causing the physics to behave a bit wonkily. I spent a lot more time working on infrastructure and bindings than I'd meant to, and even today it doesn't work properly on Linux (and probably won't, to be honest, it's not a good enough game for me to spend the time on it.)

But that's not why the game isn't fun.

The original view I had of the game was that you'd be running along towards the next checkpoint, trying desperately to get there in time, and at the last minute you'd fling yourself towards the goal, die in midair, and get to watch your corpse crunching its way down the mountain until you happened to fall into the rejuvenator and oh god time to keep running go go go get to the next checkpoint.

But there's a bunch of problems here. First off, it requires you to make a crucial decision – your exact death position and velocity – before you can even see what you're trying to aim for. Second, physics tends to be extremely chaotic, so either the game needs to be built to funnel the player inevitably down into the right location or the player's death is near-certain, regardless of skill. And, of course, if you funnel the player down to the right location, then you're making skill irrelevant anyway. A game with no skill component tends to not be a good game, and as much as I rail against them for being low-skill, even Bejeweled and Peggle involve more skill than my original vision of The Ultimate Race did.

Even that isn't the crucial problem.

The reason the game isn't fun – and this took me a while to hunt down – is that a game of this sort is only fun if you're almost losing. If you get to the goal quickly, it's easy, and you'll never bother with an early death and it's boring. If you're nowhere near the goal, you lose no matter what and it's simultaneously boring and frustrating. The player has to be right on that knife edge of losing for that fun moment I had in mind to actually occur.

And that's just ridiculously hard to orchestrate.

If I were going to do this again, I'd be trying one of two different approaches. One is to make the difficulty self-balancing in a sense. I hate auto-adjusting difficulty, so in reality what this would mean is that reaching a goal very quickly would unlock a "harder path" that the player could choose to go on, so the player could make the game as hard as they could handle and thereby keep it fun.

Another thing I would try would be to remove the time limit entirely, and even remove the voluntary-death button. I'd add some kind of a laser defense grid around the checkpoint. You die because you leap headlong into a laser and get fried, and that is when the whole "fall down the cliff praying" thing would kick in. I'd play up the "race" thing more heavily – you'd ideally be racing against a bunch of computer opponents that don't get shot by lasers ("sorry man, we're out of the reflective armor. good luck!") and so you'd be encouraged to leap headlong into danger without really spending a lot of time preparing.

And finally, the player needs at least some influence over the corpse behavior once he's dead. Even if that's limited to twitching in one direction or another. Something.

I feel like, in some sense, this game is a milestone for me. It's the first time I came up with an idea that just flat-out didn't work – the rest of my unsuccessful games have been unsuccessful because I didn't have an idea. So, I mean, I had an idea, and it sucked. That's progress.

I think that's progress.

Windows (.zip version available)
Mac OSX
(No Linux version currently available, there's a bug I can't find right now)

This was made for the annual SomethingAwful GameDev Challenge V. The theme for this year was "You Can't ____" – something that you would normally be able to do, but something that you are now unable to do.

Make a game out of it!

As such, The Ultimate Race is subtitled "You Can't Avoid Having Constant, Instantly-Fatal Heart Attacks".

This is my first game with a physics engine involved, and some parts of it went . . . rockily. I ended up spending far more time fighting my tools and far less time actually making the game than I'd expected. Still, here's a game. Go play it!

Well that didn't work.

Windows (.zip version available)
Mac OSX
Linux (32-bit only)

The theme of this month was Casual Addiction. I came up with the bare bones of an idea, without any real belief that it would make a fun game, and decided to implement it and see what made it fun.

Four days in, with virtually nothing to show for it, I realized this entire thing felt very familiar. Almost like I'd done this before! And, shockingly, it worked just as well this time. I am amazed! Are you amazed? We are all amazed.

What I've realized, albeit a bit too late for this project, is that I absolutely need a clear vision of what I'm working towards. If I don't know what I'm trying to code, I can't code it. Now, it's fine if this ends up morphing as I code, it's fine if what I end up with bears only tangential relation to what I originally intended to make. But I need that anchor point to work for, and I didn't have it. That is something I'm going to be watching for in the future.

I'll describe what I was working for, though. Maybe someone else can make it entertaining!

I was planning on working Casual Addiction very deeply into the game idea. You were going to be a drug dealer, and part of the game would involve getting your customers hooked and then getting lots of money from them. But that was a double-edged sword. The more customers you had, the more the cops started noticing you. Unfortunately for you, just shutting down one of your dealerships wouldn't really solve the problem – now your customers would be looking for a new dealership to buy from, and in the process of searching, attract even more police attention.

Similarly, your less-alert drug runners had a chance of being noticed by police (this is Bad). You could assign guards to them . . . but that would, in the process, reduce their Alertness even further, as they'd start relying on the help.

So basically, whatever you did with an intent to make your life easier would result in you being locked into that long-term, with a huge amount of pain to un-do it. I was hoping to balance things such that the "way to win" was basically stay low and under the radar and not try to make it big, while being a Big Drug Dealer would result in a cataclysmic meltdown unless you realized what was going on and bugged out early.

The problem is that I didn't have any mechanics for any of this. I was thinking of having Police and Runners walking around the world, but I was never happy with my mental image of how it would work. I was thinking of abstracting Police into some basic values, but I never came up with actual mechanics. I didn't have a game, I had a pile of unconnected ideas.

And, as a result, I don't have a game.

I've seen this exact same problem play out over and over, which is why it's kind of embarrassing to realize I've been doing it myself. It's the classic class-project or group-project issue. One person says "hey roleplaying games are awesome, let's make an RPG" but nobody has a clear view of what they're actually trying to make. They know it's got main characters, and a game world, but there's simply no coherent vision. If nothing else, I'd say that coherent vision is the most important thing to get, and fast. With Nieuwe Aarde I was forming the vision even as I was doing the first development, but less than an hour in I knew I'd have islands and you'd build buildings on those islands and there would be a monster attack once in a while. That's the core of Nieuwe Aarde, and once I had that implemented I was fine to spend a day tweaking and polishing.

So, if you're trying to make a game: write down your plans first. If you don't know roughly how game balance is going to work before you've written your game, you're certainly not going to be able to figure it out midway through.

The only thing that went right this month was that I recognized a recurring pattern. With luck, I'll be able to stop making that mistake in the future.

This game had a lot of firsts. It was my most visually ambitious game yet. It was my first use of actual perspective. And it was my first serious attempt at making art without resorting to 2d sprites – the only sprites in the game are the black structure at the beginning, the minigame icons, and one simple sprite used for the explosion graphics.

What Worked

Honestly, all of the above worked.

The game does look good – I think the explosions particularly turned out well. I spent a good chunk of time on "small things" like screenshakes and a gradually changing background. Things that nobody really mentions, but that help the game tremendously. So, full marks for art.

The game design itself also worked as well as I was hoping. The game design didn't really change from the first day to the end – I knew where I was going with it, and I went there, and everything was good. I didn't have concrete plans for the bosses from the very beginning, but they came together in an hour or two each once I sat down to work on them.

What Didn't Work

I made some decisions early on about the monster graphics that ended up constraining my design a bit more than I'd really intended. Namely, I just assumed I'd be sticking with right angles for everything, and, later, when I found myself wanting more complex layouts, I couldn't do it easily. I'm not sure this would have been easily solvable, however. I could have changed it moderately simply, but it would have been Difficult to do the actual graphics design without that constraint, as my character design was limited to text input.

Originally I had plans for how to produce more organic-behaving monsters – still built out of right angles, but with the individual parts given a little more freedom relative to each other. I ended up not implementing this due to a lack of time. I was also running into issues with render speed, which that would have made even worse. I'm not sure what the actual render speed bottleneck was, though I suspect it's heavily based around my continued use of immediate mode OpenGL. Solving this will require me to finish my Lua OpenGL layer first.

Speaking of graphics, I decided to use framebuffer objects to do the bloom effect. It turns out that framebuffer objects are problematical, as many graphics cards don't support them, and I actually reduced my userbase rather unfortunately with them. The "standard solution" appears to be rendering to the screen, then copying that to textures. Unfortunately that is difficult with my current render framework. I'll have to come up with a solution for this in the future, as I'd now like to avoid FBOs.

More graphics issues: I did the complex texture effects entirely with shaders. It turns out that shaders don't antialias well, and I was having horrible aliasing issues. Turning up the back render resolution fixed that issue. An effective 64x antialiasing looked goddamn gorgeous. It also ran like crap on every system I could get my hands on, besides my main computer, so I turned it back to 4x and crossed my fingers that it was an acceptable tradeoff. I'm not convinced it was a great tradeoff. The only alternatives were to completely redesign rendering in terms of multiple textures or to try simulating anti-aliasing inside the shader itself – the latter didn't go well, and the former would have taken a lot of time. I'm not sure what else I could have done better here, but I'll keep it in mind as a stumbling block.

I spent about six hours trying to get perspective working properly, but I kind of expected that.

I also ran into some problems writing the monster AI – I had hacks upon hacks upon hacks, and that, as well, became a significant bottleneck. I've since written some chunks of code to provide a more powerful and general AI layer, which should prevent that from happening in the future.

Despite all the work done on making the Linux version work well, I had one giant critical error that – as near as I can tell – broke it on all NVidia cards. Whoops! Guess I shouldn't have relied on friends and VMWare. That's fixed now though, and the incoming Linux error reports flatly stopped after fixing that bug. This was kind of expected, though, new platforms are always a little flaky until you do a serious test.

The Bottom Line

I know I just spent like 3/4 of this post talking about fuckups, but the fact is that I think the game was pretty successful. I got everything done I wanted to, and the game worked out as well as I'd wanted. I don't have anything major to say about the game design itself.

I'm trying a few new public-relations things, despite it feeling a little bit scummy. I went and posted a bunch of stories on Reddit and got a huge pile of comments and readers, so I feel like that worked out well. I was kind of hazy about whether this moved into "spammer" territory or not, but considering the generally positive feedback, I figure people aren't objecting to the content. Oddly, I simultaneously feel like I'm getting fewer non-Reddit comments on this game than I'd expected, though maybe I've been spoiled by the feedback on Robert Recurring and Nieuwe Aarde. (So if I'd posted RR or NA heavily on Reddit, how much feedback would I have gotten?)

The hits I'm getting for "mandible" are finally overcoming the hits I'm getting for "hard disk double boiling".

In summary: k0r worked out great. I learned a lot from it, and I learned a lot about what I fucked up badly. Time to move on to the next project!

I decided to spend a little more time on graphics this time around. Here's the result.

Windows (.zip version available)
Mac OSX (10.5 or higher)
Linux (read notes below)

A few major things to be aware of.

First, this game makes more extensive use of your video card than any I've written before. As such, if you've got old hardware or bad video drivers, you may have trouble running it. Sorry! It should tell you if anything goes wrong. I did fix a bug causing it to crash if you had no audio output, so that might make a few of you happy.

Second, I now support OSX 10.5. At least, I think I do. Let me know if there's problems.

Third, I now support Linux. At least, I think I do. There will be problems. I know for a fact that it does not natively run on any 64-bit Linux distribution. I've heard there's a way to fix this, but I don't know what it is yet (besides "make a 64-bit build" which won't be happening for a while.) The sound layer also seems to be a bit flaky – there is sound, but you might not get any. I may be rewriting the sound layer in the near future. I'm also hoping to add .deb and .rpm packages in the future.

It's been tested successfully on Ubuntu 10.04, Ubuntu 8.04, Kubuntu 10.04, Fedora 12, and Debian 5.0.4. Success, in this context, means "it either ran properly, or complained about a lack of video card capabilities." It's been tested unsuccessfully on Ubuntu 64 10.04. It's also crashed on a friend's system running Debian 6.0 test. Why? Couldn't really say! I'd absolutely love any data points or debugging assistance you can provide.

Obviously, I haven't said much about the game. That's because you should be playing the game and not listening to me ramble about it.