I would call my game Incoming Fodder both a minor success and a minor failure.

My goal for this competition was to create sound and music in the game, and of course it must be playable. So I made a lot of sound effect, some good some bad, mostly bad when things get crowded there are so many sfx playing it’s annoying. The music, or what you might call it (You can kill the music) was a complete failure. There was a MOD player lib for flash that I though would be awesome to use, took about an hour to get it to work.

Then I needed to create music. I suck at composing, I know it, doesn’t matter what tools I use, it’s just awful. I might have a tune in my head, trying to get the music to sound like that never ever happens. So I scribble down something trying to make it sound like music, copy paste. Crap, I better sing the tune next time.

I chose flash 9 as platform, that was good. Learned a few valuable things, like it’s not easy to pause things running with event listeners without preparing for that before you build your system. I had to skip pause, lost some time there.

Game play wasn’t as developed as I wanted. I really don’t know why I didn’t have time to improve here, I picked the idea of the game so I could spend more time on polish, but I guess I wasn’t interested enough in the idea to really devote to it. I need to be quicker in this area. I need to focus on that in the next LD.

Coding OOP is lovely, I had one moment of awesomeness this time. I’ve built a tower that can shoot arrows, then I built a castle to protect, after a while I realized that the castle also should shoot arrows, so I made castle inherit tower and voilà it shoots arrows! I did have to make it own 3 more towers to make it have 4 arrow shooters.

Graphics was the least of my priorities and it turned out ok, the defeat screen it the best of the whole game.

On 8/8/8 @ 8pm Ludum Dare 12 began, and the world would never be the same. The theme was ‘The Tower’, once again the theme ‘evolution’ was downed through natural selection. I didn’t find the theme very inspiring, but I was also brain drained from taking two finals earlier this day. I aced the classes though, so I was feeling good. One class was calculus, which probably influenced my choice of game.

I wasn’t having any particularly awesome ideas friday night, I wrote the basic “Hello, Tower” code. By the way here’s what I used:

Slow old laptop, which I’ve done all my coding on for about the past year. I like to write comfy code on the couch. Windows XP.

My IDE is Microsoft Visual C++ Express 2008, library is Allegro, graphics in Gimp.

Anyway I went to sleep without a decision at my usual 11pm, too tired to think. The possibilities I had come up with at this point:

1. Grow towering corn stalks by watering, but watering off center will cause corn to grow at an angle and eventually fall.
2. DeSprawler, pluck people from suburban houses and drop them in big city apartment towers.
3. A tetris game where you cleared equations instead of lines.

I woke up at my usual 8am, still not enthused about any idea. After lunch, about 1, I had decided on and started to code tetris. Now, I’m glad I finished it and I’m happy with it, but I could have come up with something more original, but so much time had already passed, I figured this would be simple to do in the time I had.

Also, funnily, I almost did a tetris clone for a previous LD. In LD6 (Light and Darkness) I started a game which involved working at a solar panel assembly plant. Solar panel parts would come on a conveyor belt, in tetris-like shapes (but I was going to have many more shapes) and you would pick them up with the mouse and drop them into a grid. The object was to fill as many grid cells as possible, but to make things trickier, the lights were slowly dimming, but completing a panel would raise the light level depending how much of the panel grid was filled. I didn’t finish that game in time, but now that I have a tetris engine, it would be pretty easy to finish it up to some extent. I put this into consideration when deciding on my LD12 game, which is actually not a good basis for the choice.

So, Saturday was making tetris for about 10 hours, rotation is the tricky part, I drew out all the pieces in all the positions on graph paper and typed in about 300 lines for this data. It’s all modularized so I could easily add more pieces and positions (I was thinking, tetris with 8 direction rotation, bricks on diagonal lines). I tested and got the numbers and symbols in the bricks and tried forming equations. They weren’t coming out too well, always the wrong symbols, I was thinking of giving up now because the game seemed overly frustrating. At this point there was not the tower of equations in the start. The game hardly had to do with the tower theme.

I played Notch’s entry: Breaking the Tower for at least an hour on Saturday night, too much fun, I had a few tabs of the game open and would leave them alone to just gather up resources while I coded. Note to self: there will be time to play other people’s games when they’re good and done after the compo ;] These web browser games are great, such easy distribution! This is exactly why I learned Java earlier this year, to distract people so I could win at LD ;]

Saturday night I went to sleep at about 1am, pretty much given up, woke up at 9am, lollygagged, at about 11am I decided I would go ahead and finish it. Sometime after this I came up with the tower idea, put that in, and now I was making equations! I got into it, making the equation checker, and I was doing pretty good on time. The game was a grid on a black screen with green text until about 4pm, 4 hours from the end, when I started making graphics. Making the background with help, code for level starting and sequencing, and tile graphics came pretty quick.

About an hour from the end, I remembered that in LD10.5, the game I submitted didn’t run for some people because I didn’t include any runtime libraries. So I researched that, found some libraries I hoped would work, but I didn’t actually get to test them on a virgin computer until after the end. This was because when I built the game in release mode, I got a screen full of tiles! One hour from finish and here’s the showstopper. Only happens in release, so I couldn’t debug easily, I was stumped. I narrowed it to some problem accessing the grid data, and switched _setstr to strcpy, and it was fixed! Whew, 15 minutes from the end and I almost didn’t have a game. Built my zip, wrote my post, uploaded and that’s a wrap. gg.

