Here it is. Experimental Game #1.

(Download for Windows)

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

It all comes down to my mom.

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

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

No Such Thing is impossible to lose.

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

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

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

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

What Worked

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

So the idea seems to be a success.

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

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

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

What Didn’t Work

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

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

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

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

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

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

Let me know what you thought of this one.

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

Usually, it isn’t.

Sometimes, it is.

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

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

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

That’s the plan.

Let’s see how it works out.

• Bad game mechanic: Process of elimination. Worse game mechanic: Process of elimination with mandatory cutscenes and finicky controls. #
• Also, I've seen adventure game heroes put inventory in all manner of unlikely places, but Wallace seems to jam everything in his armpit. #

• Universe design: Where does the leader lead from? A castle? A hut? There's a WoW character who leads from an inn. What does that say? #

• People don't want to drive to stores. Steam lets you buy full games without the pesky store. Everything should be on Steam. Everything. #

• 23:25 Resource management in ChronoTrigger: Swap party member out, cure everyone, swap back in. This sucks. Make it automatic or make it not work. #

How should Zorba integrate Twitter and LJ?

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.

Dead Space takes place on board the the USG Ishimura, a colossal “Planet Cracker”-class mining ship. It’s a ship designed to literally rip apart planets to feast on the tasty, tasty ore inside. The ship’s architecture varies from tight constricted maintenance corridors to huge open industrial spaces. At various points you visit the hydroponics bay, personal quarters, the medical bay, the bridge, and pretty much the entire set of possible important ship locations.

Most of the places you travel make sense in context of the ship’s purpose. There’s equipment suitable for its purpose, the layout is at least plausible, the lighting looks like it would be acceptable before zombies smashed up the place, etc. Some of the places do not make such sense. The ship is weirdly infested with inexplicable circuitous corridors. There are industrial areas that can best be described as mazes of walls. Why is there a maze in this ship? Did the crewmen just want a maze in their ship? There are strangely-placed high-speed trams that lead from one near-dead-end to another (the asteroid cannon being the most notable WTF moment). Why isn’t, you know, there just a door which is closer? Are you seriously saying there aren’t any other corridors within a kilometer? Overall, a good chunk of the ship just plain doesn’t make sense.

Now, if the ship were designed by zombies – yeah, sure, go for it, zombies are crazy, who knows how they’d design it. But they aren’t. It was designed by people. And when you’re told that you’re walking throughout a human-designed spaceship, and 3/4 of the ship makes perfect logical sense, those moments when you find yourself thinking “wait, why does this area even exist?” are painfully jarring. Why does this maze exist? Well, it exists because the game plans called for a maze, and by gum, we’re putting a maze in!

What’s the fix?

The only fix I can think of is to be excruciatingly careful that each location makes perfect sense, both for the game and in the context of the universe. It’s hard, it’s really hard, but I think it’s important. This isn’t an issue that’s restricted to games – it’s something movies get constantly wrong as well (please, explain to me why the Emperor’s chamber on board the Death Star has a hole leading directly to the reactor core without even a guard rail) – but that’s not an excuse, it just means we get more people to laugh at when we finally get good enough to avoid it.

For each zone, for each object in the game, you have to answer two questions. Why does the game contain this? Why does the world contain this?

If you can’t come up with good answers to both questions, get rid of it.

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.

Dead Space is a fantastic, fantastic game.

Dead Space is a third-person science-fiction horror game. Your character exists. A large spaceship exists. A shitton of zombies exist. Mix and enjoy. Technically, other humans exist as well, but in terms of gameplay they’re really only there for cutscenes.

There is you, and the ship, and zombies, with the zombies attacking you when you do not expect it and scaring the crap out of you. This is not Doom-style “a closet opens in the wall and a monster pops out, and you kill it, and you grab the health pack in the closet, and a second, smaller closet opens up and another monster pops out”. This is “you hear a squeaking down the hallway and moving shadows, and you inch around the corner and finally see a bloody corpse hanging from its neck through a vent shaft, and then you turn around and something tries to claw off your face before vanishing through a hole in the floor. Also, there’s clanging noises and screams coming from around you.”

It’s actually quite, quite creepy, and extraordinarily well-done. I quite recommend picking it up, assuming you enjoy playing scary things.

As anyone who’s been reading this journal knows, this means I’m going to complain about it. That’s just the way things seem to be going.

Dead Space is an immersive game. If you’re “playing a game”, zombies aren’t going to scare you. If you’re actually fighting your way through a derelict spacecraft, they are. One of the critical and most difficult parts to any immersive game is to not break immersion. This is hard. Very hard. Dead Space goes to extraordinary lengths not to do so. For example, there’s no HUD in Dead Space. You can see your health by looking at your character’s back (third-person, remember). Your inventory screen, and any windows or tooltips that pop up, do so via in-game holograms that exist in 3d space. Turn the camera and you can see the hologram from another angle. Monster jumps at you, and, well, it’s not like the game pauses – now you’ve got a monster on your face with an inventory screen obscuring your vision. Good move, dude. Video cutscenes? Another hologram projection from your helmet. “Click here to pick this item up”? Another hologram projection, centered on the item. Everything – and I do mean absolutely everything – exists within 3d space in the game world.

Largely, it works. We, as game developers in general, have gotten better at this sort of thing. It’s a constant battle, but one we’re winning.

Mostly.

Dead Space has three problems that I’ve found. Three big, complicated problems, that deserve their own entries. So I’m giving them their own entries. Yeah, this is a series. So there’ll be another post in a few days.

But I’ll end this with a question:

What common, constantly-ignored immersion issues do you see in games? What common problem causes you to go “hey, wait! This isn’t real!”

And how can it be fixed?