Okay, let’s polish off the Number+ postmortem real fast.

Number+ spawned out of my recent thoughts about different kind of games. Number+ is a pure skill game. The challenge is whether you can react fast enough and accurately enough to all the shit that comes flying in. If you do, you win. If you don’t, the game ends after a bit, theoretically to keep you from being annoyed at being stuck in a holding pattern. You can absolutely get better at the game with practice, and that’s rewarded by higher scores and new notes about what your number is as big as. There’s some high variance later on, but the game’s really built heavily around slow-and-steady-wins-the-race, and playing conservatively is how you beat the game (in fact, it’s nearly mandatory near the end to play super-conservatively when adding a new digit.)

Two things that worked well: sound and graphics. I pulled (almost) all my sound off Freesound and, for the first time, ended up with a game that doesn’t sound tinny and painful. That was pretty awesome. I will be doing more of it in the future. The graphical style was a total accident, I was just using white silhouettes on black for debug art for a while. Then I decided they looked good and I stuck with it. I’m not entirely satisfied with how I did them – I have three separate styles of silhouette going on – but they’re easily good enough and I think they result in a rather neat feel to the game.

Two things that didn’t work well: rhythm and balance.

One of the ideas I had for this game originally was that there would be a lot of stuff going on, all rhythmic and on-beat, and you might end up with kind of evolutionary music coming out of it. That just did not work. There’s a lot going on, and most of it does in fact happen on beats, it’s just that it’s impossible for anyone to notice. Better programmatic control over sound would probably have helped – if you’ll believe it, this is the first game I’ve written where I have the capability to *stop* sounds, and I certainly don’t have anything fancy like pitch control – but overall, I think if I want a melodic game, I’m going to have to focus very closely on that aspect.

Game balance turned out to be a major problem, and I’m not sure it’s solvable within the constraints I originally wanted.

The problem comes down to a diminishing click budget. Let’s say we trigger a challenge for the player every four seconds. This is not hard at all. Nobody will find this difficult. Let’s say we add another challenge, again every four seconds. It’s slightly difficult, but any serious gamer isn’t going to have an issue. One more thing every four seconds, suddenly it’s hard. One more, suddenly it’s near-impossible.

If you want to introduce about eight different Things over the course of this game the user will have a shocking amount of trouble just clicking on them all. Worse, if you want them all to “trigger” at roughly the same frequency, the first five will be boring and the eighth will be impossible.

I tried to solve this by reducing the frequency of the later items, but that introduces an all-new set of problems – namely, that it’s hard to figure out how to interact with the gizmo in time. There’s always a limited amount of time to react, and by the time you’re near the end, any slipup is essentially fatal.

So the first half of the game is boring, and the next third is challenging, and the last sixth is near-impossible, despite the fact that the hazards actually get [i]easier[/i] as the game goes on. And in order to beat it, you have to sacrifice six playthroughs to the God Of Learning Game Mechanics.

This is bad.

If I were re-implementing it, I’d change it from a single large number into a series of smaller numbers, each one of which teaches you about some new gizmo, then challenges you with a set of things you’ve seen before in a new combination.

A few things got lost in design. I was originally going to have some kind of “store” where you spent your number in order to get gizmos that let you pass challenges. I couldn’t come up with a way to balance it that I liked, however – the game is kind of intrinsically exponential, so I’d have maybe thirty seconds of gameplay in which the gizmo was an interesting decision, and after that it’d just be another-thing-to-click.

This is the first game I’ve been tempted to release commercially, since it would be dang easy to rip out a few dozen levels and gizmos and put it on the iTunes store or something. (Multitouch would let me do some fancy stuff as well.) There’s little enough art and sound that I could probably hire someone for relatively cheap to do things better than I did. I don’t think I have time, but I kind of like the idea.

Learning continues.

Next month’s official theme is Art Game, which I have absolutely no interest in. I’ve been thinking about games that fit the theme and the fact is that all my ideas come down to “I am shoehorning this into the theme just so I can say it fits the theme.” So I’m going to be ignoring the official theme and doing something else.

I picked up a few neat games on Steam, and naturally that led to me picking up more neat games on Steam, and someone suggested I try out Dawn of War and that led to me grabbing a pack of like fifteen games including several I’d always meant to play and long story short I just tried out Stalker: Shadow of Chernobyl.

