Mandible Games

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.

Here we go again! Experimental Game #2!

I'm not giving much commentary on this yet, since I need to get more responses unbiased by my comments. So: grab the game! Play it! Tell me everything you think.

Games, movies, and magic have one major thing in common – misdirection. Show people one thing, then indicate to them that they saw another, and usually they'll believe you. In magic, it's harder because they're trying to figure out what you're doing while you're doing it. In movies, it's easier because the person is really just going along for the ride. In games, it's really easy, because the player is being assaulted by zombies and doesn't have any attention to spare.

At least, they don't the first time they play the game.

The second time, they're probably paying a lot more attention to what's going on around them. The zombies attacking, yeah, sure, they're a problem – but we've dealt with them before. Let's look at the other things around us!

This is when they discover how careful the game is at showing you exactly what they want you to see, and keeping you from doing anything besides what you're supposed to.

Not supposed to go through a door yet? It's locked. Got a cutscene to watch? I can guarantee every door leaving that room is locked – even if you just came through it ten seconds earlier. You can walk through a door, have it lock behind you, and then have the very same door unlock the instant you're done with a cutscene or a movie. Happens all the time.

Sometimes they even force you to look in certain directions. Sometimes, this is to make you look at something you're supposed to see. Sometimes, this is to make you look away from something you're not supposed to see. In the first level, there's an exploding shuttle. I bet you remember seeing it explode, right? It was really cool? No! You didn't. Because you can't have. The camera is jerked away from it at the last second, and when you turn back to it, it's already exploded. You're carefully prevented from seeing the exact moment it explodes.

The reason for that, of course, is that animating something large exploding in a realistic manner is expensive and hard. It's easier to just not show it. And it works great . . . up until the person realizes what's going on and decides to try exploring the boundaries.

This is a common issue in games. There are a good number of games out there that pretend you're given choices, but actually prevent all choice. The Half-Life 2 series is a perfect example – the first time you play it feels like an exploration, but every time after that you realize, hey, wait, I'm not allowed to go anywhere else! That exploration feeling was a ripoff!

I should mention that this is not necessarily a bad thing. The fact is that most people will never start a second playthrough – in fact, many people won't even finish the first. It's arguably kind of silly to triple your budget by making content that 95% of your users will never even see. (It's also arguably not. I'll post an entry about this someday.) But it does mean that going through the game a second time is kind of like being invited backstage at a live performance, or having the magician explain his tricks – all those cute things you noticed the first time turn out to be your own fevered imagination running a bit too fast.

Solution? There isn't one, besides solving the hard AI problem and writing programs that can generate content for us. Unfortunately, this is a ways off, and if we ever do solve it, we've put ourselves out of a job.

All I can say is: be aware of it, and try hard to keep the player from feeling constrained. At least, on the first playthrough.

Traditional game animation is (mostly) pregenerated. An animator sits at a computer and carefully poses the motion of each limb. Eventually, you have a spider that crawls across the ceiling and shoots acid in your face. Done!

In motion, this looks pretty good. In death, it's problematic. First, unless you've gone to the trouble of multiple death animations, creatures always die the same way. If you kill five hundred Basic Guards, you'll end up with five hundred identically-posed corpses lying around. Uncool. Second, death animations have nothing to do with the weapon you kill them with. Poke them a thousand times with a needle? He'll scream, fall over, and lie with his face on the ground. Shoot him with a portable nuclear warhead launcher? He'll scream, fall over, and lie with his face on the ground. Uncool. Third, death animations tend to "snap" from other animations. Basic guard takes a flying leap, jumps at you, you kill him midair . . . and suddenly he plays the Death Animation, which involves him instantly standing up in midair, then screaming, falling over, and lying with his face on an imaginary ground, while his corpse eventually falls into a pit. Uncool.

There's a solution to this. Games have gotten sophisticated enough that most modern 3d games include a basic physics engine. You don't need perfect physics for this, something simple is pretty effective. Animations are already based on a simple skeletal model – arms have two "bones", legs also have two "bones", etc – and it's easy enough to allow these bones to just move via the laws of inertia and behave properly on impact.

So you kill someone on a tower of boxes, his corpse will tumble down the boxes. You shoot someone with an air cannon while he's standing in front of a railing, he'll backflip over the railing. Rocket launcher to the feet? Flying guard corpse! Cool.

There's problems. (Of course there's problems. You think I'd be writing about it if it really were that simple?)

Ragdolls tend to be used only for actual death. It's just too hard to recover from a ragdoll collapse if the creature isn't actually dead. You knock a Basic Guard into a pile of boxes and he gets jackknifed between two – how does your Basic Guard recover from this? He doesn't, but now there's a living Basic Guard jammed uncomfortably into a pile of boxes. It doesn't work well. So ragdolls are only used for death.

But that introduces a new, irritating problem. Ragdolls can be used to detect death. Dead Space includes a gun that fires a shockwave which knocks things down. When knocked down, a lot of the zombies will cheerfully play dead, only to eviscerate you when you turn your back on them. However, it's trivial to determine if they're dead or not. See, when you knock them down, they always fall on their backs, with their legs facing you, and their left leg (from your perspective) slightly lower than their right leg. I know this very well from knocking down dozens and dozens of zombies this way.

When I see them fall down this way, I know they're just going to get up again in a few seconds. When I see them fall down any other way, I know the ragdoll mechanic kicked in, therefore I know they're dead, and therefore I can forget about them.

It's not very suspenseful.

I'm not sure what the solution is. It really is incredibly hard to recover smoothly from a ragdoll-based collapse. On the other hand, unless you have your artists make dozens of death animations, it'll always be easy to distinguish a "real" ragdoll death from a "fake" non-ragdoll death.

