No Such Thing As Too Many Guns

2009, June 24th 8:34 AM

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.

  • Malimar

    2009, June 24th 1:47 PM

    For me, "better guns" (or, more specifically, "moar dakka") generally equals "more fun". So, after trying it the intended way the first time, I spent the second and third plays attempting to die as often as possible in order to get the best guns. Then, having achieved apparent maximum dakka ("maximum" in the sense of "I accidentally killed the final boss"; I couldn't tell if there was an actual maximum, or if the recursive guns kept improving), I set it aside.

    Making the guns more varied in what they do, rather than simply increasing the rate and cone size, would probably indeed improve the experience, but it might also add more incentive for that contrary behaviour. I also craved more levels to use my epic dakka on, which may have the same problem.

    But I am probably somewhat abnormal in that I never pay any attention to score for its own sake in any game, so I wasn't even slightly tempted to play it the proper way more than once. Take that as you will.

  • Zorba

    2009, June 24th 1:50 PM

    Actually, you're pretty normal in that respect – score is a terrible motivator, it's just an easy one to use for testing ;)

    I'm pondering a few ways to make it more rewarding to play "properly" – one idea I have is to not, in fact, provide better guns for getting hit, but rather having less incoming firepower every time you get hit. In this case, the reward for doing well would be a better ending.

    Perhaps in a few months I'll give that one a shot :)

  • soliss

    2009, June 24th 3:38 PM

    Good times. Pretty impressive that you could make that in 5 days.

    Minor point: You might want to make it so hitting space doesn't close whatever the screen was at the end of level 2. I was hitting space repeatedly to fire, so I have no idea what that screen said.

  • soliss

    2009, June 24th 3:38 PM

    Level 1, I meant.

  • Zorba

    2009, June 24th 8:52 PM

    I'm actually surprised how well it turned out, given the very limited development timeline. I'm looking forward to trying out more stuff – really, there was at most four days of actual game logic there. The next one should come together even faster.

    In theory, you're meant to be holding space down to fire. I don't really deal well with that, though, a lot of people do the same thing you do and get the same issue. Something to think about for next time.

    I also need to stop doing text-heavy splash screens.

  • Tang

    2009, June 25th 11:11 AM

    To explain the hit/gun mechanic in other words, the game dynamically adjusts the difficulty to the player's skill level. Most games do this by starting easy and getting harder as you advance through scripted difficulty levels. Adjusting the difficulty in place is an interesting way of doing things.

    I can't recall any other games that did that, although Final Fantasy 2(j)'s level mechanic was similar in that it increased your stats based on what skill you used most often and would only upgrade your HP if you got hit. I had my characters beat each other up to raise their max HP, which was probably not part of the original game design. Dynamic difficulty becomes another part of the game that can be played, as Malimar explains.

    Thoughts on not dying: Most original Atari and arcade games did not have endings the way modern games do. They simply started over if they ran out of content. The goal was not to beat the game but to go as long as you could on the same set of lives.

    Beating a game gives the reward of a sense of accomplishment, but it is less of a reward if the game does not challenge the player. Dying and having to start the game over makes it more challenging, but if the player is forced to repeat large sections of the game and it seems the player is never going to win it, the game ceases to be worth playing. Managing death in video games is a matter of finding the right balance of difficulty without contributing to annoyance. Savepoints alleviate the problem of repetition of parts of the game that the player has already beaten, but as you say, sometimes the savepoints are too far apart. The too-challenging games of the NES become a different experience on an emulator where you can save or restore at any point, but it was not a big accomplishment to beat them on an emulator.

    Dying would make this particular game much too hard because there are simply too many missiles flying around the screen to dodge at certain points. The accomplishment here is not to beat the game but to beat it with the worst gun after taking the fewest number of hits. Failure in this game is getting hit more often than you did the last time you played, but this does not prevent you from finishing the game and it is a short enough game that you can start over and be back to the same place in five minutes.

    One game which was much better than similar games for the fact that you couldn't die in it (except as an Easter Egg) was the King's Quest clone Monkey Island. Dying in the Quest games and having to start over was really annoying, and Monkey Island even joked about this ("Rubber tree."). The challenge and accomplishment in Monkey Island was in figuring out the puzzles. Puzzle games can also be too hard. An impossible puzzle in a puzzle game can be as bad for a game as dying and having to start over too much, but at least these days you can Google up the answer.

    I have sometimes thought that for a little Flash game that is supposed to be fun to play and show off a fun story, but is not intended to be challenging, it might benefit the game for designers to replace the classic "you have X lives" mechanic with infinite lives and a notice that "you died X times" at the end. I believe the Unfair Platformer does this.

  • Your Mom

    2009, June 27th 3:35 PM

    Actually, I don't find myself going for a better score – it's easier to remember what gun I ended with and keep trying to end with an earlier and earlier gun. I don't mind the game over as long as I get somewhere. Which I don't with the games you mentioned. Also, I really enjoy games more when someone else is involved – I think this is a common female thing, at least. I like playing Braid because you're usually there to laugh at me. ;) The other games I like and play alone have levels, but I usually top out well before beating the game, so I get bored. The main thing that's come along lately that I love and would play over and over (alone) is Flower. What it really comes down to is, I hate competition. I like Tang's idea of infinite lives, with a notice of how many times you died at the end. A game in which you can achieve immortality!

  • Your Mom

    2009, June 27th 5:12 PM

    Oh, and why isn't there a Linux version? You're the one who talked me into switching… :P

  • […] doing it within 48 hours, it turned out great. Compare it to my earlier games – I spent a third as much time on this one, and I think it turned out better. My tools […]

Leave a Comment

Subscribe without commenting