Stalker is a game about a man in the wastes of radioactive Chernobyl who has lost his memory. He wakes up with very few possessions to his name – a leather jacket, a pistol, a knife, and a seemingly Godlike ability to rewind the flow of time.

The developers didn’t really intend that last one. But when they put in the ability to save and reload anywhere, that’s pretty much what they ended up with.

But oh boy howdy is he a lucky man! Because, see, the wastes of Chernobyl are deadly indeed. For one thing, they’re vastly radioactive, and a few steps in an unfortunate direction can pretty much instantly kill you. They’re infested with mutant wildlife which possesses the ability to leap out of bushes and also pretty much instantly kill you. And if the wildlife doesn’t get you, the bandits might. The bandits are unlike the other menaces – at close range they actually do instantly kill you.

And then you hit “reload”, only this time, you know where the bandits are.

Theory: Unlimited saving of your game is the worst thing that has ever been invented.

Alright. Not the worst. But it’s well up there, and its grip on the PC gaming world is seemingly unshakable. Imagine the following series of events.

First, people start saving their game. Everywhere. Absolutely everywhere. Get out of a battle in good shape, save your game. Prepare to go into a battle, save your game. Run thirty seconds across the world, save your game. Take five steps, save your game.

Get out of a battle in bad shape, reload your game. After all, why cripple yourself? You’ll do better next time. You can ace that battle. And you will ace that battle. And you’ll ace the next one, too, with your excess of firepower. And the one after that. And then you’ll go and complain on message boards that the game is too easy.

So what do the developers do?

Make the game harder.

And suddenly a new player can’t beat the game without doing the tango. Every battle is instant death. Every mission has to be done twice – once to scout, once to win. Every enemy outpost is a neon gravemarker, with words engraved upon, reading “Here, Jakob, Son of Smyth, Reloaded his Game Twyce before Going The Othyr Way, since Somehow he was now Psychically Aware of the Enemys.”

Does anyone enjoy this? Anyone, anywhere, ever?

And this is not a hard issue to solve! It’s been solved! Halo did it. Ratchet and Clank did it. Much more recently, Brutal Legend did it. In none of these games is it possible to lose, and in none of these games is it possible to do the save/reload tango. Death is handled by resurrecting you at the last checkpoint or at the beginning of the current mission. “Reloading” is equivalent to “dying” in that it drops you back to the same spot. In R&C and Brutal you can always abort a mission, going back in time to just before you accepted it, and go do something else. You cannot fail – only try again – and thus there is no incentive to stepping your way through the game five perfect seconds at a time.

And I look at this simple elegant solution, and I cannot help but think: why is this not used for every game? Why are games still made where you are even permitted to save whenever you want? Why, when it is so vastly detrimental to game balance, when it is so positively and thoroughly inimical to actual fun?

What game mechanic does save-anywhere actually allow?

I still haven’t come up with an answer to this.

It’s that time again! For those who were hoping I wouldn’t go back to sidescrollers, you shall be happy. For those who were hoping I’d stay away from RTSes, you shall also be happy!

Download installer here
(optional zipped version)

This game was fated to be. I came up with the idea, almost identical to what you see here, a few days before the new official Experimental Game Project theme was announced. What was the theme?

Numbers.

Numbers it is.

Let me know what you think. Postmortem will be incoming, once I have some idea whether it was successful or not :D

• Make The Number Bigger: Now both winnable and losable. Shockingly, it turns out this is important for fun. #

Thinking over my last entry, I’ve realized that – once again – I’ve lied to you.

Sorry. This will probably happen often.

I also plagiarized a little, but only a little.

“A good game is a series of interesting choices.” It’s attributed to Sid Meier, the genius behind Civilization. I am assuming you’ve heard of Civilization. If you haven’t, get the hell out of my journal (and then come back once you’ve read that page.)

Sid Meier has a very specific view of gaming. Sid Meier does strategy games – turn-based strategy games, at that, where there is always a button you can press labeled “stop, I want to think for an indefinite period of time.” In fact, in Sid Meier’s games, usually that button doesn’t exist. Instead, there’s usually a button labeled “I’m done thinking, you can do things now.”

In Sid Meier’s games, he’s completely right. Civilization without interesting choices is a terrible game.

What about Guitar Hero?