But it's a problem, and in a game like Dead Space, where detecting Proper Death is a very valuable skill, it's distracting like you wouldn't believe.

LocoRoco: Cocoreccho

Developer: Sony

Completion level: Not even close

Spoilers: I'm not sure how this would be possible.

I just got a PS3.

What this means is that you may be bombarded with short dissections of short downloadable games. I might eventually make a post about the PS3 in general (summary: it's pretty dang awesome now and Microsoft's lunch is about to be eaten by Sony) but I may not.

The thing about small short games is that some of them are really really weird. Cocoreccho is an exception to this, mostly because I'm not entirely sure it's a game.

LocoRoco was originally a PSP game. You played the Earth, and tilted your surface to help a bunch of singing blobs defeat a small army of flying dreadlocked heads. I swear I am not making this up. If you think the gameplay sounds distinctive, the art style was even more so, consisting entirely of deformable solid-color 2d cutouts – on the PSP, no less, where most people were expecting gore and explosions. Add to that one of the most catchy and cheerful soundtracks I've heard in a long time (keep in mind your blobs sing along, with lipsynched animations, in chorus) and LocoRoco made Nintendo games look dull, stodgy, and moderately depressed.

It's a great game, and I highly recommend it. It's also a near-natural fit for the PS3's tilt sensor. All they had to do was port it over, add a bunch more levels, bam! Game!

What they actually made was, in the words of the lead developer, an "interactive screensaver".

You still have a large number of singing blobs (it wouldn't be a LocoRoco game without singing blobs) but instead of getting from one side of the linear level to another, you are instead exploring what can be best described as a humongous Thing. Its behavior will be familiar to anyone who's played the PSP game, as it includes spinny things, bouncy things, sloped things, things with holes, and every other joyous device that we're used to from the PSP game. Your goal is to move a magical butterfly around which attracts singing blobs, use that explore the Thing, find more singing blobs, and wake them up.

That's the game.

Unlike the PSP game, your little blobs have more autonomy than they did before. The Thing has several large "loops" of behavior in it, where the blobs will naturally wander down slops and jump into new areas with wind blowing them back up to the beginning, and your blobs will generally follow the loops on their own, meaning that even if you're not really paying attention they'll be wandering around the level without any help required. This is pretty dang neat – in many places you can just point the screen at a segment and let it sit while blobs fly through it. I'm pretty sure this is where the whole "interactive screensaver" part comes from.

Unfortunately, as a screensaver, it's a bit of a failure. You see, the screen itself doesn't move around. Wherever you leave it, that's what you're going to be looking at until you move it again. And while the blobs are largely self-motivating, the areas they travel through automatically aren't really particularly interesting. In order to make them do anything of interest, you have to not only control the butterfly manually, but you have to know where the interesting things are – making it impossible to just sit down and poke at it for a few minutes. Getting anywhere really interesting can easily take fifteen minutes to half an hour of work.

Which is a pity, because I think the idea of an interesting interactive screensaver that could be left on is a really cool one.

I'm going to diverge into philosophy here for a second. Games started as a thing that was Not Business. If you were using a computer for it, it was either Business or Games. It took quite a while for computers to be used seriously for any other sort of recreation (like reading blogs) and even then, it pretty much came down to Business, Games, or Communication.

We're finally moving into using computers for other things. Cocoreccho is something I would consider Art. It's clearly meant to be art, on some level. Unfortunately, it's art jammed into the mold of Game. The artistic things they could have done have been hampered by their desire to make something that should be both played and won. Which is, I have to say, sad. It could have been something More – but it isn't, and it won't be, because it's a game and it's proved unable to break out of the template of Game.

Cocoreccho is interesting. I'm not sure it's good. But it's interesting, and if what I've been talking about intrigues you, and you have a PS3, you might want to check it out.

Finally I've got the tank graphics done, or at least mostly done.

There's a lot of challenges and subtleties in these images that might not be obvious. Here's a list of things that you might not have noticed.

• The tank models are divided into tiers. As you go further down, the tanks both become more powerful and gain more vertices.
• The OTEK II has no variations. Most tank types have one variation, which is considered to be in the next tier. CARA II and SEKA I are in the same tier, for example. The highest-end tanks have two variations.
• A tank variation should be noticably different from the original tank, but still related. This is harder than it sounds.
• Tank abilities should be approximately clear from the graphic. Pointier sharper more aerodynamic tanks are faster. Wider bulkier tanks are better armored. Tanks with more pointy bits in the front tend to have better offensive capabilities, and tanks with complex detailed sides are more upgradable. There are other things to distinguish tanks, but most of them don't have to be worried about unless you're piloting it.
• Note that, in this layout, the leftmost tanks are the fastest and the rightmost tanks are the heaviest. In most cases the leftmost tank is also the flimsiest and the rightmost tank is the sturdiest, but there are some exceptions. TUVU is a sturdier tank than MARI, and the GUPE/BORA/HIMO line is backwards. (Yes, the GUPE is both a heavy tank and a fast tank. Relatively speaking, its weapons suck. The HIMO is exactly backwards.)
• I'm working the number 6 into gameplay in a lot of places. Every weapon has six increasing-power versions. There are six rounds between shop phases. I could argue that there are six tank variations in each chunk, but that would be a stretch. Note that there are 7 tank tiers. This is intentional. Still trying to figure out more places to put the number 6. Right now there are 5 damage types, but I want to keep that, so maybe I'll add a "typeless damage" series of weapons.

If there are tanks that you think look too similar, or suggestions, I'd love to hear them. But I'm mostly posting this because I think they look neat.

Also I'm pretty sure that none of them look like penises. It turns out that this is a recurring problem when you're trying to build war vehicles.