I’ve posted pictures of some of my meals, workspaces, kitties, and screenshots as the game was being made at a picasa album here: http://picasaweb.google.com/greencow/LudumDare12

Here is my post mortem entry. It’s a bit long so click the read more thingie to view it.

(more…)

Before the competition started, I made a list of ideas for all the finalist themes. Luckily The Tower was pretty much my first choice (along with escape) so I had a pretty clear image of what I wanted to do right away. In the end the game turned out to be pretty close to the one in my head :).

My development process was rather odd, as I did pretty much all the coding on my mac and all the graphics on my ubuntu box. I think most people would expect the opposite. The reason for using ubuntu for the graphics is that I’m used to the gimp and it kind of sucks on OS X, however I don’t have a really good reason for doing the code on the mac, I guess I just like using this machine more.

What went right:

I had a pretty clear plan in my head for this theme so I was able to get started right away and have something playable very fast. After that I had a lot of code-test-fix-test-refix-code-… cycles which I think were a pretty good way to make progress fast while not breaking everything along the way. Python is probably a good choice for this kind of development since with no compiling and linking to do I often felt free to test after even very small changes. Btw, by test I mean playing the game and trying to make it misbehave, not automated unit testing.

The game was not too ambitious. I figured it would be better to have a small rather polished game than a big unfinished and buggy one, so I tried to set my aim rather low to something rather simple but that I could pour a lot of chrome on. I feel I did pretty well here with the small details. The game was almost done on the first day and the second day was spent mostly on fixing little details and tweaking the levels.

The sound, this was the first game I included sound in and I think it worked out pretty well, I used three tools to make the sound effects: cfxr an OS X port of sfxr; say a text to speech tool; and Audacity.The level 2 sounds were recorded in Audacity along with one of the robot’s killing sound, the robots were done with say and the beeps and jump sound were made with cfxr. Then I used Audacity to transcode to vorbis.

What went wrong:

The collision code was horrible for a rather long time. I tried doing single rectangle to rectangle collisions and figure out where to place the character depending on his current speed. That didn’t work out for me as the player would often pass through walls or get stuck in ceilings when changing direction or jumping into walls. So I made a new system with two rectangles for the player, one tall thin one for vertical collisions and a short fat one for horizontal collisions. That didn’t work either despite quite some time lost fiddling with it. In the end I just made 4 rectangles for the player, one on each side, and tested them against all the walls. I feels horribly inefficient, but it was simple and it seems to work.

The levels are a background image and a list of rectangular walls, that seemed like it would be much easier to code efficiently than collision against a black and white bitmap, but it made making levels much harder. In the end I wrote a level tool that displayed the level image and let you drag rectangles onto it and spit out the list of rectangles. This made it a bit less tedious to make levels but it was still a pain.

Difficulty, since I was testing the game a lot, I got pretty good at it so I think I made the levels too hard. My girlfriend did some testing, but since she doesn’t play computer games a lot I didn’t didn’t weigh her concerns about difficulty as much as I should have.

Bits left out:

Originally I had planned to include a gun in the second level where the owl head is now and have a mass of zombies on the bottom floor that you couldn’t jump over, but in the end I figured it would break the flow of the game and that it wouldn’t be that much fun. 

Another idea that didn’t make it was having boxes the player could push around. Unfortunately I had that idea rather late and while I probably could have coded it in fast enough, I would have had to redo a lot of the levels or make new ones and that would probably been too much work. I wish I’d thought of that at the beginning since I think it would have allowed for some more interesting “puzzles”.

Finally, in my first image of the game there would have been a first level without monsters but just rather static fire to avoid. I decided to cut that very quickly though because there is no way I could have drawn decent looking animations for fire (and I didn’t add animated characters until rather late and wasn’t sure I wanted to deal with it) so I left it out. I’m not sure whether it was really a good idea since it might have softened the learning curve. On the other hand it might have been less fun and players could lose interest right away.

Lessons learned:

Make proper resource loading right away, for almost all the development cycle all the files, code and media were in one big directory and were all loaded directly. First I noticed that when the sound didn’t initialize that caused crashes so I made a quick audio module so I only needed to do error catching in one place instead of all over the code. And do get some caching as before sounds were reloaded almost every time they were used. Finally near the end I decided to put all the media in a subdirectory to make things cleaner and have an image module to cache images. Which brings us to lesson two:

Don’t make big wide ranging changes right before you release. Changing the way I loaded images was a pretty straightforward thing, but it required changes in tons of places all over the codebase. Inevitably I missed a few, usually that would be a problem because I test a lot, however I wanted to get the game out of the door, so I didn’t test it nearly enough. So the first version I released would crash in some common conditions. Thankfully it was still well before the deadline so I managed to fix it in time but it was rather embarrassing to ship something so broken.

There we go, sorry for the wall of text.

 What worked well:

• Building a good infrastructure: Clean object system & usable level editor = worth a lot. I only really started building levels around the 40 hour mark, and that worked like a charm.
• Cutting stuff in the end: Music wouldn’t have helped me a lot. Not having an ending was smart too: Everyone who noticed that must have liked the game anyway
• Ruby, together with an ad-hoc autoloading mechanism, made for one of the smoothest coding experiences ever.
• TIME MACHINE! I knew I’d need a backup system sooner or later (turned out to be true), but I really didn’t feel like bothering with Subversion because I always forget to add files etc. and it wastes time, so I just watched Time Machine do its background work every hour. Boy was that a relief.
• Periscope: While my timelapse wasn’t highly interesting, it only took two clicks to create, so no time wasted here for a low score

What didn’t really work:

• People had various problems with the gameplay (controls, motion sickness, …), and even if I knew that earlier, I probably could not have done much about it except getting into a panic.
• Needed to do more optimizing than I usually do, and some levels are still slow. Will revisit this and try to improve on this from the Gosu library’s side.
• I had a cold that made thinking pretty hard. Anything that involved maths was buggy, which caused a minor panic just before the deadline. It also made IRC very hard to follow

Next time’s plan: Keep the solid workflow, hope that the game concept works out better with regards to the Fun, and consequently Overall category, try to be more experimental technically. Can’t wait

Also, did anyone play the game with a gamepad? Would be cool to know for the next time, because it was hard to decide between a small ending screen and gamepad support in the last few minutes Thanks!

What went wrong

1. Choice of development platform, XNA studio 2.0 Beta. People were having trouble running the game. I knew this before I started but things like Intellisence, love for C# and curiosity of XNA took the upper hand. This was my first XNA game, and my first use of an physics engine. I used Farseer 2d physics lib. Having no previous experience in both fields was challenging.
2. The controls are like standing 100m away from a real helicopter with a remote control keyboard that has a delay of 2 sec. It made the game totally unplayable for most of the people who actually got the game running.
3. Too advanced idea for the time frame.
4. No guidance when flying out of scene.

A lot of these stuff are related to the physics engine and my lack of experience with them.

What went right

1. The editor was whipped up in director’s authoring app very quick. Place and size different rects and run generate() to make the xml level file. Yeah, loading levels were easy too. with xml serialization.
2. Sound effects came out great thanks to DrPetter’s sfxr program. The xna audio framework was a bit confusing at first, but it did the trick. Adjusting the helicopter engine sound along with the thrust was effective for game play.
3. Game play is really fun once you get the hang of the controls. I found myself several times playing around when there was stuff to code.
4. Code. The code is clean and got unusually many comments for a LD contribution.

Porting

So I decided to try to port the game away from xna, to OpenGL, so that more people can play it. The rendering part went fine. But then the physics lib stabbed me in the back again. It uses the xna lib. So I dug out a version that did not. But I failed again. It turns out that that lib also is xna dependent. So I tried to get the source code and remove all dependencies. But failed to grab the source. Not much energy left to de-xna it.

This was my fifth Ludum Dare (including 8.5). Before this compo I went through all my previous LD entries and wrote some small post-mortems for them, and looking back, I’ve never been particularly good at handing in finished entries for these compos. I think maybe the first one I entered (7) resulted in the most complete game. That one (which I named Pathmania: Way of the Jelly for some reason, I think it was supposed to be some obscure joke) left a few things to be desired, but it had a title screen, several levels, a random level generator and even a level editor! Shrapnel has one thing it didn’t have, though: Sound =)

Libraries and tools

I used the SDL, SDL_image and SDL_mixer libraries (which in turn uses some libs for decoding png and ogg vorbis), the rest was written from scratch during the compo. All work was done in Linux, using the KDE desktop with 4 virtual desktops. Tools I used was:

• kate: Text editor. The split view feature is great!
• gcc: Compiler and cross-compiler.
• gimp: Graphics. I always use several views of the same image when making pixel graphics, this time was no exception — one for 1x, sometimes one for 2x, and one for 8x or 16x. Sometimes I use a mouse, sometimes tablet, this time I mostly used a tablet.
• sfxr: DrPetter’s sound effect generator we all know and love. I used the SDL port which I ported myself during the compo =)
• pxtone: Pixel’s music editor (v 0.8.3.4).

Other things:

• xchat 2 and firefox: Internet distractions =)
• amarok: Music player. Tuned to Nectarine during the compo =)
• scrot: Screenshot utility, to take screenshots for the timelapse video. Worked really well, I didn’t notice it at all.

General

I had those previous half-finished entries I mentioned in mind as I started out, and simplified a few things right away. For example, I’ve traditionally used libpng directly for loading images in stead of simply using SDL_image. There’s a few reasons for this, but most of them have usually been irrelevant for my LD entries anyway, and SDL_image is a lot quicker to use than libpng. You just call one function to load your SDL_Surface from a file and that’s it.

So for this compo, I did what I should’ve done all along and went the quick and simple way, using the SDL, SDL_image and SDL_mixer libs. I think that worked out well, it took almost no time at all to set up the traditional black window with an event loop, and some image loading capabilities for good measure. I added sound later on, which was also very quick and simple. I still made the game in plain C, but I did some header magic to autogenerate loading and unloading code for resources, setting defines and including the header several times in the file that should get the handling code. This way I didn’t have to worry about either spreading things out in several places or making some fancy resource management system, just put the resource IDs and filenames in one place, and the resource is instantly available for use with that ID. I’ve done similar things in some earlier LDs, and while the headers can look a bit hairy it works really well =)

