Log in

Zorba the Hutt's Journal

> recent entries
> calendar
> friends
> mandible games development journal
> profile
> previous 20 entries

Sunday, June 5th, 2011
2:06 pm
For a while I've been posting entries from my dev journal, Mandible Games, in here as well. I made some setting changes to my blog and that ended up wiping out the LJ crosspost feature.

Fact is, I don't get much traffic through this journal anymore. I think we all know Livejournal is on its way out. So I'm not going to put any effort into fixing it.

If you'd like to keep reading the dev journal through LJ, subscribe to mandible_games and everything will keep plugging along as usual.

(1 contented zombie | braaaaaaaaains)

Monday, April 25th, 2011
4:47 pm - Roguelikes: The Misnamed Genre

Recently, I’ve been playing a game called Dungeon Crawl: Stone Soup. You should play it. It’s good.

DCSS is a game about searching a dungeon for a magical McGuffin named The Orb of Zot. You choose a species and a background, get starter gear, and delve into the furthest depths of the unmapped, unexplored, randomly generated, extremely dangerous dungeon complex. There are about a dozen major areas in the world, including The Hive, The Shoals, The Abyss, and Hell itself, plus a large number of minor areas like the Ecumenical Temple and Erinya’s Garden, many of which may or may not even exist. Along the way you’ll find magical armor, scrolls, wands, and potions, none of which are identified. Putting on an unidentified ring could result in the discovery of a +5 Ring of Slaying (really goddamn good), it could result in “well, now you’re wearing a ring, and you still don’t know what it does”, or it could result in discovering you’ve just donned a Cursed Ring of Hunger and you’re about to starve to death if you can’t get rid of it immediately.

Death, in DCSS, is a major event. When you die, that’s it. You’re done. That character is deleted. There are no save points, there is no reloading. Want to run full speed through the Hall of Blades just to find out what happens? What happens is that you get chopped to bits by the magical weapons filling the Hall of Blades and now you have to start over.

DCSS isn’t a unique game. It is, however, possibly the most modern example of its genre, known as Roguelikes. The original game Rogue was released way back in 1980, sporting a text-based interface, randomized items, a randomized dungeon, and permadeath. Rogue inspired a similar game called Hack, which, itself, inspired a game called Nethack, a game notable enough that it occasionally displaces Rogue as the name of the genre. A few years later Angband was developed, then Linley’s Dungeon Crawl, which was abandoned and eventually resurrected as Dungeon Crawl: Stone Soup . . . sporting a text-based interface, randomized items, a randomized dungeon, and permadeath.

Those are the big names, at least. The Roguelike genre is very conducive to small projects. Its text-based “graphics” mean that any game developer can write up a little Roguelike of their very own, and the code behind Roguelikes tend to be simple to start with, albeit complicated to continue. There are easily a dozen major Roguelikes still in production, with dozens or perhaps hundreds that have been abandoned over the years. They all follow approximately the same formula: you choose a species and a background, you enter a randomly-generated dungeon with text-based art, you travel deep into the earth, using random unidentified magical items to survive until you find a magical relic which you cart back up to the surface and you win.

Except . . . they don’t all follow that formula. They almost do. But not quite.

DCSS, for example, has a graphical mode. Not the prettiest graphics in the world. But it’s graphics. So that kind of breaks the formula. And while it’s not mandatory to use, DCSS has a Tower Defense mode known as Zot Defense, and a canned hand-made dungeon mode known as Dungeon Sprint. Which aren’t really Roguelikes, because they’re not about finding that magical relic in a randomly generated dungeon. But they sort of are, because they use all the same items and monsters and behaviors.

There’s also Desktop Dungeons, which breaks the formula further. Most Roguelikes take many hours to beat, even if you know what you’re doing. Desktop Dungeons takes about fifteen minutes per run. And it’s got graphics – in fact, it has mandatory graphics. And sound. And there’s no such thing as a cursed or unidentified item. But it’s still a Roguelike. Sort of.

And there’s Dwarf Fortress, which . . . well, it’s got ASCII art. And randomly generated levels. That’s all normal. But instead of controlling an adventurer, you control an entire town of dwarves, mining out a civilization into a cliff side or a convenient hill (or the frozen tundra, if you’re looking for a challenge). And you’re not trying to find a magical artifact. You’re just trying to survive. Or maybe you’re trying to make the world’s largest elephant combat pit. Or maybe you’re trying to build a digital computer out of pipes and gears and dwarves. It’s not really a Roguelike. But it’s within a stone’s throw.

