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)

I guess people are posting tools lists… so I shall join in!

I used MSVC 6 (yes, 6!  Not 2006 or whatever), The Gimp, and SFXr.  Chatzilla for a whole lot of IRC action.  Probably Notepad for the readme. The library I used was PTK for graphics, input, and sound.  I made the font with Bitmap Font Builder.  I tried to use Musagi to make music, but failed.

And that’s that!

Have a look at this nice chain reaction at YouTube: TheCrawlyCrab.avi

Like others I forgot about this.

I used Gimp andPython IDLE.

That’s it except for Mozilla for nav/chatting

oops i forgot to put this in.

Graphics:
- Paint.net > you can’t get alpha chan stuff with mspain. also the wand tool and multiple layers are super handy.

Sound:
- sfxr > drpetter’s sound maker i think is pretty much what everyone used, but i only used it for a couple of my wavs.
- wavepad > i really love this program. i did my recording and remixing in this.

Code:
- visual c# 2005 express > does-it-all-for-me coding and debugging tool LAWD i love this thing

Notepad:
- oh wait i didn’t write a readme AAGGGHHHH NO POINTS FOR ME

anyways thats it

A post-compo version of my entry is here.

Changes are:

• Different algorithm to create dynamic holes (without any texture upload), and compiled with optimization on (so no more slowdowns)
• Gameplay change: Can now walk even during explosions (which allows new timed puzzles)
• Gameplay change: Added movable bombs (allows Sokoban style puzzles)
• 4 new levels (13, 14, 15, 16 are new – still not very good, but a lot better than the ones in LD)
• Allow to choose your starting level (once reached)
• Some graphical changes, like flags to mark indestructible fields
• Fixed several bugs (most of which could not occur in the LD levels)
• Includes a crude linux makefile now besides the mingw makefile and the .exe
• There’s still a bug with 16-bit desktops under Windows
• Another bug which caused unexplained failures to upload textures is fixed with the fixed exe in the comments (so if it doesn’t start up, you can get that .exe – maybe I’ll also re-upload a new version with this later)

Here is some longoverdue documentation for the Windows version. I only realized yesterday that the README file was not included in the Windows release (and even it was, it would have been unreadable due to different end-of-line conventions between Linux and Windows).

To save everybody from having to download the 6MB package again, I am just posting a separate README.TXT.

Just to highlight it, you can create new globs on the right hand side of the screen by pressing NUMPAD 1 – NUMPAD 4 the elemental type of the summoned glob corresponds to the order of the runes on the control panel, so NUMPAD 1 summons a Water glob, NUMPAD 3 summons a Fire glob. If the game was finished globs would rush at you in pre-configured waves, but I didn’t get that far.

In addition, here is a screenshot showing the relationships between the 4 elements:

Red lines indicate how runes (and once implemented, globs) are activated by different elements. If an Air glob walks onto a Fire rune, a fire reaction will ensue. If an Air rune is triggered by a Water glob and there is a Fire rune in the area of effect of the resulting Air reaction, the Fire rune will be triggered by the Air reaction.

The green arrows shows against which elements globs are resistant. Air cannot harm Earth and vice versa. Water cannot be harmed by Fire, but Fire can be harmed by Water.

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)

Hi,

should work fine now.
Please download newest update: TheCrawlyCrab_c.zip

What Went Right

1. Not giving up
Above all else, the most important thing that went right was the fact that I didn’t give up. After reading the theme I thought about it for a few hours before starting to work, and figured it would end up being a puzzle game (not much unlike a bunch of entries ended up).

However, puzzle games require lots of well-designed levels to be fun, and I was pretty sure that I couldn’t manage that in the time frame. There were several moments during the contest where I was asking myself why am I doing this, this is not going to be fun, but pressed onwards anyway, and the end result (after changing from pure puzzle game to something between a puzzle and a shmup) is pretty neat.

This is also the first time I’ve felt like continuing development on an LD entry right after the contest =).

2. Pseudo-random level generation
At first I had totally random levels, but they were, quite frankly, boring. I ended up writing a bunch of different level-generation algorithms (looped square, circles, grid, spiral), which then were fed some pseudorandom values with increasing number of partycles as the levels progressed. I think the first 25 levels or so are surprisingly good with this design.. after that we’re well into the bullet hell territory, and levels were turning pretty similar.

One thing that happened almost by accident is the fact that different levels require different kinds of gameplay – some are “almost” pure puzzles, some are “almost” pure shootemups, and of course the frantic bullet hell levels later on.

3. Time management
I managed to go to dog school, take the dogs out six times, take a shower, do some christmas shopping, sleep well over 8 hours in the middle, watch a movie, etc. and still submitted the final entry 9 hours before the contest end time.

