Mandible Games

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.

So. Nieuwe Aarde, that game I made for Ludum Dare in 48 hours.

This is going to be one of the toughest postmortems I’ve written.

What Worked

Well, first of all, it’s fun. I’m getting a lot of commentary saying that they enjoyed figuring it out and that they think it’s an enjoyable game overall. That’s cool. I seem to have done a good job with the base game mechanics and the interface, I’m having very few people tell me that they simply couldn’t figure it out.

The art, while not spectacular, is servicable and nonconfusing. The game feel is consistent. The tooltips work absolutely great for explaining the concepts.

I also appear to have nailed the difficulty. I’ve had a few complaints that it’s way too easy, and a few complaints that it’s way too hard, but the bulk seems to fall into the categories of “it’s tough, but I beat it” and “it’s tough, and I didn’t beat it, but I think I could have if I’d put more time into it.”

For doing it within 48 hours, it turned out great. Compare it to my earlier games – I spent a third as much time on this one, and I think it turned out better. My tools are maturing like you wouldn’t believe and I’m just getting faster and more skilled at this whole thing.

So, in summary, I made a good game.

What Didn’t Work

The problem is that I didn’t make the game I wanted to.

The original goal was Desktop Dungeons meets Seafarers of Catan. Desktop Dungeons is a clever small-scale dungeon crawler which is designed so that almost every single move is critically important. Sure, you can get a nice lead, but that lead can be whittled down rapidly by bad luck. Doing “as well as you can” is critical, every step of the way, and each time you click it had better be the right click.

Nieuwe Aarde doesn’t succeed in that. You’ll spend a large part of the game clicking “Work” over and over, for example. Clicking a few too many times? Totally okay! Building the wrong thing entirely? You can probably recover! There’s very little that has to be timed exactly, and the game design itself isn’t conducive to the sort of miniature puzzle where you’re trying to scrape out the last little possible iota of advantage.

I still think it may be possible, but if I want to do it, I’m going to have to start from basics again.

The Bottom Line

I made a fun game, but I made the wrong game. I’m not really sure whether I want to call this a success or not.

On the other hand, I made a fun game. If this is failure, I wouldn’t mind failing more often.

The planet is dying.

Monsters raise themselves out of the ocean monthly. The skies themselves blacken.

You, and your civilization, have but one choice: amass enough magical power to leap across the starless void, to another, safer planet. But you’re racing against time – every day the attacks get stronger.

The planet is dying, and it’s taking you with it.

Ludum Dare competition page and voting

Windows (.zip version available)
Mac OSX (10.6 or higher)

Nieuwe Aarde was made for Ludum Dare 17, a 48-hour game development competition. Yeah, that’s right, my normal week-long development process was compressed into two days.

Ouch.

The theme for this event was Islands, and so Islands is what I did! Nieuwe Aarde was inspired by Desktop Dungeons and Seafarers of Catan, and I feel like I’ve made a reasonably coherent little single-player strategy game with a whole pile of tooltips.

Postmortem up in a few days. Time to start on the next project!

So hey been a while. Let’s get this thing wrapped up.

I’ve gotten a curiously small amount of commentary on this game, and I’m not quite sure why. Doesn’t give me a lot to go on, and it worries me that, perhaps, I did something wrong that I will be unable to figure out.

Who knows!

What Went Right

I decided to tackle hardware shaders and higher-end graphical effects in this game. Overall I think this was an amazing success – there are a lot of effects in this game that are done entirely via hardware and on the graphics card, and the game comes across much better thanks to those. In fact, even something as simple as the lit-up paths are hardware processed. Wonderfully powerful and I’ll be using similar stuff in the future as needed. Huge success.

I feel that the sound effects turned out great as well, which is surprising because I maybe spent two hours on sound for the entire game. I wasn’t intending to end up with such a meditative soundscape but that’s kind of what happened, and I really rather enjoy it. Happy accident there.

The basic game design . . . I’m a little uncertain. I’ve had a few people suggest that it would be better with a touchscreen interface and a countdown, and I think that might be true – the “falling tiles” behavior doesn’t lend much of interest to the gameplay. However, the actual idea, linking things via wires one way or another, seems to be pretty dang fun. I think it’s got potential for tweaks and improvements.

What Went Wrong

Nobody anywhere has commented about the achievements. Did people not notice them? Did people not care about them? I have no clue! Tell me what you thought of them, or even if you noticed. The idea was to give people suggestions towards things that might increase their score, or towards things that they might not have thought of – essentially encouraging people to explore the bounds of the game mechanics. Hopefully it worked.

The hardware shaders ended up turning into a huge code and efficiency problem, and I ended up spending a week before the game making them work, plus a week after the game making them work fast. Ugh. On top of that I’m still getting frequent crash reports. I’m not sure if this is thanks to the hardware shaders or what – I’ll have to instrument some codepaths better to figure out where this crash is coming from. It may simply be that a lot of people are trying to run this game on low-end graphics systems.