100 Rogues is an iPhone game, graphics and all. ADOM has a world map and multiple dungeons. Spelunky is a sidescroller action game. Toejam and Earl is about a pair of aliens repairing a crash-landed spaceship in order to go back home. There are so many exceptions, so many alternatives, so many branches, so many cases where people can’t decide if a game is a roguelike or not, that I can only come to one conclusion:

The term “Roguelike” is not a well-defined term.

We’ve been trying to define “Roguelikes” based on what the game includes. Deep dungeons, random levels, cursed artifacts. But non-game genres aren’t define that way. Imagine trying to divvy up movie genres based on their components. This movie has a car, so it must be a car movie. No, but wait, it has guns also! It must be a guns movie! No, actually, it’s “The Godfather”, and it’s a drama movie. Or maybe it’s a crime movie, or a thriller, or even a Mafia movie. But it contains cars and guns, and it’s about drama and the Mafia.

Roguelikes aren’t about dungeons. They’re not about text-based graphics, or random artifacts, or permadeath.

Roguelikes are about complexity.

Roguelikes are about handing you a set of pieces. Roguelikes say, hey, these simple parts, when put together in this fashion, will have this obvious effect. And then they hand you more pieces, and you get to figure out the best way to combine those pieces.

Roguelikes are about using an unpredictable toolkit with complex interactions in order to overcome unpredictable challenges.

For example, there’s an item in DCSS known as the Scroll of Immolation. When you read it, it blows up in your hands. Sounds kind of crappy, right? Now let’s imagine you’re wearing a bunch of fire resist gear, and you’re in the Ice Dungeon, and you’re being swarmed by a bunch of small ice critters. Read scroll, scroll blows up, you’re immune, monsters aren’t. Of course, this isn’t the kind of thing you can plan for. You might not have that scroll. Chances are good you won’t have a bunch of fire resist gear in the Ice Cave. And you’re more likely to be attacked by a few big monsters than swarmed by small monsters. So what I’ve just described is not likely to be useful.

But DCSS contains dozens, if not hundreds, if not thousands of tricks you can use, and in any serious game you’ll be close to death many times. If you can’t find a good trick to survive, you’ll die. The way to beat a Roguelike isn’t to memorize all the tricks, it’s to learn how to come up with ideas on the fly.

In Dwarf Fortress, your game will depend partially on what natural resources are available, and in what quantities. You can’t always determine this early on in the game. You might reach the mid-game and run out of iron. Whoops. Time to find more iron, or learn to do without. In Desktop Dungeons, you never know quite which monsters you’ll run into, which deities will be available, which spells and items you can get ahold of. These aren’t traditional Roguelike games, but the core mechanic, the critical part that makes them feel Roguelikey, is preserved perfectly.

Once we acknowledge this potential new definition of Roguelikes, we start seeing it crop up in surprising places. Civilization 5 has a military that relies on finding certain important resources in order to build the best units. If you’re lucky enough to find a lot of them, you might change your strategy to lean towards military conquest. If you find few of them, you might take a more defensive position, or use units that don’t require iron or horses. Dominions 3, an excellent but obscure multiplayer turn-based strategy, is thoroughly laced with this – finding an important magical site, or a powerful recruitable independent mage, can change your entire long-term strategy if you’re clever enough to recognize it. And here’s the most unlikely comparison you’ll hear in a while – Super Smash Bros Brawl multiplayer is like a Roguelike! A lot of the multiplayer strategy is seeing special items quickly and coming up with a good way to use them, or seeing what’s being used against you and learning how to counter it. Compare a SSBB Pokeball and an unidentified Nethack potion or scroll. Unpredictable toolkit, unpredictable challenges.

And of course, Nieuwe Aarde, the game I’ve been putting more work into, is intended to be a Roguelike by this definition. I’ve been putting a ton of thought into how to make it more Roguelikeish – right now it frankly does a very bad job of being a Roguelike – and I think I have good ideas. Once I have the time, you’ll be seeing more on this front.

There’s only one problem. The word “Roguelike” is already taken. And the people who make Roguelikes would probably be a bit peeved by my claim that Super Smash Bros Brawl is a Roguelike. And worst of all, Rogue itself only has this property to a limited extent – there aren’t many items, there aren’t many abilities, there aren’t multiple races or multiple character classes. So I think it’s time to coin a new term . . . but I’ve had no luck coming up with a good term. My best option so far is “Highly Emergent Games”, which sounds like a phrase you’d hear coming out of Zynga. Not ideal.