The result: Less fiddling with technical fluff, more time to work on the actual game. This was a very good thing, since I worked horribly slow and inefficiently during the entire compo and could use all the time I got. I also had major trouble getting to sleep during the compo, which didn’t exactly help (that happens sometimes, compo or not .. I’ve tried several variants of sleeping pills before, but none actually work on me for some reason). So, I ended up wasting more hours just lying in bed trying to sleep, during the night, than I spent actually sleeping, which ended up being during the day. Ugh.

I also spent some time porting DrPetter’s sfxr tool to SDL and Linux, since the Windows version had some issues when I ran it in Wine, and I was determined that for this Ludum Dare, I would have sound in my game or die trying. The porting work was done entirely during the compo, so that “wasted” some time too, though I don’t really see that as a waste of time since I ended up using the port to make some really nice sounds that I feel add a lot to the game. Similarly, the time I actually spent sleeping, eating and going outside for some air was time well spent, I doubt locking myself in the room for a 48 hour marathon would’ve resulted in a better game. On the other hand I could’ve really used some of that time to make more and better levels. The short and crappy levels are, I think, Shrapnel’s most major flaw.

What went right

Well, I made a playable game, and I think it’s kinda fun despite its many flaws =)

The food I ate during the compo was great, probably the best I’ve had during a Ludum Dare so far. One of my flatmates made us lots of delicious food =)

I kinda like the graphics, too. It’s not amazing by any means, and the ship designs are perhaps somewhat uninspired standard fare, but at least they’re not plain ugly =). The graphics was made in Gimp with my tablet. Before the compo started I had some serious issues with the tablet in Gimp, so I was afraid I wouldn’t be able to use it. Gimp would freeze, crash, make all tools behave like the “move layer” tool, and generally misbehave in any number of ways. Thankfully these issues magically disappeared the day before the compo started when I compiled GTK and Gimp from source and installed that in stead of using the distro’s packages.

The sound effects are great, which I have DrPetter’s sfxr tool to thank for. The time spent porting it to SDL was time well spent in that regard =)

I also like the music, which I made with pxtone (pxtone works well in Wine as long as you touch .ptcop files before saving them, since only overwrite works). I was equally determined to get some music in the game as I was about the sound in general, but initially I didn’t have any musical inspiration at all. I tried to make some tunes, but everything I did sounded like crap (specially since I don’t really know any musical theory, it can be a bit hit or miss). I was ready to give up and continue making the game — this was during the last hours of the compo, there wasn’t much time left and I really should be spending time on more important things than trying to make music — and even switched over to the code desktop, ready to do some coding again, when the whole tune suddenly popped into my mind out of nowhere. So, I switched back to pxtone and, according to the timelapse images I’ve got of my desktop, the primary and secondary voice was basically complete in literally three minutes for the first half, four more for the second half, note for note what you hear in the final tune apart from some minor tweaks I did later. That includes time for listening to it a bunch. It was so weird! I did spend some more time with it later, added the drums and such (and made the ingame background thing), but the whole thing was done pretty quickly. Most of what you can see of the pxtone window in the timelapse video (below) is actually rejected tunes, listening to it, and doing and undoing small insignificant tweaks =)

What went wrong

I already mentioned a bunch under General, so I’ll skip that here.

By far the two biggest complaints I’ve seen about my game in the comments have been that the game is too short, and that there’s not much connection to the chain reaction theme, and both of those are really at least partly because of the levels, or lack of, and their design. Actually calling it “level design” is a bit of a stretch since I didn’t really put much thought into their design at all, there wasn’t enough time. They were literally thrown together at the last minute. For the next compo I really need to set off some time for level design, or make some game where level design isn’t so important.

There really are chain reactions in the game, I made the game with the idea in mind from the start — when you kill enemies, they send out shots that kill any other enemies they hit (or you!), which again sends shots when they die to kill yet more enemies, and so on — it’s just not very apparent that they’re there since the level design I mentioned doesn’t really take advantage of the fact at all, except perhaps for this one place. So, there’s not often you actually see chain reactions happening unless you’re both lucky and work really hard at making some. Originally I wanted to have a bit more advanced enemy behavior too, with them floating around the screen for a while before going on, going both left and right and upwards in addition to just down, so that you had to choose both where and when to shoot to make the most chain reactions possible. I’m sorry I didn’t get around to that, because I think that that would definitely have been a much better game. However, that would also have required good level design, and even with the current enemies I think that some decent level design, levels to really set up potential chain reactions, could have had an impact.

Also, the scoring system could use some work perhaps, but the effect the chain reactions have on the score isn’t really obvious in any case (see next section). There should have been some visual feedback when combos happen and such, or at least a mention in the readme in the slim chance that someone should happen to read it.

There’s also a few bugs that slipped through. The most apparent one is probably that the last level sometimes ends before you get a chance to kill the last few enemies, so you win the game with enemies still firing shots at you =). Another bug is that the Alt test when pressing Alt-Enter for fullscreen doesn’t actually work, so you go into fullscreen just by pressing Enter without Alt. Maybe that’s a good thing though, since the fullscreen toggle is undocumented and it’s easier for people to accidentally discover it that way =)