4. Sfx(r)
One thing I’ve really improved upon in LD entries is the sound effects. Sure, I used the (amazing!) sfxr tool as basis this time, but also recorded (with a crappy webcam mic) and mixed some sounds. I used fractal music generator for the music again, which, while not good, is better than nothing.

5. Graphics
I think the graphics turned out pretty good this time, the little there is.

What Went Wrong

1. Bugs
A few bugs which I could have found (and possibly fixed) during the last 9 hours of the compo were left in. Widescreen monitor support, which I actually spent some time on, is broken. Midi music volume works differently than I expected, ending up changing the system midi volume(!), and third, some PCs, more-or-less-happily including my wife’s, are slow. As in 2fps slow.

I’ve solved the first and have been trying to figure the last for the past week or so. It appears that the rendering drops into software on my wife’s PC for some reason that I haven’t been able to figure out yet.

2. Tons of other stuff to do
Having this kind of contest in the middle of the holiday panic isn’t the best possible time =)

3. Tuning
Another thing where I could have used more time on; more level generation algorithms and/or hand-designed levels, slowing down the “normal” bullets from partycles, different kind of partycles that would lead to different kinds of puzzles.. etc. We’ll see if the game is popular, I might spend some time developing it further.

4. Code re-use, or lack thereof
I realized, while doing this contest entry, that I’ve probably written a bazillion font printers. Thus, I started working on a basecode set which includes most of the stuff I’m doing over and over and over again to be ready for the next LD.

5. Post-LD Exhaustion Syndrome
Returning to work and working on the multi-million line projects which move forward at glacial speeds after making a whole game in a weekend.. well, you probably know how that feels =)

Controls should be fixed.

I have added some options:

-choose between window and full screen mode

-choose mouse sensitivity

-choose crab speed

Download: TheCrawlyCrab_b.zip

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.

ok, so maybe I’m a bit late to the party, but here’s a quick post mortem for my ld10 entry. I had limited internet access for this one, and missed being able to hang out on IRC and see what everyone was up to as things progressed, but it’s been great reading the blog posts retrospectively.

:: Design

The compo started at 4pm Saturday for me (New Zealand). I got home around 6pm, completely not intending to enter, but when I saw the theme was chain reactions I caved. I spent most of Saturday evening thinking about game ideas. The main contenders were:

• a 2 player board game with tiles which keep changing colour until the board reaches a stable state.

• a dominos bowling game with many many pins standing all over the place.

• a platform game with lots of crates full of fireworks.

The last one was by far the easiest to visualise, and to know that somehow it would turn out to be fun without oo much messing around. And when I saw that Dr. Petter didn’t have platformers covered for once, it was a no-brainer. :p
:: Tools

This is my 4th entry, and I’ve used the same tools each time:
sdl, sdl-mixer, bcc55, mspaint, gimp. Also this time, sfxr.

:: Implementation

The first step is always to get a black screen which responds to keypresses. I hate that part. I cheated a little this time, by copying snippets of code out of a past entry (sprout) to get the sdl initialisation and keypress code working. Knowing I did this is a tiny lead weight which my soul will carry forever.

Next up was running around a test map. I love this part. It doesn’t take much to get a guy running around 2d blocky landscape, but it’s instantly satisfying to start leaping around and exploring the limits of the world. I spent a lot of time tweaking the physics until it had a good feel to it.

The whole time I was doing this, I was imagining how the fireworks might work. I knew how the sparklers and rockets would be, and they took very little time to draw and code. The roman candles I wasn’t so sure about, and I ended up spending 5x as much time on them. Writing code and drawing gfx doesn’t seem to be the bottleneck — it’s just deciding exactly how things should look and behave.

I had just moved back from overseas when I did this compo, and in the midst of daylight savings confusion and lack of internet connectivity, thought I was finishing at 3pm instead of 4. I realised my mistake quite close to finishing, and was very happy to have the extra hour. I didn’t leave enough time for the vital task of designing maps, but was still able to try out what I imagined to be the defining moment of the game – being chased down a corridor of exploding crates.

I did the sound in about 5 minutes with sfxr. I would formally like to donate my audio points to Dr. Petter for that one. I just grabbed the first 5 randomised explosion sounds that came out.

:: What Went Right

• Not using placeholder graphics. They have a weird way of finding their way into the finished game.

• Being familiar with the tools. I could concentrate on designing stuff rather than fighting with technical issues.

• Making sure of the design before getting deep into implementation. I didn’t end up spending much time reworking code or graphics.

:: What Went Wrong

• Bad time distribution. Even 30 more minutes working on level design would have improved the game a lot.

• Not budgeting time for details. Little things like a nice txt file to go with the game, windowed mode support, hardly take any time but would have been worthwhile.

:: The Fucha
The problem with making 48h games is that I alway want to spend more time brushing up my entry and re-releasing it. Splode is no exception — I’m thinking to make a nicer 10-level arcadey version with online scores and recording at some stage. I’ll post here when it happens.