________ are about using an unpredictable toolkit with complex interactions in order to overcome unpredictable challenges.

I’ve defined a new genre of game. What do you think it should be called?

Friday, March 25th, 2011
3:05 pm - The Origin of a New Game

I’ve got another megapost percolating, but I saw something from Warren Ellis and had to quote it:

Sometimes it works like this. You can’t choose what part of a story comes to you first. Sometimes you think of a setting first. Sometimes an interesting plot progression drops into your head and you find yourself looking for somewhere to put it, instead. Sometimes it’s the title first, or a character name, or even a line of dialogue from nowhere that kickstarts the whole thing. There’s no hard and fast method, no laws about how this works. Every job is different.

Quite, quite true. You get inspiration where it shows up and you don’t complain about it.

Monday, March 7th, 2011
1:22 pm - Nieuwe Aarde 0.1.1

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

“Wait, Nieuwe Aarde? What’s going on? Didn’t we already see this game?”

Well, yeah. You did. And you’ll be seeing more of it, too!

I’ve decided to turn Nieuwe Aarde, along with one other game yet to be announced, into a longer-term project. I’ve got ideas on how to improve it considerably. This isn’t really an improved version – this is just a re-release of the version you’ve played before – but it does have a few improvements.

First off, and most noticably, it has music! I’ve been collaborating with Robert Seaton with music for a few of my games (and I’ll be posting them with music as well, though they won’t be getting a long-term treatment.) We did a really neat thing with the music in this game. I’m not going to spoil it, but you should go play it to find out. Seriously it’s pretty dang cool.

Second, a common complaint was that increasing your metal and magic in the lategame took far too long. I’ve added +1000/-1000 buttons as a small hack fix for that.

Third, the rendering engine is far more efficient – the original renderer was quite shockingly bad. Sometimes that’s just what happens when you have 48 hours to write a game in. I regret nothing.

Overall, this is the same game . . . but keep an eye on this journal, because I’m going to be making some major changes to it.

Monday, February 28th, 2011
11:17 pm - Art That Stands The Test Of Time

I just spent a lot of paragraphs talking about Super Meat Boy’s artistic choices. Mostly, I talked about what made it a good facsimile of a classic console game while still, in a technical sense, being completely unlike a classic console game.

I didn’t talk about what made it good. More importantly, I didn’t talk about what “good” means.

From a big-business point of view, “good” is what sells games. That’s cool. It’s a rational choice. But it’s not my choice.

From my point of view, “good” is what makes for good games. And by “good games”, I mean “games that people enjoy, and games that people will continue to play well after release”. The gaming landscape is littered with games that made a splash, but a stifled one – games that sunk unnoticed after their initial burst of sales. The indie market can’t afford to do this. Indie marketing is a slow, gradual beast, and indie developers live or die on their long tail of sales.

That means when you’re releasing an indie game, you have to release something that will still be fun a year from now. Two years from now. Five years from now. I can guarantee people will still be buying Braid in five years. I can guarantee people will still be buying Super Meat Boy in five years. And the way you get people to do that – at least, in terms of art – is to make art that lasts.

X-COM UFO Defense. This game’s almost old enough to vote – seventeen years and counting. The graphics, by modern standards, are best described as chunky – this was back in the days when we were oh so excited about being able to display 256 colors on a screen at the same time, please ignore that we were restricted to a 320×200 resolution. But despite the chunkiness, they’re good. You can see what’s going on, the art doesn’t induce pain, you get a sense of the world’s style. The graphics may be old, but they’re competently done and pleasant to look at.

Hold on to your hats, because we’ve got a shitload of screenshots coming up, all from around the same time period.

Space Quest 5 was one of the best adventure games of its time. Lavish hand-painted images, gorgeous worlds. Tyrian: a vertical shooter from Epic Megagames. It shipped with half a dozen detail levels, the highest of which would slow even the best computers down to a crawl. Jazz Jackrabbit was a successful attempt to bring the platformer genre over to the PC, merging the speed of Sonic the Hedgehog with the firepower of Doom. Master Of Orion 2 is an old 2d turn-based strategy game, setting you in command of an alien race to conquer the galaxy.