Another undocumented feature is the joystick support. I wonder if someone used it?

Last words

Overall, I think I’m going to call the game at least a partial success. I didn’t get done nearly as much as I wanted to or even could have had I been more efficient, and the levels are a huge detractor, but it’s still kinda fun to play, and I like it =)

By the way, it actually is possible to take advantage of the chain reactions for higher scores if you’re just aware of the scoring system =). I think my record is around 11800 or so.

First, you lose one point for every shot you fire, so if you want high scores it’s in your best interest to not just keep firing, but choose somewhat more carefully where and when to fire.. like a bleak shadow of the original intent with the smarter enemies, heh. You only score 1x the points for each enemy you kill yourself, but enemies killed by the death fire of other enemies get a combo multiplier — 2x for the first one, 3x for the next, and so on. Score is also multiplied by the current level number.

Or, if scoring’s not your thing, you can also try to beat the game by not firing a single shot =)

Timelapse

Finally, here’s a timelapse video of my desktop during the compo. I turned off the computer when I went to sleep, since it’s a bit noisy and is in the same room as my bed, so it’s broken into three parts. I use four virtual desktops, you can see which one I’m in in the little indicator at the taskbar if you look closely. During the compo I used the top left mostly for code (kate), top right for graphics (gimp), bottom left for IRC (xchat2) and internet (firefox), and bottom right for sound (sfxr) and music (pxtone) and sfxr porting =) (except for day one, when sfxr porting was done in the top left desktop).

There’s one screenshot for every 30 seconds at 30 fps. I used scrot in a shell script loop to take the screenshots in the background during the compo, and then mencoder to combine them into this video.

Hm, looking at this I seem to be doing a lot more work than I actually did. Like I said, inefficient..

Now before everyone’s going into hibernation again here’s a small Post Mortem for Chain Reaction.

First i was not sure i was actually going to enter. I’ve partitiated in a few Ludum Dare’s before, but usually only when i could really use the full time. This year round that was not the case. I didn’t even reserve some extra timeout from the family.

Still, once the theme was up i couldn’t help it. I strived for a rather simple game (simple as in simple to make) since any greater planning would go down the drain anyway. I’m rather glad how it worked out. My entry is not particularely innovative but things fell into place pretty nicely.

What went right:

• Having the general gameplay up and running as the first step

This is actually the most important part for these kind of competitions. If you have a flaw in your gameplay design you still have time to refine it. It’s no use having nice technical gimmicks all around when the gameplay is crap.

• A working editor

If a game is level based it’s one of the rather convenient things to have. Sure, with the given time nothing stops you to hardcode level data or even store it in some text file. Once you have an editor you can churn out levels at an alarming rate. And it’s a nice polish plus for the final version.

•  Sound effect (thanks to DrPetters awesome tool)

Usually one of my bad points. It’s easy to use a microphone and grunt/hiss/snarl some stuff but it also sounds exactly that way. DrPetters tool is a most awesome help as you can experiment and modify in just a few clicks.

What went wrong:

• Innovation? We don’t need to stinkin’ innovation!

Not thinking too much about what to do i was glancing over the first shots of the other competitors. Lerc’s shot looked very nice and i thought about these circles being bombs. I’m glad that the gameplay came out very different though.

This was my first ludum dare ever so I didn’t really know what to expect of it. Also it’s my second little-time-internet-game-compo ever, the first one the last pyweek. I think it was my 3rd or 4th game I’ver ever made, but I’ve programmed other stuff before so it’s not all new to me. All that considered I do have some things I wished I could have done better..

Bad things (in no particular order):

• The choice of using Glut to draw fonts, because I was lazy. This led to my game being impossible to package and I think I missed out on some ratings because of it. ( I updated it with new font-rendering and working packages after the compo was over though). This choice was made purely because I was lazy, i didn’t know any other way to draw text in opengl so I ran with it.
• Taking too many breaks.. Yup, I took breaks. Plenty of them, I even played some games! Now, this is not bad, you need breaks every now and then to function properly. But taking to many will throw you off just as well, and of course leave you with less time to work.
• Not spending time on art. This was a big mistake, I started out with boxes for everything and that’s pretty much the way it ended up in the final game.I should have taken the time to make some ugly sprites, even that is better than boxes.
• Not leaving enough time to make some decent levels, I think the game could be great fun IF it had some fun levels. And I should have made a better ’system’ for loading levels and controlling the enemies.
• Using single-point particles as an explosion effect. Doing this in python, the quite possibly bad way I did it, turned out to be slooooow. Who would have guessed? Had I gone with something else maybe it would have run a bit faster. Also drawing lots of points in opengl immediate is slow in itself, should have bother being more fancy with it.
• Thinking “I can’t do that, I have no idea how to do it and I’m not a good enough programmer” too much. Turns out I sat around thinking about stuff I thought was really hard to do, that were in fact simple to do once I started. Not because of me coming up with a great way to do it, but just because the problem was simpler than I had imagined and/or I was not as daft as I thought.

Some good things:

• The idea! I liked the idea and had great visions for it, but the way I implemented it was no good and the game ended up being pretty dull. I might revisit it later and make something out of it. Done right I think you could make people spend some time on it.
• I finished! I’m very pleased I actually made a somewhat working game in 48 hours, I’m really pleased with that.
• Explosions, I think it looks really cool when you chain together a long line or a big bunch of bombs. And that’s what matters most…right? right?

That’s pretty much it. I really loved doing this, it was great fun and you are all nice people. I will be back next time, hopefully coming up with something better.

Oh, deskphoto! It’s a bit late, but better late than never. (Beware of dust)

Well, not much to say about this entry … I used pygame which was a good choice as usual.  I broke my level into MVC components, which really didn’t matter much, but it was interesting to do.  (I’ve usually done my games as just a single blob.)  It didn’t take any more or less time to do, so I guess I might as well do it, since it makes enhancing a game that much easier.  (Galcon is just one big blob and it’s somewhat painful to work with sometimes.)

The gameplay was the first okay idea I had.  I think half the fun is not playing the game, but messing around with making a million fuses go.  Originally I had it so you could set up your fuses and then light them yourself, but the gameplay seemed pretty slow.  I made the fuse auto-light to give it a more arcade feel, which I think worked.  However, the gameplay isn’t really “great” but I think it’s passable.

I had most of my fun drawing the backgrounds for the game.  I figured since the gameplay wasn’t the strong point I’d go for broke on art.  However, I’ve been in a bad mood about python+C integration the last few weeks so I didn’t feel like writing a particle engine in C, so my explosions ended up being really sorry.  I wish I understood blender so I could render stuff with that, but I don’t use it often enough to retain memory of how to use such a crazy interface.

My sound is usually a pretty strong point.  This time it was a bit weak, I just cranked out a chord progression.  I had some intentions of adding in a viola track over that, but didn’t feel like it.  The sfx were made with SFXr of course.  Really cool tool!  It saved me the bother of recording my handmade effects, which since I was feeling lazy was good.  I prefer to make my own, but it was nice not to have to this time.

Anyway, that’s about it.  Hope you had fun with the game.

(Hm, got bored at work, so an extremely lengthy post-mortem following..)

Post-Mortem

LudumDare 10 entry “Lunte” by Allefant

Introduction

I have yet to analyze the over 3GB worth of automatic screen caps, but I think I spent about a third of time each in IRC, coding, or working in Blender. Rather minor amounts of time were devoted to idea research, making sounds in SFXR and making music in LMMS.

Audio

In fact, my music is somewhat of cheating, as I used an existing melody, and further, an existing .mid file including 2 additional scores to the melody, cords (or whatever, I’m no musician) and percussion. What I did is just fiddle in LMMS to create and assign instruments.. I gave a high pitched square wave to the main melody, a piano to the cords, and since LMMS decided to simply lump the midi percussion notes into one channel, ignoring the MIDI assignment, some wooden sounding neutral percussion to that. As for in-game sounds, I used SFXR by DrPetter, which simply is incredible - in last LDs I was running an old SimSynth through Wine to get some poor sounds, now (also thanks to mjau) I have a native app with all those randomization features making sound generation much quicker.

Video

Since sound is covered, next to graphics. My tools were Gimp and Blender. But most of the visible graphics are Blender renderings. I do know by now how to set up a simple “armature” to get stuff animated. I still have no idea what the difference between the three windows IPO/Action/NLA is and why some of them are empty some times and sometimes not. And very likely connected to that, I can’t figure out how to give separate animations to separate things (like, doing the feet animation independent of the head animation, in the same armature). With everything downscaled to 640×480 pixels, not many details were necessary anyway though.

One thing which proved somewhat challenging were shadows. I decided I want to have them separate - since two tree sprites next to each other looked somewhat odd otherwise. Suffice to say, I had to resort to Blender’s Python-scripting capabilities to have a script which fiddles with material parameters - for the non-shadow version, disabling the shadow, for the shadow version, setting all materials to “cast-only” and a special “shadow plane” to “only-shadow”. The result is, each of my graphics has two versions, the shadow and the rest.

The biggest challenge however was the explosions. I learned some about particles, soft-body and the deflection setting in Blender. One thing I wasted time on was when I tried to get the explosion to cast a shadow - Blender simply can’t to that (yet?) - particles can receive shadow, but not cast it.

Code

Now, finally, to the code. I ended up not using pygame but my C-disguised-as-Python language and my custom library. Which for someone who wants to compile means, the following dependencies are required:

• allegro window, input, timers
• allegroglopengl context in above window
• DUMBmod player, actually not used, but i found no time to edit it out of everything
• OpenGL, FreeType, png, z, jpeg, ogg, vorbis, vorbisfile

After that, it should be a matter of compiling all .c files in the “generated” folder and linking to those library. I provided the Makefile I used for cross-compiling the .exe.

The actual code I have written is all in the src directory, little more than 800 lines. I love the Python syntax for that, even though the code is rather hackish and there’s no comments, the forced indentation makes it still easy to follow. There’s nothing really special regarding the gameplay, it’s a rather simple puzzle game, done a 100 times. I made one huge list of all objects (santa, trees, bombs, wood), then pass it to the C qsort function to sort by layer and by y position, then draw it.

