Background and Pre-Compo

My primary goal of this, my first Ludum Dare, was to finish the competition. Nothing more; not to win, not to place, not to show. In fact, someone’s game has to come in last place, and I was totally OK with that game being mine.

There’s something mystical about computer games. Every developer I know has tried to write one. All of us dream of checking out from our dreary jobs after a sleeper hit that we wrote at home over 52 weekends. But though we’ve all tried, none of us ever seem to finish our games. I was tired of being in the slacker group. I wanted to join the cool kids who have finished a real computer game.

I made the final decision to participate a few hours before the theme announcement. My wife’s 9 months pregnant and could go into labor at any moment, so when I first heard of LD a few months ago, I dismissed it as too close to our due date. But by Friday afternoon (Pacific time), it was looking to be a quiet weekend, so I committed. I knew that by Sunday evening I would submit a Ludum Dare entry.

Technical Preparation

At around -2:00 (two hours before the theme announcement), I downloaded an IRC client and joined #ludumdare. I closed all my open projects in Eclipse and created a new blank Pydev project. I made sure I could draw a gray screen in pygame. I promised myself that I’d stick to 2D.

I searched Google for [royalty-free clip art]. Then I read the contest rules for the first time and was horrified to learn that we couldn’t use clip art. You might as well have asked me to sing on American Idol. But hey, level playing field, etc. etc. etc. No biggie.

While waiting for the theme announcement, I read some of the survival guides and prior postmortems. Don’t use LD as an opportunity to learn new technologies. Don’t start coding before you’ve done a little bit of design. Don’t design for lots of content. Don’t get drunk. Don’t pick this weekend to get a new girlfriend. Roger wilco.

First Night

I spent the first few hours of the competition kicking around ideas. Almost every one was too ambitious, mostly requiring level design or lots of cute icons that I couldn’t draw, or else having a bunch of vague “and then the two actors have some sort of conflict” parts that I wasn’t sure would get clearer in the remaining 46 hours. I settled on a dumbed-down Tetris variant.

This was the first decision I made in the competition, and it was probably right for my personal goal, but it doomed any chance my game had of being playable. It was the best briefly-describable game I could think of in the short timeframe. I traded the benefit of simplicity for the chance of creating something interesting.

I wrote a little code and started talking myself out of the Tetris idea. Sensing trouble, I backed away from the keyboard and went to bed.

Saturday

I woke up hating my design even more. I started typing in more Google searches: [anti tetris], [tetris variants], [inverted tetris]. My web browsing was getting more free-form. Huge warning signs. I pulled back and resolved to get back to my stupid original idea.

Six hours later, I had the core game finished. I added scoring and an in-game tutorial. I also added some animation transitions that were surprisingly effective in helping my focus group (my two kids, ages 4 and 5) understand the cause/effect relationships in the game.

After a dinner break, I made another big decision: either explore gameplay and risk destabilizing the code, or button everything up to guarantee that the entry would be finished. I picked the conservative route and promised to return to gameplay during whatever time was left on Sunday.

This decision hurt, because I knew the submitted game was now very, very likely to be trivial and dull. But last time I checked, game design is hard. Which am I more likely to do in the remaining hours: stick to my strength of writing production-quality code under deadline, or come up with a brilliant flash of creativity?

Sunday

More buttoning up: gameinfo.xml, readme, license, screenshot, hunt-and-peck testing (which did discover a few obscure but good bugs), py2exe, free-licensed font, and coming up with a suitably dorky name for the game. As expected, these details sucked up a fair amount of time. But damnit, my entry was technically complete in every sense. I’d finished Ludum Dare!

With the remaining time, I implemented two interesting features: a special tile that showed up later in the game and introduced some locality constraints on the board, and various gradients on board components that gave them some visual depth. The gradient code introduced far more CPU usage than I expected, so I spent the last 90 minutes before the 48-hour mark prerendering and caching as much as possible (while flipping through the Git documentation to figure out how to quickly revert to earlier in the day if I had to abort the gradient project to make the deadline).

What I did right

