Down The Line is my game developed for the 26th Ludum Dare on minimalism. It was my second entry in the competition.
I took advantage of my own JavaScript engine, {FM.js(engine);}. It proved very useful and trustworthy, I did have to make a few tweaks on the pathfinding component but overall it worked pretty well out of the box. I also used Netbeans, Tiled Map Editor, Inkscape, Audacity, bfxr and Circuli.
Last time I participated I was alone, this time I decided to enter the Ludum Dare with other friends such that we could spend the week end together, help each other out, playtest the game of one another, etc. It was extremely motivating, we were in an infinite motivational loop. If anyone of us was tired just the fact of seeing the others making progress was enough to keep working.
We live in France and the theme was then announced at 4 am, In my opinion it’s the worst time to get started, do we stay up until the theme is announced ? Do we wake up at 4 am ? Or even 6 am ? There’s no perfect solution so we went with the last one, we woke up at 6 am after a good night sleep, ready to get started… but 6 am is still not the best time of the day, especially if you count on working ’till 2 am.
The theme did not really appeal to me since I consider minimalist game design as good game design. I just felt like the theme was not a theme but rather a constraint that I already try to apply to my games. So it took me roughly 4 hours of eating, sleeping, thinking to get started but I finally got excited with my newborn concept. I wanted to let the player experience minimalism by letting her carefully creates paths with few waypoints but maximum efficiency. During judging I saw a few games with a similar approach so I guess it’s not completely irrelevant. It could have been brought further though, especially in terms of level design and scoring by allowing the player to find better paths for a same level.
Anyway, even though it was very fuzzy at the beginning I sensed that there was something that could be done. During development the game kind of evolved on its own and became its own thing. It was a bit as if I had no plans but I knew what kind of feeling and level design I wanted. The gameplay had to fit that.
In the end several iterations altered the way the player handled the entities, that’s how were created the blue and red entities, depending on the directions they took when hit by a waypoint. I could not decide whether they should follow the path forward or backward so I created two types of entities.
Overall it went pretty smoothly and after my last Ludum Dare one year ago I could not have dreamed of a better second time. Now that I’m done with my whining and ranting let’s talk about the development itself. What did I do wrong ? What went right ?
What went right
Early prototype: I was able to get a minimal working prototype very early, this helped me a lot and made me confident that I would be able to deliver. In 48 hours of hard work confidence is key, you sleep better, you work better and it helps you stay motivated.
Concept: the early playable prototype proved me that my concept was leading somewhere interesting, somewhere with potential. I still had some doubts of course but manageable ones 
Design: one of my main tools was Tiled Map Editor. Even when you’re not building a tiled game it is still relevant to place your objects, giving properties to them and to the levels themselves. Building levels could not have been easier.
What went wrong
Programming: the system I built at first worked perfectly, each entity was assigned a path as soon as they touched a waypoint. But when I added a new entity (the blue one) I discovered that my system did not handle AT ALL the reversed behaviour. It can seem pretty basic, and it is, but the system I built did not consider all waypoints in the path, only the following ones. At the end it was a mess and I discovered a bug that prevented me from adding more levels. This is the main regret I have for this Ludum Dare, I should have thought of that or designed the last level first such that I would have discovered the bug earlier and have time to fix it.
Design: although I had built a prototype early I didn’t use it to quickly create my levels. I kind of waited for the game to build itself and let it inspire me. While it might be cool to work like this it can also lead to undesired situations, like the one described above.
Sounds: I think that my lack of knowledge in sound design has prevented me to make a perfectly consistent game. Specifically, the sound effects appear less clean and clear than the music since I used bfxr to generate sounds and Circuli to make music. The former is made for 8 bits style game and it does not mix perfectly with the crystalline music produced by Circuli.
Conclusion
Time to wrap it up. As I said above I could hardly hope for a best second Ludum Dare. Of course I could have made a better game, the theme could have been better suited for my taste, I could have been more cautious to avoid major bugs, etc. But it was the best 48 hours I had spent in a long time, my tools are working great, the game seems to be well appreciated and I think we (my friends and I) are considering participating in every Ludum Dare ’till we’re bored… or dead.
Thanks for reading! And don’t forget to play my game and rate it!
Simon
6
This entry was posted
on Tuesday, May 14th, 2013 at 2:58 am and is filed under LD #26.
You can follow any responses to this entry through the RSS 2.0 feed.
You can leave a response, or trackback from your own site.
