Instead of a typical postportem, my hindsightly wisdom will be portrayed with more generalised advice, in the hope that others can learn from this too. So, here are the cumulative lessons I have learnt from the past few Ludum Dares to push your overall ranking up (disclaimer: I have yet to test these):
#1 Get yourself or make yourself a library or framework that gives you basic, smooth mechanics of a game.
Chances are, if you try and implement your own physics and collision detection inside the 48 hours, you’ll a) waste valuable gameplay-crafting time and b) end up with something that has more bugs than it should.
‘Smooth’ is in italics here because it’s imperative that your basic mechanics are solid, or the game will just feel awkward to play, and hence less fun, no matter how good your idea was.
It’s also worth including things that you know you’ll need such as resource loaders, audio players, or (if you’re higher tech than me) an animation player.
#2 Make your graphics feel polished, even if they aren’t.
For the artists out there, this isn’t usually an issue, but if you’re like me and can’t art for cheese, then you need to add juice.
Tweening, basic hit animations, and screen shakes give your game a fantastic aesthetic, even if your sprites are just pixels.
Add these functions into your framework (see #1), or find a publicly available library to hook up with, before the Ludum Dare. This saves time and gives you chance to practice (something that gets its own heading).
#3 Cool features are often easy to implement.
Lighting is cool.
Particles are cool.
Animations are cool.
Screen flashes and shakes are cool.
This overlaps with #2, but I couldn’t fit it all in and it really is worth accentuating.
And everything here requires minimal code and can be easily fitted into your framework or found in a public engine.
#4 Keep your game as intuitive as possible.
Intuitiveness is always important, but it just can’t be stressed enough in Ludum Dare, where the majority of your players will be eager to jump into the game as quickly as possible to improve their coolness.
This means that everybody that has played Mario can open up your game and work out how to play with a couple of lines of instructions.
This can be tricky for puzzle games, but the key is to keep the objective of the puzzle clear, and let people figure out the other mechanics for themselves (of course, keep an instructions page for reference if people get stuck).
A personal example: my favourite Ludum Dare entry of mine was my You Are The Villain entry, where the objective of the puzzle was to help the player complete his objective while pretending to work for the villain by ‘accidentally’ forcing the player to do the actions required for him to win in such a way that doesn’t arouse suspicion with the supreme overlord.
In comparison, my Ludum Dare 28 game’s objective was to “kill all the enemies in one shot”. Their relative intuitiveness is reflected in the comments (and probably a large part of their overall scores).
Finally, walls of text for instructions? Don’t.
First audio lesson: choose your sound effects carefully. If you’re using sf/bfxr, spam the generate key until you have a sound that is, by auto generation standards, perfect for its use. If your gun firing sound is irritating after five shots then nobody is going to play your game for long and enjoy it.
It’s possible for your sound effects – even if they are from sfxr – to help with the intuitiveness of your game. Your sound effects should imply what the action achieves.
Second audio lesson: music really adds to the mood. Even if you aren’t going for a moody game, exciting music will make players feel excited. Sounds obvious, but a lot of people overlook its importance.
If you can’t create decent sounding music yourself, try using GreaseMonkey’s autotracker. It creates music of an impressively high quality for auto generated standards.
#6 Get some practice with your development tools and framework.
If you’ve gone and created a framework with tweening and animation handling after reading the first 4 lessons, then you need to practice before the next Ludum Dare.
“Practising” is not synonymous to “testing”. It’s great that your framework can handle a wall and a zombie, but you need to get used to your tools so you can create the best game you can during those 48 hours, and that means speed.
Enter mini ludum dares and the warmup weekend. Use every feature of your engine and create a bullet hell shooter with as many screen shakes as your eyes can handle.
This will also have the added benefit of revealing any subtle bugs which could surprise you at 3am during the compo.
So, now I’ve preached, I can start following these myself as well. I hope this is helpful to more than none of you. See you next Ludum Dare!