• Set a realistic initial goal and stuck to it.
• Wrote solid, conservative code.
• Added a reasonable level of polish: transitions, cosmetics, in-game tutorial, and compliance with all the LD submission guidelines.
• Stayed on IRC.
• Admired without envying the progress of my fellow competitors.
• Postponed needless risks as long as possible, while tackling necessary risks as early as possible.

What I did wrong

• Wrote a really crappy game that is wasting LD judges’ time. I didn’t realize that every entrant was expected to judge every other game. That’s a heck of a O(n^2) algorithm, and I’m sorry to be contributing to the polynomial explosion. I wish there were a “submitted for non-consideration” tag, like “finalbutdonotjudge” instead of “final” if you’re entering just to enter, not to compete.
• The one somewhat fun aspect of the game is the special tile. But I don’t introduce it until 60+ seconds into the game. Unfortunately, from the comments left so far for the game, I am pretty sure that most judges exited before seeing the first special tile. The rule of thumb is to sell the core of your game in 20 seconds, or risk your judges bailing out early. Fixing this wouldn’t have saved the game’s crappiness, but I’m disappointed that I didn’t get this easy part of the game presentation right.
• Aimed a little too low, even for my first competition. It’s my personal style to value reliability over creativity, but successful gaming is all about taking risk. That’s obviously true in game play, but it’s also very true in the development of indie games. Your audience really doesn’t give a shit how proud you are that you finished your game; that’s a given, or else they wouldn’t be wasting their time playing your unfinished game. So people expect that any finished game will reach a basic level of challenge, and mine definitely failed that test. It was a fine personal goal to finish LD once, but for a second LD, if my game were no more fun than this one, I’d decline to submit it and call my attempt a failure, even if it was technically a complete entry.
• Didn’t explore every artistic challenge the compo has to offer. I should have tried to draw something. It was fine to use sfxr for my beep-boop sound effects, but at a minimum I should have tried throwing some reverb over the wav files. I avoided injecting any kind of artistic expression into my game, and as a result the game’s not just boring, but also sterile.

I have fixed a small bug in the AFI Top 100 quotes phrase file.  It contained an elipsis character that you cannot type.  I also fixed some issues with spaces showing up before a single quote.

You don’t have to redownload the game, just the two separate phr file and overwrite the originals.

phrasesupdate.zip

Introduction

This was my first attempt at entering the Ludum Dare (a.k.a. LD48). It was a bit intimidating to see some of the really impressive games that came out of previous LD48 events, however the line on the LD48 website reading something like “Historically, less than 20% of the contestants submit an entry” was a bit of an encouragement. At least if I bailed, I wouldn’t be alone. As it turns out, I was able to eek out a ‘game’ in the 48 hours, even if the only machine it likely runs on correctly is my own.

Time Management

I got my idea pretty early on, and my game design was done in under an hour. I’d say roughly 40% of my time was spent coding what could have been reusable game engine things, such as a texture loader, sound effects loader, collision detection code, etc. Another 20% was spent on logic specific to my game such as collision response, physics updates, game end conditions, and state changes. I spent another 30% on the game resources, including artwork and music. The last %10 was spent on the initial design, some game tuning, writing a quick read-me, and finally a mad rush to get everything packaged and uploaded.

Although I had devoted the entire weekend to the event, my girlfriend had some friends in town, and I spent about 7 hours (~15% of the time). I slept also, which in retrospect, was a good idea. By then end of the event, my nerves were starting to feel shot.

Development Tools

I was doing all my coding in C++ on Linux, using OpenGL and GLUT for graphics, OpenAL and libvorbis for audio. I used CMake (a build tool) to help generate makefiles which is handy because it allows one to generate build files for other systems (Visual Studio solutions, for example) using a single cross-platform compatible input file.

Editor: I used XEmacs as my editor. I’ve spent some time using it and have it customized pretty well to suit my needs. What do you think I’m typing this write-up in?

Graphics: I used Graphics Gale to create all the artwork, which I saved as 32-bit Targa files. Graphics Gale is available for free in it’s basic version with some feature restrictions. It has a few features to make drawing ‘cell style’ animation easier, such as onion skinning and animation previews.

