Ludum Dare 31
Theme:
Entire Game on One Screen

Judging ends in:
It’s time to Play and Rate Games!

PlayRate80Star

SuperShred – Postmortem

Posted by of LoneStranger Designs (twitter: @lnstrngr)
April 21st, 2009 8:09 pm

Since it’s been a few days, I wanted to write up a postmortem on my LD48 #14 entry before I forgot too much.

Background

I didn’t think that any of the final themes were very good, or at least, anything I was in the mindset to tackle last weekend.  When the theme Advancing Wall of Doom was announced, I was sort of disappointed.  I hadn’t come up with any ideas for it, even though it was a front runner earlier in the week.  I think I sat down and watched some TV for about an hour and a half before I even started coding anything.  I flipped through the program guide for any ideas but nothing.

The idea can be literal, and I think most people created games with a wall in them.  Advancing Wall of Doom has been done in many games as an actual wall, so this wasn’t a bad design.  From the start I decided that I didn’t want to use an actual wall.  Figuratively, the AWoD is just something that you cannot stop from coming.  You just continue until you cannot continue anymore.  In lots of games, this wouldn’t be any fun, so if you can survive for a period of time, you win.  In a way, Tetris is an AWoD.  You can do what you can to keep the wall (i.e. the top of the well) as far away as possible, but eventually it gets closer (pieces fall faster) and you have less room to maneuver.

Mechanics

I knew that for this LD, I wanted to do something very, very simple.  I had two birthday parties and one playoff NHL game to attend to, so I didn’t have a full 48 hours.  I remembered an idea I had for a typing game, and decided that an AWoD would make a good way to push the user to type faster.

Gameplay is simple.  The wall moves from the left to the right as the phrases come from the right to the left.  If they meet, the game is over.  Since this is a typing game, a shredder played the part of the wall.  It starts off slow and as the user makes mistakes, the shredder picks up speed.  If the user can complete ten phrases without ending the game, they will get a short reprieve by setting the shredder back to the default advancing speed, but it will never ever stop.

Coding

I mapped out a couple objects that I would need and started getting them working.  First the phrases, then the AWoD disguised as a red box.  I progressed a bit at a time, getting the phrases to move, the wall to move, then for them to interact.  Input was probably the trickiest.  I used the KeyEvent VK codes, and they don’t tell you what character was input, only what key.  So it will tell you that the user hit ‘G’ but it doesn’t tell you if it’s a ‘G’ or ‘g’.  You have to check for the presence of the Shift key.  For the alphabet and numbers, it wasn’t a problem, but it got sticky for a couple of the symbol characters.  For some reason, the VK_QUOTE or apostrophe key and VK_BACK_QUOTE or backwards single quote were not actually showing up when I hit those keys.  After fussing with them for an hour, I ended up ‘hacking’ a solution together than just checked for the input I was getting from those keys.

By the end of Friday, I had most of the idea done, it just needed something to make it a game.  One of the ways you can do that is add points.  So I came up with the idea that you would get a point per character and maybe some bonus for completing the phrase.  As I was beginning to code that, I figured stats on your successful streaks would be great, and then realized that you should get more points the better you are doing.  Instead of one point per character, you got your current successful typing streak.  So that works.

I started working on the graphics for the wall and settled on a box with teeth on one end.  I drew some teeth and photoshopped them onto the box. By the end of Saturday, I felt that I had a reasonably fun game that looked decent too.  Did I say Saturday night?  I meant Sunday morning at 5am.

Sunday, after four hours sleep, I fixd the two keystroke bugs and add some actual phrases for the user to type. Along with those phrases, I created the WordKeeper to keep track of them, and added a PopupText class to manage the popup text that shows up when you do good or bad, or complete the stage.

So I managed to complete most of what I wanted to do.  Of course, there is always polish that could be done, but because I had some things to do on Sunday, my time was limited.

What I Did Well

I think I did a great job at scaling down the game.  I didn’t need a lot of graphics.  In the past, I’ve spent a little time drawing some art and photoshopping it and while that may take a lot of time, I didn’t have to worry much at all for this compo.  I do miss the art style from my last compos though, so I’ll try to use them next time.

Input is usually one of the pain in the rear things for me.  I have to come up with a scheme that is intuitive, but I also have to take that input and figure out how to use it.  In the Roads compo, I had to learn how to use the mouse to steer a car on a road and make it seem legit based on the speed of the car.  I wasted a lot of time on that.

Sound effects.  Oh man.  Dr. Petter’s sfxr tool rocks for this one.  I think I spent less than five minutes generating sounds that I felt fit what I needed.  They’re simple and very Atari 2600-ish, but they offer great feedback while playing the game.  I tried his music program, but I lack talent in music and should probably try to learn it outside of a compo.

This was the fourth competition that I’m using the same general basecode.  I’m getting used to it and making changes here and there so I don’t have to waste hours trying to figure out how to do basic things for every compo.

What I Did Wrong

Surprisingly, not much this time around.  I had three things that were planned for the same weekend.  One birthday party each day, and a playoff hockey game Sunday night.  I knew that if I didn’t get the game mostly done by Saturday night, I wouldn’t have much time to complete it on Sunday, so that’s what I aimed for.  Sunday was mostly spent doing the last bit of features and polished a little bit of it.

I would have liked to have made the stat display actually look better with some kind of graphical overlay.  It’s really the only part of my game that I think looks boring.  Sure, the shredder could be better, but it’s ok the way it is.

Some of the phrases submitted with the final entry are really long.  They should have been split up into two or more.  It also might have been easier for the player if I put the entire phrase un-scrolling on the bottom of the window so they could look at that.  I think one of the voters already realized the maximum WPM you can get is around fifty since the phrases scroll is constant.  Another way to fix it would be to speed it up if your recent WPM is past a certain threshold and slow it down if it’s not.

What To Do Next Time

Next LD competition, I still want to scale down, even if I have more time that weekend.  With what I did in the time I had for AWoD, I could really make it great with another six or twelve hours.

I want to continue with my basecode and work to make it more robust of a base.  I see things that other people are doing and I know I’ll never be able to do them if I don’t build a better foundation and skip the mundane basic code.

Conclusion

I’m really happy with this compo.  This was my fifth competition, and the third where I actually submit a final version.  I’d like to continue as this is a great way to keep skills sharp and perhaps learn something along the way.  See you in August for LD48 #15!

Tags: , , ,


One Response to “SuperShred – Postmortem”

  1. Great Postmortem,

    I know plenty of people have mentioned DrPetter’s sfxr tool but your post is what finally got me to take a look at it. It’s just as awesome as everyone says.

    So thank you, and thanks DrPetter :P

Leave a Reply

You must be logged in to post a comment.

[cache: storing page]