There aren’t choices in Guitar Hero. Guitar Hero is a flat-out test of skill. You are either good enough or you aren’t. (The actual definition of “good enough” depends strongly on the player.)

What about Braid?

There aren’t really choices in Braid either. You’re trying to learn how to solve the puzzles. There is no penalty for failure – you play the game inside a cheerful sandbox which is always willing to let you try again. In one sense, a random number generator could beat Braid, because it will eventually happen to solve all the puzzles . . . but it won’t understand them, and that is the interesting part of Braid. Which, it must be pointed out, can only be experienced once, because then you understand it and you’re done.

What about Samorost?

At first glance, Samorost may seem similar to Braid. I claim it is completely different. Samorost is not a puzzle game. There is no underlying logic to Samorost, there are no sets of rules to comprehend. Each screen is more of an experience than a level. In Samorost, the goal is the journey, not the individual puzzles – the puzzles are largely simple, but the journey is beautiful.

So I’m going to propose four rough categories.

* Strategy games, where your opponent fights you directly and must be defeated with skill and thought.
* Skill games, where your opponent is the game itself, which provides a series of increasing challenges to surpass.
* Puzzle games, where your opponent is your own limited understanding of the rules set in front of you.
* Journey games, where you have no opponent.

I’m going to have to mull on this one. Anyone got a counterexample to those four categories?

• MISSION COMPLETE: Save the Rogues' Guild! REWARD: Some crappy Rogues! Look, one of them almost died before the cutscene was done. #

So. Mobius.

If you haven’t played Mobius, and plan to, stop reading and go play it, since I’m about to spoil the whole thing for you.

Still here?

The official theme this month was Failure. Usually, failure means you lose the game. Mobius is born out of the first idea I had regarding failure – a game where failure made you more powerful. Every time a character dies, the game counts up how many monsters you’ve killed and credits those to the person who “died”. He becomes more powerful, but is penalized with having fewer HP, making him more likely to die in the future. If the difference in experience gets too great, a death can actually result in real, true failure, coupled with Game Over.

That is pretty much the entire game.

For a variety of reasons, I don’t think it worked. And I could go into each one in detail, but to be honest, there’s one which is big, and important, and vastly overshadows the others.

Real-time strategy games are intrinsically not very much fun.

They suck. They are boring. They are awful, awful games. I am prepared to defend this statement, but let me explain what I mean first.

There are genres of game which are intrinsically fun.

First-person shooters: you get to blow shit up. That’s fun. You can run through an FPS in God Mode and still enjoy yourself, because, hey, kaboom! Kablammo! Look at all the shit I’m blowing up! Look at all the zombies/nazis/robots/robot-nazi-zombies I’m killing! This is so much fun.

Sidescrollers: The good ones are simply a joy to control. Look at Abe’s Oddysee for the best example I know of, but a far more well-known example is Super Mario World. Super Mario World is fun, even when you’ve played it before. And that’s not due to the inventive level design, or the “plot”, or the challenge – even after someone’s beaten it half a dozen times, they’ll go back and try it again. It’s simply enjoyable to play.

Anything involving leveling: We like leveling! People like to see a number that represents how awesome they are, and they like to see that number get larger. So you can have fun with RPGs even after you’ve beaten them once (plus it’s like re-reading a good book), and you can enjoy Civilization 4 many many times, partially because your empire is getting huge and you’re awesome. It’s fun. You’ve done it before, but let’s do it again, let’s become big and strong for the third seventeenth one hundred and fortieth time.

There’s one other aspect that can rescue an otherwise doomed game: Intelligent challenge. If fighting against your opponent is nontrivial, if it’s not obvious what the right choice is in every case, then you can get a great game out of it. See: Civ4. See: Starcraft multiplayer.

And that’s the crux. Starcraft multiplayer is a really good game. Starcraft singleplayer plot is really good. But nobody finds Starcraft singleplayer fun to replay.

Why? Well, it’s simple. There are no interesting choices.

A good game is a series of interesting choices, and once you know how an RTS works, the choices aren’t interesting anymore. You know the build order. You know the right units. And, let’s face it, even if you don’t know the build order or the right units, singleplayer RTSes can almost always be beaten with a few very basic steps:

* Defend your base.
* Build your economy.
* Create an army.
* Destroy the enemy.