Sound/Music: I wanted to integrate the use of my MPC1000 hardware sequencer in to my work-flow, so that’s what I used to sample a guitar riff and some beat-boxed sound effects I recorded. I have a microphone, mic pre-amp/effects processor, and dedicated guitar effects processor to tweak sounds before I edited and sequenced them in the MPC1000. I also used a couple freeware VST synthesizers from Tweakbench.

Time-lapse Video: During the competition I was continuously saving desktop screen-shots every 30 seconds which I later compiled in to a video. To save the screen-shots I used a Linux tool named scrot, and a very simple bash script like this:


#!/bin/bash
mkdir /home/win/screenshots
for (( ; ; ))
do
scrot /home/win/screenshots/%d%k%M%S.png
sleep 30
done

Note that in hindsight, I had some problems with the way the files produced by scrot were named. Some of the files had spaces in them, which might be a bug in scrot. This was a problem for me because my video encoder (ffmpeg) was unable to deal with anything other than files that were named in sequence numerically (no gaps in numbers). I was able to use the batch renaming feature of the Linux tool GQView to rename the files sequentially based on their date-stamp, and ffmpeg was happy. The ffmpeg encoding tool was able to splice in an audio file as it encoded the 1800 jpeg frames.

Game Design

I got lucky in that the chosen theme, ‘Advancing Wall of Doom’ was already my first choice, so my subconscious had some time to mull over the design. I wanted to keep the design dead simple so I wouldn’t bite off more than I could chew. Looking back, this turned out to be a good thing, as I was working right up until the end of the compo and wouldn’t have had time to add any extra features. Even though the design was simple, I feel I should have spent a bit more time considering the playability and fun factor of the game. During testing it was very apparent that my game lacked a lot of variability, and there wasn’t much room for any real strategy or technique. Every test-play through the game took about the same amount of time, and I hadn’t exactly intended the game to be based on any time limit.

Things Learned

Overall I’m happy with my performance during the competition, mainly in that I was able to complete my project in under 48 hours. Although my personal experience playing the game is biased, I’d say it’s good for at least a minute or two of genuine fun. I was also able to take a few things away from the experience which should make my life easier if I decide to compete again:

1. I was coding at a relatively low level, and ended up spending too much time writing and debugging code to provide functionality that others in the event were essentially getting for free (image loading, sound, collision detection, etc.). I also had to be aware of some platform-specific issues (namely timing functions) that users of other APIs could also ignore.

2. Sleep and getting up for breaks is important. I even went outside and ran around the block once during the compo. A couple minutes of jumping-jacks were helpful also. I didn’t regret spending about 15 hours during the compo asleep. I get the feeling my mind was still somehow at work debugging my code while I was sleeping anyhow.

3. I should have spent some time preparing a bit of template code that is generic for any relatively simple game (2D or 3D) that I might want to quickly create. Game loop, end conditions, state changes, main input/display/audio systems all seem like targets at first glance. I had a hard time deciding how to write my code in order to keep an architecture that wouldn’t strangle itself in the short time span of the competition. I think an overall ‘game template’ even if it was just a short checklist, would have been really helpful to me.

4. Although this wasn’t an issue during my time spent in development, I realized after the competition that my code would not be immediately available to other entrants because of the development tools I chose, and the because the corners I cut in testing meant that I produced code which had problems with timing and input on other systems I was able to test my code on afterward. This is a big problem because it makes judging by the other entrants much more inconvenient of not impossible. If I had developed for a virtual-machine environment such as Flash, I suppose I could have avoided this. problem.

Conclusion

I had a great time and am looking forward to entering in the next compo if I have time. I think as long as I can view the event less as a race and more as simply an exercise in programming and design on a very short time scale, and use the experience to become a better coder.

I also have to mention that the social aspect of the event is really great. Everyone in IRC was really friendly and helpful, and it was exciting to see what people had going on at any given time of day or night. I even found out that one entrant was a fellow student at my college, taking one of the same classes even. I’m glad that my comment about his entry on the web wasn’t too harsh!

Thanks everyone for a great event. Long live LD48!

-Windsor 04/22/09

Okay, I’m calling the game done. The biggest addition is a campaign of semi-random levels which introduce the game a bit more gradually. I’ve also added in some special case rules that help regulate the game a bit and keep it from breaking quite as frequently. This build also includes a few small graphical changes. After playing through the campaign, the game creates an endless string of more random arena levels. Here are some directions:

Purple creature- this is us!

Red creatures are enemies.

Green creatures are our allies. They produce two types of helpful offspring:

Purple followers can be collected for additional firepower.

Green eggs can be gathered and planted to make new allies.

<arrow keys> – move

<space> – plant eggs

Our character fires and heals itself automatically.

Play the game

Edit: Updated Version (fixed a sound glitch)

Edit again: A New Version (fixed a couple bugs that affected creature reproduction)

These are two examples of the new levels:

Hey everyone.

Since you’re all busy busy playing and voting for entries, I thought I’d open up a thread to collect some suggestions. We’ve already seen many great ideas come up in IRC, but they should really be written down. So, any thoughts on the voting process, submission process, or anything to improve how we run a compo, drop a comment to this post.

With such an big turn out for April, it looks as if we’ll have to start taking things more seriously to manage the growth. If you’re a PHP+Database+Wordpress guy (gal) that wants to help us out, stay tuned.

For now, I’d like your thoughts. Respond away.

- Mike Kasprzak (PoV)

I recorded a timelapse of my game which Fiona uploaded to youtube for me – hurray!

http://www.youtube.com/watch?v=nkbvkhGOR-0

The analog clock in the corner looks awesome

Hmm I didn’t know how to get the video to be embedded in the page – is there some trick to it?

Hi people, I had some trouble with my home server where I was hosting my LD48 #14 entry, and so I’ve moved it to my domain host’s server.  If you want to test/play/vote on my code, the download link is here (Linux source + i386 binary):

http://windsorschmidt.com/dl/winferno_LD14_youfirst.tar.gz

I’ve also got my desktop timelapse video up on YouTube here:

http://www.youtube.com/watch?v=nuUO8E62Vt4

Or, if you want to download the original 8MB video file (mpeg video + audio), you can get it here:

http://windsorschmidt.com/dl/ld48_14.mp4

Thanks everyone for a fun event. I’ll definitely be putting the next LD on my calendar!

-W

This is my first LD so I don’t have anything to compare to, but I actually think overall I did pretty well. I’m not sure I can say what I did write and what I did wrong, being new to the compitition and game developement in general, but I can say what I did at least.

Ideas

I didn’t really have much trouble coming up with an idea. My first thought was to make the game incredibly happy looking (flowers, smiley faces, etc.) and then have a freakish wall of death, but it relied on graphics and I had no thoughts for game play to back it up. Really, it seemed you could either take the theme literally and make a wall of doom chasing you, or you could interpret it to make some sort of art game.

I chose to just make a wall of doom. I didn’t really think of the game play mechanics at first, just started making the player graphic. I guess I did that wrong, but I just wanted to start coding and see what I’d end up with. The final version ended up pretty well balanced, I think, but so many things could have gone wrong to ruin it entirely.

Code

Using Construct made the coding pretty easy for someone as new to game developement as me, although I do hope to enter LD some day using “real” code. The game required a lot of things I’d never done before. The player remained in the center of the screen the entire time and the ground went on for ever, so instead of programming the player to move I moved everything into a family that moved when the arrow keys were pressed. I started making animations for the ground to move, but it didn’t look to great and skipped when you stopped or changed directions. I ended up scrapping the animations and applying a warp behavior to the ground so it would scroll endlessly, which looked much smoother but did have some slight tearing issues but not a major problem.

The main thing I had trouble with was spawning buildings and enemies randomly, and I never entirely got all the bugs out, but it worked pretty well in the end. The main issue was buildings overlapping each other, and I never entirely fixed it. Enemy AI was easy until I found some game breaking glitches in my code I couldn’t fix. I ended up just skipping it and comming back later, but I did find a solution. 

Overall it went pretty well, there were a few stressful moments where the game seemed to destroy itself and I wanted to give up but nothing to major.

Sound

The sound might have been the easiest part of the game. I used sfxr for all the sound effects and Musagi (along with a tutorial) to make the music. I’ve had complaints on the music being repetitive, due to the fact that I’ve never made music before so I just looped the 30 seconds I had throughout the entire game. And thats pretty much it for sound.

