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!

This postmortem covers my experience with the 10th Ludum Dare 48hour game competition, in which I won a Silver Pelly in the Technical category.

Summary

The theme for the competition ended up being 'Chain Reaction'. This wasn't really one of my favourites, in fact, it was amongst the themes that I wanted the least. I think my dislike towards the theme is pretty apparent in the final result, as it doesn't feature traditional "chain reactions" as seen in most of the entries. Taking that aside, the "game" (quotes because it's more of a toy) turned out pretty good I think.

As soon as I discovered the chosen theme I began the hunt for ideas, and just like most of the other entrants I tried hard to think in different directions than what had already been done (match3, boomshine). From the get-go I knew I wanted to do something in 3D, simply because I figured most entries (if not all) would be 2D. This was a silly decision, considering the gameplay I ended up with would have translated very well to a 2D setting, and would have saved me a bunch of time which could have been spent on polishing. But anyway, having it 3D allowed for a couple nifty little features.

It didn't take long for me to decide that I was going to use spring physics in some way or another. But knowing what a pain it is to implement and use springs, I knew the usage had to be something really simple. I honestly don't remember the idea I initially went for, but somewhere along the road, while implementing the physics, I discovered how fun it was to swing this snake-like structure around using the tail as a wrecking ball of sorts. With this discovery I figured I might as well do something with that.

There were lots of possibilities bundled with this discovery, like for example I could make it a fighting action game where you use your tail to bash down enemies, with possible chain customization included. Or, you could use your tail to collect stuff scattered around on the playing field. As said, lots of possibilities based around it simply being fun to control the motion of the tail.

I guess it's true that games are emergent.

Ultimately I ended up with a game about "snake-like creatures using their tails to bash a ball around a soccer field in hope of hitting the opponents goal" that had close to nothing to do with the initial idea. (Which I don't even recall what was by now - I guess it wasn't very good!)

What Went Right

I'm really happy about these, and they were really simple to implement!

I still find myself enjoying swinging them around, so these were a definite success.

The mouse control scheme is probably the one feeling most "right", and is quite easy to control, in my opinion. Same goes for the gamepad scheme.

What Went Wrong

This competition is generally not very friendly towards microsoftian technologies, thereby making distribution a living hell for anyone using them. I knew this beforehand, having participated before. I chose to use them regardless as I feel much more confident in the use of them which makes me able to produce stuff faster.

This was a bad decision, but I did not feel I had the time to figure out a decent AI solution for the enemy opponent. Even now there's no obvious solution that pops into my mind when thinking about it, so even though it was a crippling decision it was probably the right one.

Waste of time and effort. The springy goals are often not even noticed, and has zero impact on the game-play.

They suck. Nuff' said. Unfortunately, as far as I know, there's not really any way of having keyboard controls that feels right for this game.

Conclusion

It was a very good competition this time, and it went very well for me. I produced a whole lot of stuff during the competition, and ended up with a nice little multiplayer toy that I had some fun playing.

However, the game did not really make great use of the theme, and in a similar fashion did not present any new and awesome innovative game mechanics. Another downside is that I tend to end up with half-games; that is, games which lack polish (menus, game states, help screens/information) and are therefore basically just toys.

"Use the Tail, Luke!"

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 ]