The PC wasn’t the only platform with good, solid artwork. The Super Nintendo had its share as well. SNES cartridges were capable of storing up to four megabytes of data (six megabytes, if you pushed real hard) and their developers used this to its full extent. Super Metroid: still possibly the best game in its genre, it provided a gorgeous view into a strange alien planet. Chrono Trigger, a classic RPG, showed us the kind of variety an RPG could give us in graphics. I won’t give away the plot twist in Final Fantasy 6, but suffice to say it was fantastically done, and – while it wasn’t an SNES game – any discussion of gorgeous pixel art would be incomplete without Metal Slug. Which, if you can believe it, looks substantially better in motion.

All of these games have good graphics. I’m not saying they had good graphics for their time. I’m saying, even today, you can imagine sitting down and playing them. They look better than most modern Flash games.

(And you should play them, by the way. They’re all really good. I’m not picking bad games here.)

And some games did not fare as well.

Alone In The Dark: A game that practically created the survival horror game genre. Final Fantasy 7: One of the most beloved RPGs of all time, even more so than Final Fantasy 6. Half-Life: The game that started a modern development behemoth, and one of the highest-rated games ever. Marathon: A relatively unknown first-person shooter that later spawned a somewhat better-known series called Halo. Starfox: The first 3d game on the Super Nintendo, creating an entire still-popular franchise of its own and firmly pushing consoles into the 3d world. And finally, Doom, which may well be the single most influential video game in history.

These are all considered great games. Some of them – perhaps even most of them – were even more groundbreaking and amazing than the games I’ve listed before. Most of them were released around the same time or later – the 2d games max out at 1995, the 3d games go all the way up to 1999.

But look at them. Seriously. They look like crap. The textures are low-resolution, either chunky or blurry. The models are blocky in the best of cases, and downright polygonal in the worst . . . and that’s for the games that weren’t using flat resized sprites. It feels like sacrilege saying that Doom is a game that looks bad, but, let’s face it, by modern standards, X-COM looks good and Doom looks bad, even though fifteen years ago Doom is the game we were raving about.

All these games were released at roughly the same time, from 1993 for Alone In The Dark to 1998 for Half-Life. The earlier 2d games date 1995 or earlier. But all the 3d games look terrible, and all the 2d games look great. So what gives?

I didn’t pick this time period arbitrarily. The mid-90′s were the birth of the 3d gaming movement. Before that, we just didn’t have the CPU horsepower to do 3d in any useful manner (yes yes, 3d Monster Maze and Catacomb, but I’m not even going to bother posting those). The instant we got 3d capabilities, people started making 3d games. They were new. They were amazing. And we simply didn’t have the technology to make them look good.

Today, of course, 3d games are absolutely gorgeous. Photorealistic. Better than photorealistic, in fact. This is a line we’ve only reached recently, in the last few years. Logically, if we’ve only reached photorealism recently, that implies that 3d games have only just started looking good, yes?

And if you look back just a little, you’ll find evidence corroborating this. Halo looked great on release, questionable now. Unreal Tournament 2004 is still a truly enjoyable shooter, but it’s quite clearly dated. Serious Sam didn’t look all that impressive when it was released, and it certainly hasn’t improved. And Doom 3, hailed as a revolutionary graphics advance, is showing its age – blocky, not particularly atmospheric, and old looking. Better than Doom 2. Nowhere near Crysis 2.

And that means that no 3d game, before the present day, will stand up graphically. Right?

Well . . . no.

Not at all, actually.

Okami was released in 2006, but don’t let the date fool you – it was one of the last games released on the rapidly aging Playstation 2, well after the release of the XBox 360. Its graphics come not from heavy hardware use, nor from a huge investment of money, but from style. Okami is a beautiful game.

Okami is not unique.

ICO and Shadow of the Colossus, two gorgeous games by the same developers. Shadow of the Colossus is a 2005 release, around the time of Quake 4. Ico was a 2001 release, back in the days of Halo. You can certainly see the lack of good technical backing to Ico, but it doesn’t matter. The atmosphere of the game is clear, and the gorgeous art stands out today.

All of these games share something. They share a coherent visual style, one that could be accomplished with the technology of the day. And I do mean accomplished, not approximated. If you made Okami today, it would still look like Okami. If you made ICO today, it would still look like ICO. But if you made Half-Life today, it would look like . . . well, it would look like Half-Life 2 Episode 3. Not like Half-Life.