Graphics

Graphics were easy to, as I just made a sprite whenever I needed one. I decided to keep everything simple because a) Complicated art takes time and for me wouldn’t even end up looking to good and b) (basically the reverse of a) Simple art can be made quickly and often ends up very eye pleasing. Most of the graphics I made at the begining of development, except for the helicoptor blob, which I threw in at the end to varry the game a bit. Only complaint anyones had with the graphics so far is that the magic looks like blue sperm.

Conclusion

I’ve been very pleased with the feedback from people in LD14 and from others I’ve showed the game to. We’ve been having competitions in my web design class to get the high score (currently at 6000 something) and its ended with some pretty awkward quotes, to (“I had mad money but I couldn’t find a dude castle.”). I went ahead and fixed some of the problems people had with it and updated the game post LD. One complaint was that the game isn’t varried enough, to which I have no excuse. I finished the game around 4:00 on Sunday (I think) and uploaded the final version. I had plenty of time to add some more features, but I guess I was just to burnt out. I worked almost nonstop on the game, and the break I had on Saturday was to go outside on a hot day and shovel mulch for two hours. But overall I’m happy with it. I actually managed to take everything I had in my idea and work it into the game, and it worked out pretty nicely. The game is far from perfect, but I’m fine with it.

http://www.youtube.com/watch?v=9IjsHysbTUk

I can’t believe how long it took me to reboot to get rid of that Windows Update dialog, hahaha.

Next compo I’ll get the webcam going, too… much more interesting when you can see the person I think.

Shortly after the compo I fixed up the menu images, flickering graphic bug and added something to track your progress as requested by some people I showed the game to. As most of my comments here have been requesting score tracking. I thought I’d share the updated link with you chaps in case you want another go at finishing it. Usually it just frustrates you with how close you came. I still haven’t finished the game but I have it on good authority that 3 people have.

Get IT here.

Assembled out of more than 10k JPEGs, totalling almost 2GB O_O.

http://www.youtube.com/watch?v=r5iXb51buMs

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!

well, apparently i just suck a lot, because i messed up map3 on ethergrind. python’s dom chokes on it because of some malformed xml. here is a fixed copy of the xml for those of you with nerves of steel who can make it that far. drop it in the /maps directory. alternatively, i’ve just gone ahead and fixed the download link from the original post; feel free to disregard levels 3-5 if you wish when you vote.

also, you’ll be happy to know that it IS beatable. many levels, however, took me several playthroughs; notably level 2 and level 3 are fiendishly difficult. some tips:

level 2: use speed and boost through the level until you reach the last grinder. take out the turrets first and let the enemy ships you’ve dodged come back. destroy them all before trying the boss. make sure to take out the cannons before you fight the boss.

level 3: just power through with speed. this is just really hard.

level 4: for the asteroid area, concentrate on going slowly and eliminating all enemies as they appear. when you get to the grinders, dodge like hell.

level 5: make sure to pick up all of the powerups. it will give you enough to get a shield. when you get to the boss, fly straight through him (losing your shield) and keep going until there is enough space for you to deal with the enemy ships. then fly to the top and bottom of the screen and take out the turrets before engaging the boss. it’s very, very hard. good luck.

thanks for the comments, guys, all the games i’ve played are top notch. congrats to everybody!

This isn’t an official entry, since it’s way too late. You can see what I was trying to achieve and why I missed the deadline here and here. I thought I’d post what I’d made, just for fun. This is the product of about two laptop battery charges (~2.5 hours), and one hour to polish, fix the odd bug and package .. so in total it’s about a ~6 hour game made using Processing.org. The game takes 1 min to play, and I’d say most people will be able to beat it on their first or second try.

Chances are, everyone is far too busy judging the record number of on-time entries this year .. but if you are curious, you can see the details and play the game here.

Hey, everyone who commented on my entry! Thanks so much for playing and commenting!

I felt it would be good to respond, so here’s some quick answers to the comments.

(1) Sorry, I was too busy making fancy-looking graphics to do the reset button ><

(2) Sorry, I couldn’t finish the music in time, so there’s no sound! Once I regain some energy I will release a new version with sound. I think this game has legs.