The challenging thing was the water/ice/snow layers. The straightforward idea was to first draw water, then where there is ice draw ice tiles, and finally snow tiles. It just would have meant, if there’s a snow tile at x/y, cut that tile out of the snow texture, and place to the screen. However, I wanted to use an alpha mask for the cutting out - but OpenGL 1.0 does not allow specifying a separate alpha channel. Which would have left me with some texture combine extension, or a fragment shader. I read up a bit on fragment shaders, but then finally went for a software solution, re-calculating the water animation with possibly ice and snow in front each time level geometry changes.

Game Design

One thing I totally neglected was level design. The game I cloned apparently lived from the clever level design, giving you hours of puzzles. In my version, there are no real levels, basically just 13 tutorial/test screens. I guess I could try and find a ROM of the original then rip out the levels. Or try to create some challenging levels myself. In any case, when doing a puzzle game in an LD48, time for level creation must be factored in. It’s hard enough doing platformer levels in short time, but for a puzzle game it’s crucial.

Conclusion

In a way, not having the least bit of originality haunted me throughout the competition. I wish now I had thought more about my initial chain-of-lights on xmas tree idea (all the xmas setting is a remnant of it), then could have spent the time creating explosions and break-able terrain on implementing that idea instead.

Ok. Managed to upload and post the thing properly, so now I can relax and write some stuff about it.

This one was a shaky ride for sure. Throughout the first day I kept a laid-back attitude and sort of held a leisurly pace. Spent a lot of time on IRC and elsewhere, but still got a fair amount of code done. Second day started well, with some bugfixing and new implementation. Halfway through though, I started realizing that I didn’t really know exactly where I was going with this in terms of gameplay, and sensed a wall rising before me.

I was stuck for a few hours incabable of deciding what direction I should go with things and actually considered (briefly) forfeiting the whole thing… I came to my senses though and decided to salvage it as best I could by making some fun gfx and audio. As soon as I got a “living” player character and some sound effects in there it suddenly felt a whole lot better. I should have done that way earlier. With just one or two hours left on the clock I was all inspired again… dang.

The last hour was a blur of stressed music-making, panicked code-juggling to get it playing in the game, and some begging to get a few minutes to wrap things up in a respectable manner before making the final post. But it worked out in the end (sort of).

I just wish I could bend my sense of time/planning to actually fit reality a little better. I always act like I have all the time in the world until I’m literally running right out of it. THAT’s the point where I start doing actual work, and kicking straight into highest gear. If I had started working on the media 5 hours earlier (back when I didn’t do much of anything anyway) I would have had time to properly tweak things and maybe make a “good” song rather than a doesn’t-quite-make-you-rip-your-ears-off one.

Anyway, despite the little crisis and gloomy bughunts I will remember this compo fondly. I did have a lot of fun on IRC over the first day and a half, and the last pull-together of stuff for my entry made all the difference between a sense of failure and modest accomplishment. The final product didn’t end up being a proper game (as usual) but at least I’m not embarrassed of it.

I have an exam in 2.5 hours that I neglected studying for, so I’ll just sleep for a bit instead I think. Life’s tough, but you need to get your priorities straight… I’ll re-take it in March or thereabouts.

As for food, I don’t hold any sort of lightsource to the grand masters who have been posting here, but I did consume something like 10x the amount of sugar that I’d normally do over this time period. Lots of candy and soda, yuk. My tummy doesn’t quite like me atm. Also downed some chicken, pasta, vegetables and milk (which constitutes my staple diet) - and pilsnerkorv!

I kept a slightly more detailed/rambly timelog in my main.cpp which is included in the submission zip. Check it if you’re interested. Oh, also I forgot/neglected to put in some library code that’s needed for the game to compile… tinyptc, portaudio and playmu (which is my sort of in-development musagi playback library, used it for LD9 as well). I don’t see much point in uploading them at this point, but they’re available to anyone who might ask. I’ll have to clean up playmu at some point and upload it to my homepage properly.

Looking forward to checking out all the entries soonish, after some R&R. Congrats to everyone who joined/tried/failed/succeeded!

The theme for LD 9 was “Build the level you play”. The premise is that you’re some god or something whose sole purpose in life is to control the path of some space fish, guiding them through gates that changes their colour, and get at least some set number of fish to go through the spectrum in each level. You control their path by creating planets, of course. Planets attract fish using the laws of gravity.

This is actually the first game where I’ve used OpenGL, apart from some small fiddling. (This also made it easy to make the game window freely resizable with hardware scaling, and I made sure the window always keeps the correct aspect ratio by inserting black borders where appropriate. Incorrect aspect ratios are always annoying.)

That aside, this one didn’t go very well. I spent a lot of time just fiddling around with insignificant things and not getting any parts of the game done, and about midway through I changed the aesthetics from creepy-ish paper-cut-outs floating around — something which at least looked somewhat interesting — to badly drawn space fish, and also inverted the planets, for reasons which completely escapes me. I had also coded up an in-game level editor that I used to create the included levels, but this was disabled for the compo release. For a compo where the theme was “build the level you play”. WTF?! Why did I do this? I have no idea.