Today, hardware is no longer the issue. We have the hardware to do amazing things, as the above screenshot of Crysis 2 demonstrates. The issue today is money, and this is something that indie developers need to deal with regularly.

The genius of Super Meat Boy’s art isn’t just that the art is good. It’s that the art is inexpensive. I have a hard time imagining that the game cost vastly more than Braid, and Jonathan Blow has estimated that Braid cost $200,000. The credits of Halo indicates that there were at least fifty full-time employees involved there, possibly more, and even calculating it conservatively, $200,000 isn’t enough for half a month’s salary for that many people.

Today, Halo doesn’t look good, and Super Meat Boy does.

The trick for modern indie games is to come up with art styles that are beautiful for what they are. We have the horsepower to do whatever we want, but we don’t have the manpower. Luckily, this is nowhere near impossible.

And Yet It Moves: A gravity-based sidescroller, with an art style based around photographs on torn paper. I can’t even imagine how cheap the art for this game was, and it forms a visual style that is still nearly unique.

Darwinia: Vector-based realtime strategy game. Us coders love our simple geometric designs with hardware tricks to make it pretty – they’re cheap to do and very, very effective, if perhaps a bit cliche.

Gemini Rue: Classic Sierra-style adventure. Is it handpainted? I don’t know, but it may as well be. This is a game that would fit in perfectly next to Space Quest 5.

Shatter: I did say we loved our geometric designs! Modern hardware is fast, and with the right backing behind it, that speed can be turned into prettiness without a lot of money. Particles and rendering effects are easy on the wallet and easy on the eyes.

machinarium: When you don’t want to do the coding tricks, you can just do 2d handpainted art. And when you’re handpainting, why bother with realism? Photorealism is a dead end for the indie developer – it’s too hard to get right, and you can fall into the Uncanny Valley without even trying. Graphical style is a much better idea.

The Witness: Light and shadows are one of an indie developer’s best tools, and we already visited that in Super Meat Boy. They’re computationally expensive, but simple to code, and shockingly beautiful. The Witness is making great use of them, putting more coding muscle behind lighting than many AAA games do.

Design your art so that you can do it competently. It doesn’t matter how technologically advanced it is. It doesn’t matter how many buzzwords you can fit in. It doesn’t matter whether it uses 20% or 90% of someone’s graphics card.

What matters is that you know what the goal of your art is, and you choose a goal that you can accomplish.

Ten years from now, nobody will remember the games that pushed the cutting-edge of technology. Nobody will remember the games whose main selling point was how much it would overload your graphics card. The games people will remember are the games that still look good in 2020, the games that still play well even then. And those are the games people will keep buying.

Saturday, January 22nd, 2011
5:12 pm - Super Meat Boy Dissection: Doing 8-bit with 64 bits

Been awhile since we’ve had one of these, eh? Let’s get some images, too. Images that aren’t screencaps of my own games.

Oh man that’s so much better.

Super Meat Boy is a truly fantastic indie platformer that came out a few months ago. It’s available here, though if you haven’t played it by now, it may not be your cup of tea.

You see, Super Meat Boy is hard. Hair-tearingly soul-crushingly ridiculously hard. It is one of the harder games that’s come out in the last decade or so. What happened a decade ago? We learned that games should probably be possible.

It might not seem like we had to learn that, but, trust me, we did. For a long period of time, games weren’t meant to be possible, they were meant to eat your quarters forever. The more quarters you could convince someone to feed into your arcade machine, the more money you made. This culminated with a rather notorious boss in the Dungeons and Dragons arcade machine that would literally take no damage until you’d put in twenty quarters. That’s right: you have to pay five bucks to start killing the boss. Eventually games moved on to consoles and computers, and people stopped having to feed quarters in, and eventually we realized, hey, why not make games have an end? Then it turned out that if you spent a lot of money putting an ending in your game, maybe it was a good idea to, like, let people see it, and so games got a lot easier in the space of a few years.

Some people miss that.

Team Meat missed that.

So they made Super Meat Boy.

Super Meat Boy is a throwback in a lot of ways. First, in terms of its difficulty. But most obviously, its art style. It could be described as “relentlessly retro” – the game is firmly grid-based, the pixels are large and chunky, everything about it says “this is a retro game”.

And some parts scream retro. Limited palettes, small assortments of tiles, even less bending of the grid formula. There’s slopes in the previous two pictures. There’s no slopes here. We don’t need slopes. We’ve got blocks.

