Zorba the Hutt (zorbathut) wrote,
Zorba the Hutt
zorbathut

No Such Thing As Too Many Guns

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.

Tags: coding, design, monthly game
Subscribe
Comments for this post were disabled by the author