I also still don’t have OSX crash reports working.

I didn’t have time to play around with the game mechanics much further. I wanted to have things like “score doublers” that you could drop in, that would double any points gotten “through” that link. Didn’t happen. I had some ideas about ways to modify the board layout after placing pieces, or letting the player stash a piece. Didn’t happen. This game was a huge time crunch from beginning to end, and I’m glad I did it because I ended up with some great infrastructure in place, but the game design suffered.

The Bottom Line

I feel like I’ve made my prettiest and most atmospheric game yet. That’s cool. I feel like the game design itself was kind of a failure, and I’m pretty much just gonna be moving on to whatever’s next.

Which, lately, has been an iPhone port. Getting close to the point where I can (relatively) easily build iPhone games!

My word this one was tougher than I’d expected.

Windows (.zip version available)
Mac OSX (10.6 or higher)

Things I’ve learned: hexagons suck.

This game makes far heavier use of graphics card hardware than any I’ve done before. Report any problems! With luck, there won’t be any. Luck is not something I have had during the design of this game.

I’m tweaking the terms of my Monthly Game slightly. March is going to be insanely busy thanks to GDC and PAX, both of which I’ll be attending, so I might not get a game done in March. If I don’t, I’ll get two done in April.

Leave commentary on the game. As usual, I’ll be posting a postmortem in a week or so.

THE BAD:

The original goal for this game was to rip off the Drawing minigame in Kirby Canvas Curse, then play with it a lot to see if I could come up with neat variations.

Fundamentally, I couldn’t. Ironically I’ve gotten a lot of really good ideas since finishing it. SO IT GOES.

One problem I hadn’t anticipated, however, is the issue with the user’s control scheme. People who use trackpads didn’t generally like the game or do well. People who use tablets generally liked the game and did really well. Tablet users might be, in general, more artistic in the first place, but I think some of this is thanks to trackpads being really really awful for this game style.

I’m not sure what a solution to this is. I should maybe just have added a screen at the beginning saying “plug a mouse in you doofus”.

THE GOOD:

The game balance is more subtle than you’d expect. Scoring is done by taking the average distance-squared between each of your drawn points and the closest point to it on the pattern, then adding the reverse of that, from the pattern to your points. I quickly realized that the big simple patterns ended up vastly harder than the small ones due to how large errors tended to be. The solution was to send a beta copy to all my friends and get them to play through all the levels, then average their scores for each level and use that as a scaling factor.

The spiral ended up being the “toughest” in terms of scaling, while the rabbit crouching next to a bed was the “simplest”.

However, once I’d done this, it just worked. A was tough, A+ was very tough. User balance: it’s a good thing!

The background color. This seems like a silly small thing, but the game completely opened up when I added the background image and I was no longer making gameplay while floating in a sea of black. Every other game I’ve made has started with a black screen. I think I’m going to start with a non-black screen on the next one and see what happens.

This is going to sound silly, but I really feel like the big thing I got out of this game was the background color issue. I think that’s been a recurring issue in a lot of my games, and I’m going to fix it, starting now. And by “starting now” I mean “I already know what my next game is, and I’m going to start working on it real soon now, no more five-days-before-the-end-of-the-month for me!”

WHAT IT ALL COMES DOWN TO:

I’m getting better at this. I think I did a good job of the atmosphere in Andre Copperman, and the game ended up roughly how I intended. I didn’t come up with clever gameplay elements but I made a fun game and that’s what I was going for.

As a side note, can anyone with OSX 10.5 let me know if the build worked? I’ve gotten a bunch of reports of it working on 10.6, and exactly one report about 10.5 (didn’t work.) I don’t yet know if this was a fluke or some actual incompatibility.

Well, here we are again. This month’s theme is Art Game, and I’ve provided you with a game that is all about the process of making art.

And appropriately, this is the first game of mine that includes OSX support. We now have even more download options than we did before!

Windows
Mac OSX

Windows .zip for those who dislike installing things.

Let me know whether the OSX version works, and what version of OSX you’re running it on. It hasn’t been very extensively tested.

As usual, commentary coming in a few days.

Here we go again! Download installer here, or download ZIP version here.

The original Experimental Gameplay Project has started up again and I’ve decided to follow it. This month’s theme is “Bare Minimum”.

You may notice that the main character is a bear.

Get it? Get it?

Besides the obvious pun, I also applied the theme to the game mechanics themselves. Once again I’m mucking about with difficulty mechanics (I really need to stop this) and once again I’ve tried a new tactic (at least I’m making progress.)