What I find most fascinating about Super Meat Boy’s art is that it’s far, far, far more complex than anything you could do on . . . say . . . a Super Nintendo. Deceptively so. Super Meat Boy’s art isn’t 16-bit art. It’s modern, hardware-accelerated DirectX graphics . . . carefully crafted to be strongly reminiscent of old game consoles, while not actually being old game console art. And curiously, it takes on several “16-bit conventions” that didn’t actually exist back in the 16-bit world.

Take a look at an actual 16-bit game, Super Mario World. (In the series Super Mario Brothers. You may notice that Super Meat Boy has the same initials. I would be shocked if this were a coincidence.) Look at what’s going on this screeenshot: rounded corners everywhere. The platforms have rounded edges, the blocks are rounded squares. None of that translates into the actual game physics – every ledge behaves like it’s a sharp 90 degree angle, the rounding is just there to give it some fancy looks. The floor, and the platforms, have some art going on to give them a little more depth. The background has coloring designed to fake you into thinking it has a lot of depth. Bushes in “front” are darker, bushes in “back” are lighter, and it’s all fluffy to make it hard to recognize the tile boundaries.

Two more: Donkey Kong Country and Tales of Phantasia. Look at DKC, first. See just how impenetrable the actual level layout is. There’s all kinds of crazy fake-perspective and cleverness going on here – you can’t even see the underlying grid. This game makes great use of parallax – as you run, the backgrounds scroll at a different rate, to give an impression of depth.

Tales of Phantasia doesn’t do as good a job of hiding the grid, but look at how many tricks they’re using to make it still look great. Fake 3d, shadows, objects that don’t conform to the grid quite like you’d expect. The grid still exists, but the collision layer doesn’t conform directly to it – the collision layer is more complex so they can make rough edges. The grid is still there, they just try to hide it. It’s all smoke and mirrors.

Super Meat Boy dispenses with the smoke and mirrors. Platforms have hard edges. There’s no fake lighting effects on the platforms themselves, just splashes of red where you walked (Super Meat Boy is a boy who has no skin, and as such, he leaves blood everywhere.) There’s often multiple layers of background, as you can see in the first image, but there is a hard divide between the “background layers” on the same plane as Super Meat Boy and the background layers deep, deep behind him. The same-plane background scrolls at the same rate as Super Meat Boy does. The deep background layers are much, much, much slower, giving an illusion of depth with no risk of confusion.

The real 16-bit games did everything they could to escape their 16-bit nature. They pulled every graphical trick and programming trick they could. The modern “16-bit” games revel in it. The sharp corners are emphasized instead of hidden. The backgrounds are set apart from the foregrounds.

It’s not about immersion, because if they wanted immersion, they wouldn’t be making a 16-bit game. It’s about a feel and a concept.

The funny part is when they start using techniques that the “16-bit” games couldn’t use in the first place.

1: Take a look at the left side of that pipe. You see the tricky thing?

It’s rotated.

The Super Nintendo couldn’t do that. The Nintendo absolutely couldn’t. Easy use of rotation only showed up as of the PSX era, deep into the realism push.

(Okay, the Super Nintendo sort of could, but only one layer out of its 4. It certainly couldn’t rotate multiple things independently unless you had a cartridge with special rendering hardware, like Starfox or Yoshi’s Island.)

2: The contrast is a little tricky here, but this comes from the third screenshot up above. It’s the same deal as #1: rotated clouds. These clouds zip around the level wildly while you’re playing. That’s not a 16-bit effect, that’s a modern hardware accelerator. Can’t fool me!

3: Super Meat Boy has some really wonderful lighting effects. In this case, the pit below Meat Boy is emitting light, which is pouring up through the hole and illuminating everything. Again, this is the kind of thing that the classic consoles just couldn’t do. Light compositing takes some moderately hefty hardware, and transparencies only showed up in the Super Nintendo era. In this case it’s actually even worse than you’d think. The crumbly-looking blocks that Meat Boy is gripping will actually disintegrate after a second or two of being touched, and the lighting effects adjust instantly. That sort of complex lighting is well out of reach of 16-bit consoles, but because it can be easily applied to “16-bit” worlds, and because it looks really quite awesome, it’s common in games like this. See Gish for more examples of this lighting style.

(Also not a coincidence – Gish and Super Meat Boy share a substantial portion of their development staff.)