(3) Yeah, the wall-switching is a bit cumbersome. I guess this is where memorization comes in – if you know the pattern beforehand or can read it quickly, then you know which wall colours to use and can set it up pretty quick. Not sure if that’s bad design… You can actually just hold down a shot button and move laterally across the wall to change all the circles at once, by the way.

(4) Sorry, there wasn’t a help screen, or it would be more obvious that there are three weapons (Z, X, and Z+X), and that each corresponds to a different colour for wall-switching. Edit: I haven’t encountered any problems with the wall-switching – maybe my explanation was unclear? An animated tutorial might help.

(5) shrt, it seems you have one of Those Keyboards. I’m not sure what the exact reason is, but some keyboards (like the one on a laptop I once used) seem to not want to register a combination of a letter and certain arrow keys at the same time. So you can’t press Z, Down and Left together. Best I can do is to put in 360 pad support, and possibly other pad support too, in the remake.

(6) All told, if you actually use all the bombs, you have 12 shots of the superweapon. This is (in theory) enough to clear the Horrible Rush Of Enemies before the boss, and kill the boss, without firing a single conventional shot, and being invincible about 90% of the time. (Edit: Assuming you don’t die before the Horrible Enemy Rush, that is.) C launches the superweapon when your wall is up, and re-summons the wall when it is offline. I was actually worried that it would be a game-breaker, but it seems it… well, wasn’t. If you’re having trouble, use more superweapon!

(7) There’s a semi-hidden trick to the game. You can operate either the spread shots or the laser simultaneously with the missiles. To do so, hold either the Z or the X key to fire the spread or laser, and simultaneously tap the other key (X or Z). This increases your firepower very substantially, but also makes your movement speed erratic, so threading a path through bullets gets a bit tougher.

(8) Have you ever encountered flying monks that *weren’t* attacking you?

Edit: (9) Muku, your comments were completely spot-on. I wonder if you were reading my mind! Yes, I realized a couple of days ago that I should have added a readme with instructions – will try to remember to do so next time. Yes, I am actually considering a more extensive remake/expanded edition with SNES-style blocky sprites (after I finish solving the more obvious issues). Yes, I did think about adding one or two ticks of acceleration, but my experience in the past has been that adding excessive acceleration to a shmup causes the player’s movement to feel sluggish – that’s probably something that can be solved with tuning though, so if I do a more extensive remake I will seriously consider it (thanks to your feedback!). Finally, the wall mechanic currently relies heavily on memorization (you switch the wall between waves to prepare for the upcoming wave); in the remake I am thinking of giving the player the choice of 2 different “wall modes” – manual and semi-automatic – where the former is the same as the current wall, and the latter is easier and more responsive but also far less flexible.

people who like my entry might enjoy this unofficial sequel a comrade of mine made using my source. it’s more of a puzzle game, often requiring planning and careful timing. it’s also a lot harder.

Big thanks to jlnr for rubyscript2exe-ing my game (latest gem update killed the good old packager)

Here is the new simple Window version (no need to install Ruby or download my huge zip)

I’m not sure how my previous Windows link got mangled, here it is again for anyone interested.  This one includes source, though they all do in one form or another.  You can check the Resources inside the OS X app for the source and the rs2e basically tars up the scripts and unzips when ran, though that doesn’t really enable you to check the source that way

Long post, more after the jump, but the headlines in summary:

• Learning from past mistakes
• Step #1: Add tile mapping
• Step #2: Add collision detection
• Step #3: Add physics
• Step #4: Evolve game concept
• Step #5: Iterate gameplay
• Step #6: Build-out and polish
• Step #7: PAAAANIC!
• Step #8: Deep sigh of relief… followed by panic

(more…)

I fixed the build scripts and libraries so that it can create Win32 builds again.

It’s still not much, but if you are interested in judging it for the compo, check the link at:
GBGames Presents a Very Unfinished Game: Walled Off

I do plan on finishing this project so that it has some semblance of game play. I really liked what I was going for and feel pretty down about how little I accomplished.

RE: Corrected link — if you want it

Sorry about that. The actual download link is http://dl.getdropbox.com/u/972220/secret_knitter_LD14_Wall.tgz