That’s it. That’s the strategy. Now you can beat almost every singleplayer RTS ever made.

Now, you can draw this out quite a bit. Good singleplayer RTSes tweak the game subtly, many many times, so you never quite understand how it works. They disguise it as “unlocking new buildings and abilities” – in every level, you get More Stuff, changing the game balance and the optimal unit loadout slightly, and you only get the best stuff in the last level. Ever wondered why RTSes delay so much? Ever wondered why first-person shooters seem content to give you all their weapons about halfway through, or two thirds of the way through? It’s because the RTS game has nothing more to offer you once it’s shown you everything.

Because the game, itself, is fundamentally boring.

There are many ways I could criticize Mobius. It got less actual development time than any other game I’ve made so far, and the only reason it doesn’t look far worse than Too Many Guns is because I’ve gotten a lot better at making games. The writing suffered, the art suffered, it could have used more variety, it could have used more testing and more balancing.

But the single most damning criticism is a very simple one.

Mobius is, unintentionally, a puzzle game, masquerading as an RTS . . . and once you solve the puzzle, you’re left with a very simple RTS.

Single-player RTSes do not have interesting choices. Mobius does not have interesting choices.

And, thus, Mobius is not a good game.

Download installer here (advanced: zip version)

I’m taking a pretty serious diversion from my previous game designs. Mobius isn’t a sidescroller in any sense, and in fact, it’s controlled largely using the mouse. We’re into realtime strategy here, folks. Well . . . realtime tactics.

Beyond that, however, I’m not saying a whole lot about Mobius right now. Download it. Play it. Let me know what you think.

I’ll follow up with a postmortem in a bit.

I have been thinking, recently, about which board games I enjoy and why.

First, this is a very different subject from computer games. Computer games have plot and flow and artistic beauty outside the raw game mechanics. Board games, fundamentally, don’t. They’ve got flavor, but it tends to be very static flavor – contrast comic books with a single frame from that comic book. Much of this entry doesn’t immediately apply to the board game’s single-player electronic brethren. I know you guys probably read this for video games, but, well, I’m not a video gamer, I’m a gamer.

Second, what I should be doing is sleeping, but we can probably all guess how well that’s working right now.

So you get a development log entry.

An engineer, a physicist, and a mathematician go to a convention.

That night, they all retire to their own separate rooms. They bid each other good night, remark upon the remarkable weather, and sleep. The aforementioned remarkable weather gets worse, lightning strikes the hotel, and a spark leaps from each person’s power outlet and lands in their wastebasket, which catches fire.

The engineer wakes up first. He sees the fire, grabs the water cup from his bedside table, and hucks it at the fire, which goes out. After checking to make sure it’s out completely, he goes back to sleep.

The physicist wakes shortly after. He quickly estimates the volume of his cup and the size of the fire, guesses at the trajectory necessary to douse the fire, nods in satisfaction, and elegantly hoists his own cup into the air, perfectly covering the fire. He checks to see if it’s out, just to be sure, but he knows it will be, and it is, so he goes back to sleep.

The mathematician wakes last. He derives the volume of water, and proves to himself it will put out the fire. He quickly measures his arm strength and the distance to the wastebasket. He calculates an arc that will land the water perfectly in the wastebasket, then rapidly doublechecks his calculations.

“Aha!” he proclaims. “There is a solution!”

And he goes back to sleep.

I really can’t stand chess.

I’ve tried. I really have. I know it’s a good game. I know many, many people play it. But me? I can’t stand it. I think I finally figured out why.

There’s a solution to chess.

More importantly, there’s a solution to pretty much everything involved in chess.

Now, okay, we can’t make a computer that can play perfectly. But at this point chess largely comes down to sheer horsepower. Chess AIs can beat humans regularly. It’s no longer even worth mentioning. The game is understood well enough, and by enough people, to describe it to a computer such that the computer will absolutely destroy you regularly. But this is not the critical part.

The critical part is that there are two groups of people when it comes to chess. There are the people who have been playing for their entire lives, and there are the people who haven’t. If you’re in the latter group, everything you could possibly come up with in the game has been done already. There is no room for invention. If a move is uncommon, it’s probably because it’s stupid. The game, for you, is solved.