4: You never see old games intentionally making the world blockier than necessary. They do everything they can to make it less blocky. But take a look at this lava – it’s obviously and intentionally chunkier than the rest of the level. Big pixels, about twice as large as the pixels on the solid objects, and they’re not even grid-aligned. That’s not done for the sake of the hardware. That’s a pure stylistic choice.

But if you want a really ridiculous example . . .

5: These pixels aren’t even square! Look at them! They’re ridiculously tall! And I don’t even know what’s going on with the pixel sizing. On the edge there’s tiny, tiny pixels. In the middle there’s big chunky pixels. In the fire, there’s pixels of all shapes and sizes, glomped together into a flame effect that looks distinctly old-school while having absolutely nothing in common with old-school platform limitations.

The fact that it’s sitting on top of a beautiful and completely non-SNES 45 degree angle is just the crowning touch.

Next time you’re playing a fake classic game, look at all the tricks they’re using to show you how old the game is meant to look. Next time you’re playing a real classic game, look at all the tricks they’re using to pretend the game has more detail and beauty than it actually does.

This was meant to be one entry. “Oh, but Zorba, it is one entry!” No it’s not. You just haven’t seen the second part yet. This will be continued.

Tuesday, December 21st, 2010
9:57 pm - Insanely, Ridiculously Busy

I’ve come up with like four posts I want to make. Half of them are far too short, half of them are far too long.

You’re getting “too short” here. Suffice to say that things are churning along, in many different directions, I’m unbelievably busy, and it’s all going well.

We’ll resume our regular programming eventually. For now, bear with me.

Wednesday, November 17th, 2010
12:51 am - Your Shopping Adventure! Postmortem

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.

Sunday, October 31st, 2010
11:36 pm - Your Shopping Adventure!

Windows (.zip version available)
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.

Monday, October 4th, 2010
9:26 pm

(2 contented zombies | braaaaaaaaains)

Tuesday, September 28th, 2010
2:23 pm - Ramsgate

Windows (.zip version available)
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!

Tuesday, September 14th, 2010
1:03 pm - Chassis Commander Postmortem

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.

Wednesday, August 25th, 2010
1:36 pm - Chassis Commander

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


Marooned on an unknown planet!


His only weapon, a hoverbike with a malfunctioning weapon!


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?!


Play it today!

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

Tuesday, August 24th, 2010
12:33 am - Seattle Ho!
Heading down to Seattle again for my yearly PAX trip. I'll be there approximately one week before and one week after the end of this month, driving up from SF as usual. Let me know if you want to meet up!

I mean unless you're someone I'm expecting to meet up with anyway obviously, then you don't really need to post.


Tuesday, August 10th, 2010
5:23 pm - The Ultimate Race Postmortem

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.

Saturday, July 31st, 2010
12:04 pm - The Ultimate Race

Windows (.zip version available)
(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!

Friday, July 2nd, 2010
4:00 pm - twitter snippets
  • Sign of a good game: you regularly keep playing until it crashes. #
  • Sign of a bad game: you still end up stopping play sessions frequently. #
(Got questions? I read replies! Discussed entries may be turned into full-fledged journal posts, so ask away.)

(2 contented zombies | braaaaaaaaains)

Thursday, July 1st, 2010
4:01 pm - twitter snippets
  • Found a weird semantics glitch in my game engine. Fixed it, but somehow this caused a massive framerate drop. Confusing. #
  • Went to track down the massive framerate drop. Found a potential problem, which somewhat fixed the issue, but not entirely. #
  • Eventually realized that fixing the semantics glitch had actually fixed a previous bug I'd had. That's good right? #
  • But I'd already accidentally worked around that bug, and my workaround was now causing me to render the *entire screen twice*. #
(Got questions? I read replies! Discussed entries may be turned into full-fl
edged journal posts, so ask away.)

(3 contented zombies | braaaaaaaaains)

Monday, June 28th, 2010
4:02 pm - twitter snippets
  • My life is this rotating sphere of constant busyness. There's always *something* waiting for me to work on. #
  • Game idea: "The Credible Machine". #
  • It's pretty complicated. But, you know. Not really *that* complicated. #
(Got questions? I read replies! Discussed entries may be turned into full-fledged journal posts, so ask away.)


Monday, June 14th, 2010
2:51 am - GT Paradise, And Postmortem

Well that didn’t work.

Windows (.zip version available)
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.

> previous 20 entries
> top of page