At the beginning of the game you’re given the option to buy upgrades. Depending on how many upgrades you end the game with, you get a better ending – the goal is to finish the game with the bare minimum of upgrades. (On your bear. Get it?) I’ve explicitly said “hey here is your ending, here is how you go about getting a better one” in as many places as I could. In general, people seem to be figuring it out – at least, when they put any thought into the game. A few people seem to be taking the tactic of clicking wildly, ignoring the dialog, and them complaining that they didn’t get the game. I’m not sure there’s much I can do about this.

What Worked

I made a level editor before starting this game. Oh man. Made everything so much easier. As part of the level editor I also put together a UI framework, which also proved invaluable – I used it for pretty much all the non-game UI to get stuff done vastly faster than I otherwise would have.

I tried a new method of doing art – sketching on paper, scanning in, and tracing the lines, then doing fills from there. It worked a whole lot better. My paper art is crummy, but it’s not as awful as my non-paper art. I also ordered a small tablet, so we’ll see whether that works even better for next time. I deeply love the picture I came up with for the Ringmaster.

I do have a vague, unnerving feeling that Nanok and No Such Thing exist in the same universe. They just have a similar feeling. And I’m pretty sure the Ringmaster is a major figure in that universe. He may be revisited.

The game’s fun. I actually enjoy leaping around and shooting things. I’m not sure anyone besides me has beat it on the hardest mode, so, y’know, go and try it. Tell me how hard it is.

What Didn’t Work

I’m starting to push my knowledge of OpenGL rendering. That’s good, because I’m learning. That’s bad, because I spent probably a day or two just mucking with obscure OpenGL issues and trying to make it run acceptably fast.

While the new method of doing art does produce better and more interesting art, it’s also a lot slower. I’m not sure what the tradeoff here is. Part of me thinks I should have ground out some cheap art and then done something better late, but every minute I spend working on art that I eventually replace is a minute I’ve effectively wasted. Not ideal. Making a game that looks and plays appropriately is really important for analyzing the gameplay value, just because of how critical graphics are, but I feel like I’m missing the balance point rather badly.

I should have put a little more work into the editor. I got it ready for this project thinking “hmm, I also want a few more features, but I probably won’t need them immediately.” Natch, needed ‘em immediately. I spent some time working around them and some time implementing them – more things that cut into my limited time budget.

I’m not sure if I didn’t prioritize well, or if I just picked up something too ambitious, or if I just got screwed by SNAFU. For the first time, I was not able to make the game I wanted to. I wanted more detail in the world, I wanted more detail in the spaceship. I did not want the player to end up walking around in a world of purple blocks. That was not my goal. And yet, here we are – purple blocks. Ugh.

I still want parallax (seriously, goddamn, I wanted that *last* game) and I also want some basic music. I don’t even know where to start with the latter part.

The Bottom Line

With No Such Thing and Fluffytown I was a lot more focused than with Nanok. I need to regain that focus – when I’m making the game, the most important thing is to finish the game. Putzing around with tools and with new techniques is something that should be done before and after the week, not during the week. I fucked that up.

I’m spending way too much time with this single game mechanic and I need to go into something more interesting. I’ve got a few possible ideas for next game – I’ll see what the game theme for next month is, then see if that inspires anything.

On top of that I think I know enough to make a longer-form game now. It’s still going to be short, but it’ll be a little more thorough and a little more flavorful. Yes, it will be a sidescroller. Yes, I really like sidescrollers.

Nanok is fun, but it could have been better. Still, I’m eagerly awaiting people’s reactions.

And yes, this game does have some slight resemblance to Iji.

Alright, time for the postmortem.

The Technical Side

Qualified success.

I intentionally used a small loophole in the rules – I spent a few days beforehand building a capable platformer library named Scaffold. I’ve never actually written a platformer before, so I wanted to give myself a bit of leeway to fuck things up. This was probably a good idea, since without that I would have had to cut stuff that I wanted to put in. I don’t feel bad about this at all, since I’m going to be using the library for other games in the future (in fact I’m already working on some much-needed improvements and tweaks to it).

I spent about three days working on the game design – after the third day, the level fundamentally didn’t change. I spent about two days on the intro cutscene, ending cutscene, art, and sound, and one day rebuilding some of my libraries and tracking down an awful bug that was causing crashes. Turned out to be a library error with Luabind, with the only fix currently available on a mailing list. Sigh. So a total of five game-related days and one SNAFU-related day.

I keep pushing myself to do wackier and weirder stuff with Lua. I split the game code into two files and tried to make a good connection between the two. I’m pretty sure I failed on this, and that’s where the data leaks and slowdowns come from. Something to fix with Scaffold v2.