And it’s not like you couldn’t get better. Of course you could get better. You could, quite easily, get better at chess than most people you’ve ever met ever will be. But you’ll never be a grandmaster – you didn’t start when you were four years old. (What were you thinking?) You will live your entire chess career knowing that there is a bar that you will never reach.

This is not what I want out of my entertainment.

What I’ve determined, slowly and painfully, is that the part I find fascinating about games is learning how they work. Learning how the pieces interact. Learning how the options interact. Finding ways to break the game, finding ways to fix those breaks, finding ways to break those fixes. I don’t want to hone myself to become an absolutely perfect player at a single game – I want to analyze that game from the inside out and figure out its strategies and design philosophies and understand them on an intellectual level. Nothing more.

And with chess, that’s already been done. I can walk into bookstores and find shelves of books doing exactly that.

What’s your chess-related question? Oh, let me look that up for you! See? There’s a solution! You can go back to bed now.

Alright, I’m not going to bed yet, because I wrote that subject line up there and I’m not going to change it because I was more awake when I wrote it than I am now and there’s still one bit in that subject that I haven’t touched on.

Eurogames.

The history of board games has been a long and complicated one. Settlers of Catan was really the landmark moment in the recent resurgence, and deservedly so, because it is a great game that happens to avoid many of the problems I find in eurogames.

Eurogames are a genre of painstakingly balanced board games, with some light flavor and usually light strategy. A single play tends to make that strategy clear. Perfect execution of the strategy is perhaps difficult, but sufficient execution is usually reasonably simple. Eurogames frequently have further balancing mechanics, so that mistakes made in the beginning and end of the game work themselves out rapidly, leaving a tight playfield at the end for many exciting endings.

Eurogames are a genre of games painstakingly crafted to have limited expert play, with rules carefully constructed to both create an obvious strategy and blatantly demonstrate it to everyone involved. Perfect execution of the strategy is difficult, but except in the absolute highest tiers, largely unnecessary due to internal self-balancing, aimed to insure that everyone is somewhat successful. This balancing can become so extreme that the victory hinges not on your play in the beginning or middle of the game, but on your ability to precisely calculate the entire game state once you’re two or three moves from the end.

You see the problem?

It’s as if the wastebasket fire came with its own solution. You don’t even need to wake the mathematician up, it’s already done!

I’m not trying to say that Eurogames are bad games. If anything, the opposite is true – the well-known eurogames are such good games that they are immediately uninteresting. I probably won’t be able to break them. The strategy is well-known. In many cases I can’t even hone my strategy worth talking about, since either the game result hinges around random chance, or it relies solely on the player’s ability to bruteforce the entire game decision tree in his head.

The execution can be fun. No, scratch that, the execution is always fun.

But when I find myself thinking about board games, and wanting to play them again just to analyze them further, I don’t think about eurogames. I know how Power Grid works. I understand Settlers. Carcassonne has basically two tiers of play – one involves counting cards, and the other is trivial. Once you learn how not to screw yourself, you’re done with Ticket to Ride.

I find myself thinking about the games that I’m not sure are balanced. Starcraft, which, in board game form, is a ridiculously complicated strategy game. Android – I’ve played it three times, and twice it’s ended in degenerate cases that, it turns out, violate the rules. Galaxy Trucker, with an entire major game mechanic that I simply do not know how to optimize yet.

And if I’m not playing a game for the research, I’m playing it for the flavor . . . and with eurogames, that flavor tends to be limited.

It’s late, and I’m tired, and I should have been in bed something like (oh god) four hours ago. But at least now I have some basic understanding of why I’m bored of eurogames, and why chess doesn’t interest me, and why Go does (it’s because the strategy in Go seems less understood, and seems more intuitive, and I don’t yet get it, while I do basically understand how chess works even though I can’t play worth a damn), and why I’m finding myself rather fascinated with Arimaa lately.

I suppose if there’s one thing you can hope to get out of sleep deprivation, it’s introspection.

And now I really am going to bed.

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.

Bit of a general fuckup here, folks – it turns out that the Mandible blog has been rejecting comments for probably a few days. If you posted a comment about Fluffytown, I’m sorry to say it got entirely lost and I can’t retrieve it. If you had anything to say (and I’m hoping someone did) I’d appreciate it if you’d go back and re-comment, or at least summarize what you had to say.

Now I’m going to go figure out a way to automatically notify myself when things go this wrong.

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.

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