My setup

My video card unfortunately only supports one monitor, but I like my setup. I will not be using the 360 in the corner there. Nothing really special. I have a tablet, but I lost the pen Just a keyboard, mouse, headphones, and 23″ widescreen monitor.

Less that 4 days to go!

Here it iiis:

Windows version: http://www.raschke.de/julian/temp/ld14_final_win_jlnr.zip

Mac version: http://www.raschke.de/julian/temp/ld14_final.zip

Source code: http://www.raschke.de/julian/temp/ld14_src.zip

Not much content—sorry—I lacked direction and worked much more iteratively than before. Only really worked productively during the last hours. But I managed to do some nice little tricks using just a 2D lib

Enjoy!
(Reuploaded the next day because the original wording was unintentionally offensive in one instance. Didn’t touch the rest.)

18:11
Ice drawing is *really* done. Or at least I hope, because it’s starting to piss me off.

19:56
Bullets have sprite and particules. So cool.

22:11
Eating. Have starting producing sprites and arranging the interface of the game. It is taking too long. TOO. LONG.

Mmm, pizza ham-pineapple, an apple, and some of the best chocolate in the world. I am now ready for the last 7 hours. With Queen as musical background I can win this compo. Definitely.

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!

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

- 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

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 )

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

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

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)

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

Check it out.

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.

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

Edit: Mirror