Ludum Dare 28
Ludum Dare 27
Ludum Dare 26
Ludum Dare 25
Ludum Dare 24
Ludum Dare 23
Ludum Dare 23 Warmup
The 7-Way Tie Award
Awarded by JesterBLUE
on January 9, 2013
This will be my 6th participation. I am using Haxe to make a Flash game. No base code or external library (except possibly Box2D if needed by the idea, because good physics is a hard problem). I like reinventing a new wheel each time, it’s a fun part of LD: write quick and dirty code instead of the usual care about code quality.
Have fun and good luck to everyone !
No Time to Stop is a classic puzzle where you can’t turn until you hit a wall, with an additional 10 seconds time limit. This was not just to follow the theme, it added something I love in puzzle game: optimizing solution. You also need to smash keys in fast sequence, which I am not a fan in music games, but here I liked it, because instead of simply following a track, you actually design the sequence and replay it using both memory and quick thinking. The game was done in less than 24 hours and has 10 levels offering a hard challenge.
What went wrong:
Lost 24H on another idea (a dirt racing game). The car drifting mechanic was done when I realized that a 10 seconds lap was too short to be fun. I scrapped that and fell back to something more easy to tweak and simple enough to be coded in 24H. Don’t give up, try plan B instead.
How to win. I suspect that some players didn’t understand how I intend the game to be played. You are supposed to ignore the time limit when searching the solution and then replay it quickly. I think some people directly stop and retry after 10 seconds, probably because it looks like you are supposed to do that (death sound and a red retry message, even if you are still free to move). Others seem to plan mentally before the start. I admire that chess-like spirit and it’s how I designed the level in my editor, but it makes some levels very hard. Don’t assume that players will play the “fun way”.
The difficulty. Because 10 seconds was a fixed limit, it was hard to balance the levels (IMHO that was a general problem with the theme). So, during development I tested with 8 seconds and added hotkeys to tweak that time limit if needed. Unfortunately this is not visible in the interface and some people will not see it in the description. Always show hotkeys in-game.
What went right:
Easy to code. This time it was really refreshing to have a game straightforward to code. My previous LD always had some tricky physics problems, which are often hard to tweak. Here, the core mechanic is very simple, and adding special blocks was just few lines. Pick an idea easy to fully prototype early.
The graphics. During most of the development, it was just a grid of colored squares, good enough to prototype, maybe even to release. I only added sprites in the last few hours. A simple trick with good payoff was the line behind the player. This obviously helps to follow your moves, but before that, there was no animation (for fast gameplay and easier coding), and that tiny effect really added a lot of life to the game. Always add a cool effect to the main action.
The levels. I really had a lot of fun creating them, and a simple pixel editor was enough. I am also happy about their number and variety. Without testers, it’s hard to balance but they are small, so hopefully determined players can finish the game. Making levels is fun and important, keep time for that.
This LD started bad but ended well. My advice to people who give up during LD because their initial ambitious project failed: instead try to make a very simple idea in the short amount of time left, it’s very fun too.
As usual, I will use Flash with Haxe with no base code. I like to rewrite everything from scratch each time. I often find new methods to do things this way, sometimes better, sometimes simply different. Of course, it only makes sense to do this for LD (inefficient for real developpment, but more fair for this, I think).
I hope we’ll get a good theme, because finding a good idea is really the hardest part and sometimes the theme doesn’t help at all. I also hope that Real Life will not interfer too much this week-end (which is sadly probable).
That’s all, good luck to everybody and have fun.
But a bit sick. Hopefully, it will go better, or at least not worse. That’s my 4th LD and I never gave up, so I hope to continue this trend. But I already feel as tired as at the end of a LD, making this one extra challenging. Worst case scenario I’ll do dead simple code and gameplay concept, and focus on content (doable even with a headache, I think), which is also the opposite of what I usually did in the past.
For the technical part, as before I will use Flash with Haxe, with no base code. Last time I didn’t even use any extra library (my first two LD used Box2D), and I like that sort of purity for a LD game. But I may change my mind if my idea for the theme really needs it.
Anyway, good luck guys and may the inspiration be with you.
My idea was that a big ugly spider is a classical villain in games (Limbo, Minecraft and many more) and the cute fireflies were the source of lights in a dark cave (finally not so dark, but that was the plan). A bloody eating animation was also supposed to highlight that, but not enough time.
I took a risky bet to improvise some basic physics engine with per-pixel collision and it turned OK. I initially planned to use a library again, but LD is also to quickly experiment new things. However, I constantly modified the gameplay around it. The jumping mechanic exists mainly because walking was a bit clunky. Similarly, the rolling and sticking behavior solved the same stability problem. My first idea was to use some ninja rope possibility, but jumping was already fun enough. The second reason to use per-pixel collision was to quickly create levels simply with an image editor, thus skipping the need to code some custom map editor. This also allowed to easily add many graphical details.
Making the first level was really fun (almost too much fun). I wanted to make more of them but drawing take more time that I expected (the price to pay for its flexibility I guess). I also added water a bit late, and it’s probably a bit too hard. Plus, a last minute typo made it even harder. I had more gameplay situations possible with the current terrain types, but again, levels were done too late. I also coded some compression tricks to handle these big megapixels bitmaps but it was probably not needed because the final game is only 180kb.
I think the look and feel is good. Tried a lot of control variants and lost some time on the sprite and animation, but it really helped to make it more natural. Simple things like the spider orienting its legs towards the wall, or the difference between the rotating open/closed states made a big impact on the resulting impression.
Pretty happy about the final game. I really like the mechanic and wish to explore it more. Also, less ashamed than usual by my sprite skills. I really need to improve my level creation timing, though. But in the end and as always, I greatly enjoyed the Ludum Dare challenge
But still with some maybe, because conditions are less optimal this time. I had annoying hardware problems last few days (seems fixed now) and just reinstalled my system, also switching from Debian stable to testing. This means that some of my tools are now pleasantly updated but slightly unfamiliar. I will probably have some missing libraries here and there, and other small time eaters like that. Anyway, I can compile Flash/Haxe, so worst case scenario is a less polished game. Now we’ll see if I can overcome these first world problems and make something fun with it.
I had a lot of fun during my first participation, so let’s try this again. Should be a bit easier now that I know more about it (famous last words…).
Like the last time, I will use Haxe/Flash and maybe Box2D. These days I mostly use C++/java and OpenGL, but Flash still seem better for LD (cross-platform and no install needed). And Haxe is a cool evolving language, they even added new features since the last time, so it will be cool to work again with it.
Anyway, code well guys, and make cool games (or have fun creating weird stuff)
So my Big Atoms was released on time and I like it. Here’s its post mortem.
I am happy about the theme-idea (“hey atoms are tiny”). I wanted to try to do a physics game, and the result, even if classic, has some less used features, like flying and complex shapes, thanks to the molecule theme. The plan was to add special atoms having electromagnetic forces etc, but the bonus atoms already took too much time.
My main problem was the need of an editor. Creating physics level always seems hard and I avoided any polygons fiddling, but I needed to handle much more objects. So, I kept adding editor features to allow me to create levels faster, and trying to find the good balance optimizing the time left. It was almost an epic fail since I made only few levels at the very end.
That one was a big problem and I experimented with various methods most of the first day (mouse, rotation). All were hard to learn and tweak, so I got back to some dead simple stuff and started the game itself, also because it was still impossible to test correctly without real levels. The final result probably relies too much on inertia. I was planning to have bigger molecule at each level and thus wanted to start weak. A bit more power seems more fun now, but it also makes things much easier, so the sweet spot needed more testing to be found. [edit:] I just documented a method how to tweak your molecule’s power using the editor. Funny, we can’t patch things, but providing an editor allow the players to fix and tweak the game if they want
It was really fun. I loved searching and deciding an idea in few hours, experimenting quickly, using tricks to create stuff faster and the rush at the end when so much is done. Also really happy to have managed to finish it. Definitively be back next time.
Yesterday, I submitted my warmup game, SameOrb, and was happy to be able to finish during the weekend. I picked an hard time limit to myself to check how I could manage the polishing phase. The engine/toy was quickly done the first day and the gameplay/balance/arts the next day, with a big gap between them where I was erroneously thinking that having few bouncing balls was an “almost-done” game. So it was something like a 2 half-days project.
It was a very fun exercise and I learned a lot of good lessons about time management for the true Ludum Dare challenge, except the theme part, we’ll see how that goes. Here are the steps which required more time than I expected, and I hope to fix that in my LD. Classic tips, but I can now confirm that I should follow them
- Challenge/gameplay. Even when the engine and controls are done, I still need levels, checkpoint etc
- Be nice with new player. Ok, no time to write tutorial or instructions, and *I* know them, but need to focus more on intuitive feedback to explain things.
- Don’t add sounds at the end, it’s not just arts, it can be an important interface feedback.
- Tweaking and testing physics is hard, and messy hardcoded values don’t help.
- Still need to watch performance. No time to optimize, but brute force everywhere sometimes leads to problems.
- Deciding when to stop adding features and when to start polishing gameplay and arts, is very important.
- Keep some time for the release step, stop coding *before* the last minute.
- Still take breaks, it’s important for performance and allow to think about the big picture.
Ok, I hope it helps someone (other than me), and don’t forget to have fun
This is my first participation and I am curious to see what can be done in 48h. I would love to work with C++/OpenGL but it seems that Flash is better for this. So, I will go with Haxe and maybe try Box2D if it’s good for the theme. I am currently experimenting with the haxe version of this library and will try to use it for a warmup game.
Now, let’s create some fun!