The gameplay itself also had its issues. I think I made the gravity a bit too “realistic”, since inserting a planet subtly effects everything — so it doesn’t really matter if you’ve fine-tuned your existing planets to perfection if you have to insert a new planet or even move an existing one, the new gravity will upset the fish and you’ll have to fine-tune again. So, while the gameplay can be fun-ish for a little while, the constant required adjustments can quickly get annoying.

After the compo I played around with visualization of gravity by using a GLSL shader, which made the game somewhat more interesting (not to mention extremely colourful). Another thing I tried, both during the compo and after, was making the planets be effected by gravity, so they’d float around too (until they collided and launched themselves at light speed off the screen), and also make the fish generate gravity, attracting other fish and planets. Somewhat fun to watch and play with, specially with gravity visualization enabled, but the game was pretty much impossible then, heh =)

Download [ Windows/source code ]

My entry for Ludum Dare 8.5. LD 8.5 wasn’t a 48 hour compo, we only got 24 hours to make the game in, but the start time was flexible so you could choose the 24 hours of the weekend the compo was held that was best for you. I managed to use exactly 24 hours on my entry =)

Themes were Moon (actually “But even if you doubt their overwhelming findings, the Moon will never be the same to you again. Never will you raise your eyes to look at her without wondering: IS IT OR ISN’T IT AN ALIEN SPACESHIP WORLD?”, but everyone interpreted it as just “Moon”) and Anti-Textmode, no text at all in the game.

The story, which you have to guess at since there’s no text (and the readme is rather sparse), goes: You’re a rabbit, minding your own business on the moon, when one day a butterfly comes flying from somewhere. It flies straight into a crater, which happens to lead to a huge system of caves beneath the surface. Curious rabbit as you are, you follow it, and so the game begins.

When I started making this I actually intended to make one of those bullet hell shooter games, but for some reason the game evolved into this cave-flying exploration game in stead. Or, well, calling it an exploration game might be a bit of a stretch since there’s only 5 rooms in the game, not counting the exit room (which is a very quick drawing of what’s supposed to be me in my bed, getting a good night’s sleep after 24 hours straight spent coding and drawing), but it would have been if I had spent less time fooling around with the code. For such an art-heavy game you’d think most of the time was spent drawing things (all the rooms are just bitmaps, there’s no tiles), but I actually spent most of the time on code. So, the art didn’t take much time, which kinda surprised me, though of course everything being lores greyscale had something to do with that, and I did rush it a bit too. Anyway, doing the art was a lot of fun.

So anyway, you fly around in this cave system, collecting flashing ring things to open gates while avoiding monsters and projectiles and such. It’s a shame the game is so extremely short, because I really like it and think it could be a good game with some more work. Maybe I’ll get back to it sometime =)

Download: [ Windows | Linux/source code ]

This was my second Ludum Dare entry, for LD#8. Theme was swarms. This time you’re playing the Master of Fireflies, out for revenge against some mushroom-dwelling things who didn’t invite you to some insignificant party last week. So you send your swarm of fireflies after them to torch their mushroom homes. That’ll teach ‘em! The mushroom-dwelling things doesn’t take kindly to this though, and starts spraying water around, which unfortunately kills your swarm and stops the mushroom fires. The battle is on!

This was the first time I made something with a swarm-like behaviour, which was nice. The game turned out ok, though not really finished — those mushroom-dwelling things only ever face right, for example, and the levels weren’t supposed to be that flat. There should have been platforms and stuff. Still, there’s a win condition and level progression and such, so that’s something at least. Anyway, it’s kinda fun-ish for a little while, torching mushrooms while those poor guys losing their homes at your hand try to kill off your swarm, but it gets boring and repetitive after a while.

Oh well, I had fun making it, and learned some new things in the process, so I choose to consider it a success regardless =)

Download: [ Source code ]

This was my entry for Ludum Dare #7, which was the first LD I entered. The theme (growth) eventually gave me the idea of growing a maze.

So, you create the maze as you walk around inside it. When the game begins, the maze is just a set of disconnected squares. Each of these squares can be linked with a set number of its neighbours (how many depends on the square, from none to four), and you create new links by walking from one square to another where there’s no previous link. Once a link is created it can be walked on as much as you want, but a link can’t be removed once created, so you have to be careful when creating your maze so you don’t get stuck.

Once I had that working the deadline was looming close, so I threw in some keys and locks and made the objective to clear all locks of each level, to make the thing resemble an actual game. In the end there was four levels, a random level generator, and also a level editor.

I wrote in the original README that I’d continue to work on the game, something I haven’t done. I still like the general idea behind the game, but it has this tendency to degenerate into just staring at numbers, which isn’t very fun at all, and on top of that it’s easy to get stuck, having to restart the level if you don’t pay attention. Perhaps some of the extra elements I didn’t have time to put in the game for the compo — more tile types, powerups, bombs, enemies — would have made it better (more varied if nothing else), but I think the interface is the main problem. It should be more obvious what tiles can connect, how many exits are left, etc, so there’s less guesswork, no number tracing, just puzzle solving. Since the levels are so “dynamic” getting that to work would be tricky, though.

Download: [ Windows | Linux (x86) + source code ]