I’ve written a postmortem for my LD10 entry you can see it on my website here. I’d repost the whole thing here, but I’m lazy.

WOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO!

Game Development!

Finally I’ve ported it away from XNA to OpenGL, still got the (almost) same lousy controls, for your pleasure. Still needs .Net 2.0 to be installed though, but should be compatible with Mono, and thus playable on Linux. If someone like to try to compile it on Linux, contact me. Some things have been tweaked and added. But the game play is the same. Added ugly clouds for better sense of height movement. Updated the physics lib to the newest version.

Arrows: (over) steer

Z: Claw claw claw!

X: TURRRRRRBO

Space: Reset heli position

R: Reset level

N: Next level

Download now! 441KB Now with dependencies included!

Only 4 people rated my game. Thats unacceptable, I need get rid of XNA. So I’ve thrown all XNA stuff out of it. I needed to poke a bit in the source of the physics lib as well to cleanse out the filth, thankfully that was easy. Now I need to tame the horrible controls (That was my fault, cannot blame XNA for everything), and then pretty it up and I’ll make a release. I plan to port it to linux too, with Mono.

I’m only using Glfw, OpenGL and .Net 2.0 as we speak. For sound it will be OpenAL.

Did not quite make it in 2007, but here’s Partycle Popper 1.5

- Pretty much recoded based on cleaned up basecode which was based on the contest version of the game
- The widescreen bug fixed

- Audio recoded using SDL audio instead of fmod to make porting slightly easier
- Custom mixer for sound fx and midi instruments
- MIDI player (only supports one instrument and note on, but hey, it works)

- Gameplay tuning;
- Player’s bullets and bad pop bullets are faster, normal pop bullets slow enough to dodge around now
- Scoring is slightly tuned
- On player death, the same level is restarted with the same score as when the level started
- Couple new hint lines, and couple informative printouts here and there

If there is an LD11.

OK, at the moment I’m learning how to code in C++, is that a recommended language to be used in LD11?

I’ve tried to look at the pros and con’s, and found:

Pros:

1. It is Object Orientated, which may persuade me not to use plain structured and a loop.
2. It is a compiled language, so it should be easier to make it cross platform
3. It should run faster as well
4. It is great for text based games

Con’s;

1. I’m not great at it
2. I have no idea how to GFX in it
3. I’ve not touched the language since 2004, and the whole thing was different back then.

At the moment it looks like the pros are greater than the con’s, but, is it a better language overall?

I mean python is written on top of C++, so that means that the person who made Python can’t of been to happy with C++ if he made is own one, either that or he was bored.

If python is written in C++ then That could mean that it is an ”improved” version of C++, leading me to think that that is better.

However, I already know python, so it would be a good learning experience for me to learn C++, and someone gave me a Sams Teach Yourself C++ in 21 Days, so I’m trying to learn that. (Not the average item on a 12 year olds list )

---

Also, I may be making a text based game next time, is it worth it?It would take less time, I’d imagine, and I don’t know how to do GFX in C++.

---

Please replyas a comment, awaiting your replies.

Since people are posting pellies, here’s the one I made last night:

(slightly tweaked)

Well, this started as a clever idea.

One of those drinking birds, with a pelican beak, drinking from a trophy. Alas, it really looked terrible, so I hacked it somewhat, creating this slightly more carnivorous scenario.

The idea was to use something iconic embossed on a medal.

inspired by PoV’s posting of this:

I created this pelly (admittedly useless as an award):

Someone asked for a pelly. I made one. It’s simple and boring, but I suppose it’ll do if nothing better comes along.

Here’s a psd file with suitable layers for making variations to suit all the themes: pelly_layers.psd

(I’m too lazy to do them now)

I made a new level for Mr.Splode — good luck!  To play it, copy it over level 4 and then press 4 from the title screen to play the level.  I’ve also made it compile under linux .. you can grab the new .c and .h from this zip as well.  To compile:

gcc -g mr.c `sdl-config –cflags –libs` -lSDL_mixer -o mr

Check it out.

Okay well .. it’s been a bit of work, but I got one together. Unfortunately, youtube wouldn’t take it. I think it had something to do with something to do with something. Which, means I need to upgrade linux to get … blah blah.

On the more interesting side, I wrote a linear video editor for the task in pygame + pug. It only took about 90 minutes to make the editor. The rest of the time was struggling with encoding issues. The editor works pretty good and plays music along with so you can get things synched just right

The program takes in a list of .png files (movie.txt) and lets you cut out chunks and do other things with ‘em. Here’s the video. It’s got great music - thanks to DrPetter’s brother!!

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..

I tried writing a post up in this thing but It kept on trying to eat it so I put my post-mortem here

I had to close proactiveapathy.com. So you’ll probably have trouble downloading my stuff until I find alternate hosting.

Edit: Mirror

for anyone who wants to keep tabs on me, stalkers and lurkers included, head over to:

http://www.gamedev.net/community/forums/mod/journal/journal.asp?jn=270089

hopefully i’ll be back for more LD madness if there’s a number 11.

yes, its a whiteboard. no, its not especially exciting. but! if it weren’t for LD10 and lerc’s youtube of his room, i never would have realized I NEEDED IT SO BAD IT HURT. so i wound up getting it as a gift from my folks.

this is the result of a chain reaction caused by a simple competition. a chain reaction of LOVE. thank you, everyone in the LD community! happy holidays to all of ya!

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.

Well, not exactly, where do you download py2exe, and how is it run?

Anyways there is aa little story to the game, but, I never released it, also I did make the laser move towards in the last few mins before I uploaded it, but, it was so buggy, I removed it.

The story is as follows:

Youare a cycling maniac, you always knew one day it would get you into trouble, and it did, you got trapped between two pillows (Iwas going to make the pillow further back and stop you moving past it), and a laser was there to, if you hit the laser at a low speed your chain would react to the laser, weakening it, aka, making you lose a life.

If you went quickly past the laser, it would react differently, giving you back your life.

You had to see how long you can last without dieing, it’ll be a challenge with an always moving laser!

And who is shooting the laser at you?

Aliens from outer space.

Also in LD11, I’m planning on using C++ is that recommended?

Graphics - MS Paint

Sound - SFXR by DrPetter

Music - Reaper mostly, but the music didn’t make it into the game

Coding - Mostly Python IDLE IDE

Libraries - Python and Pygame

it was a fun competition!

Next time I won’t wait until the second day to start, I underestimated how long it would take to implement my game and I ran out of time.

Didn’t know about this.

GFX - Gimp

Language - Python/Pygame

Sound - Didn’t have anny

Developer - Gedit (I started with DrPython, but quickly got frustrated with it).

Tools I used!

• GraphicsGale - Art / Graphics
• SFXr - Sound (Yaay DrP)
• Komodo Edit - Python (and others) IDE
  • Komodo ran really slow for me. Someone on IRC said I could turn a bunch of stuff off to make it faster. I use Ecplise sometimes, but I can’t get my Linux install to run it right. I need to just use Xemacs.
• python & pygame
• pen & paper: Ideation

I intend to post a follow up as soon as my family visit settles down a bit. If I could do it differently I’d probably pick a different graphics program that works on Linux As it was I had to transfer graphics from my laptop to my desktop. And, as I mentioned above, I wasn’t happy with Komodo Edit.

Tools of power:

• kate - text editing
• gimp - image editing
• pen and paper and scanner - graphics creation
• python + pygame
• gaim + firefox - time wasting
• SFXr + modplug - sfx & musix

All in all, a good combo. Next compo I need to get over my angst against python-c integration and go back to SWIG or something (like I used in Galcon to get the swarms and effects)