I’m abusing coroutines more and more as I go, and they just keep getting better. Coroutines are absolute gold. If you’re trying to do any kind of scripting or AI in a language without them, just stop now and find a language that has them. I’m serious here, I whipped out things in five minutes that would have taken an hour or two in C++. My code is grim and nasty, but shockingly maintainable and compact, so as far as I’m concerned the coding of this is a great success, at least on the Learning Experience front, which is why it’s kind of a qualified success for the actual game.

The Artistic Side

You may have noticed there’s just a little bit more custom art in this than in No Such Thing.

No Such Thing had a total of 23 images, totaling 177kb, with 159kb of this being the backgrounds. Fluffytown has 76 images, 226kb, 187kb being backgrounds of various sorts. Fluffytown also has those images divided roughly into 14 animations (No Such Thing’s only animation was the explosion) and contains 17 sound effects compared to NST’s four.

And yet, I spent about the same amount of time on art and sound. I’m getting better at this, clearly.

I botched the resolution a little bit. I’d meant to make it a 320×240 game, only I got confused sometime between making the hearts and the elephants, and I ended up making it 640×480. That was a mistake – in retrospect I think 640×480 is exactly the wrong resolution. At higher resolutions you can get away with solid colors and aliased shapes, at lower resolutions you can get away with more abstraction. 640×480 is this annoying little niche where you can’t do Iji-style art and you can’t do Spelunky-style art. I’m not going to make that mistake again.

I have a lot of trouble with shapes. I am just flat-out not good at doing shapes on a computer. As bad as I am with pencil and paper art – and I’m pretty damn bad – I can at least get shapes to do what I intend after a few tries, and I just can’t get that working on the computer. I’ve ordered a cheap scanner and I’ll be trying to do sketches, scanning them in, and tracing from there for my next project (assuming I do sprite art, I’m seriously considering just doing opengl effects for whatever comes next.)

All that said, I’m rather proud of the art. For someone who sucks at art it’s not bad at all.

I was hoping to include several parallax layers in this level, as I consider parallax to be one of those real easy things you can do with incredible results. My “level editor” was not up to the task, however (if you go to line 341 in main.lua you can see what I mean by a “level editor” – I recommend using a monospaced font with word wrapping off). Also, while my engine supports non-grid-aligned objects, my “level editor” fundamentally does not. I’ll be putting something better together for Scaffold v2. I want my parallax.

The Gameplay Side

Alright, here’s the interesting bit :)

The weirdest thing about this game is the fact that none of my testers figured out the gimmick. Not one. I was ready to write it off as a failure of a test, only once I posted it, a ton of people figured it out – some even before the end screen. I’m not quite sure what happened here. Maybe my testers, thanks to me being right there online waiting for a response, didn’t bother trying to look into it too deeply. Maybe the addition of more sound effects and more thorough graphics – which my testers didn’t have – made it immersive enough that people started noticing the details, and not just the gameplay. Or maybe my testers are just kinda dumb :v:

The gimmick is indeed the fact that it tracks exactly what you kill and leaves appropriate piles of bleeding coffins on the side of the screen once you end the game, as well as removing the corresponding happy living creatures.

After No Such Thing I found myself thinking a lot about gimmicks that somehow encourage the player to do something counterintuitive. In NST, you merely tried to avoid getting hit, but it was kind of bizarre because getting hit gave you a more awesome weapon. A lot of people just wanted a really big weapon, and so my encouragement of score just flat-out did not work for them.

In Fluffytown I was going for a much subtler incentive. I wanted to see if I could get people to challenge themselves without being explicitly told “hey you should go try this”. I also wanted to challenge myself – I tend to want to force the player to play the game “the right way”, and in Fluffytown . . . well, if you want to go on a homicidal rampage, that’s A-OK. Besides a lot of bloody coffins, the game will let you, and if you find the sight of a blood-soaked hill pleasing and enjoyable, more power to ya.

Overall, I think this actually worked quite well. Some people went back and tried to do it “the hard way”, some didn’t notice and just flat-out beat the game. I’m actually fine with this. At some point, you have to acknowledge that your players might not notice all the cute subtleties and jump through all your flaming hoops. Everyone seemed to have fun with the game – some people just extended their fun further than others.

That’s cool. I like that.

In terms of difficulty, I got a lot of comments that the game was pretty tough. Amusingly, these were invariably followed by “but I beat it anyway”. I think this means it was exactly the right toughness.

Summary

After some testing, I was pretty sure it was going to be an epic flop. After reading a bunch of comments, it wasn’t. Clearly I need to have more confidence in people. I think there’s a self-balancing aspect with obtuse plotlines – if the plot or the Ultimate Ending is obscure or difficult, the people who figure it out will really love it. (See: Cave Story.) By beating your player over the head with it like No Such Thing did, alright, everyone’s going to see it, but nobody’s going to care about it. Fluffytown got people emotionally invested.

Now I need to figure out what game to do next – I’ve got two ideas, both of which I’m pretty sure I’m not able to do justice to yet.