Ludum Dare 24
Ludum Dare 23
So, my first Ludum Dare was a success. My first objective for this edition was to manage to finish something, and at the end I had plenty of time to deliver so, probably, I was too cautious with my estimation.
What went right?
- Programming language and libraries: I have relied, mainly on plain C++ and simple SDL which proved to work quite well to program a simple game.
- Data driven: Making the levels data driven was a VERY lucky choice. I was able to tweak them quite easily, although for the next jam I’m going with a tool
- Sound Effects: sfxr worked awesome. And FX really add a lot to the project.
- Pixel art: Maybe I see the game through fathers eyes, but I think the simplistic 8-bit look makes programmer art looks pretty decent.
- Planning: Since I decided to participate, I had a timetable in mind. I’ve managed to be “on time” for the full weekend. Saturday night I had the game with graphics, music, sfx and I made a “beta” version which tested on my father computer (if you work on Windows you MUST do this). I was able to expend sunday morning polishing the levels and music. Even I had time to add a new type of enemy in the game.
What went wrong?
- Lack of art skills: I’m pretty comfortable programming but I’ve found I lack art skills. Not only unfamiliarity with tools, although PyxelEdit had some quirks (like not remembering last used folders) and lacks some way of previewing animations (or I didn’t know how to do it), I had never animated a sprite and couldn’t get a walk animation I liked. I even decided to switch to a simplistic character, because it was easier to animate.
- Lack of a tool: Making the game data driven was a good choice, but for next compo I think I need to experiment with some tool to layout the sprites. If you check my Timelapse you’ll see I expend a lot of time tweaking the numbers in a text file. Manipulating text files with Vim is quite easy, but being my first time making art I didn’t prepare the sprites in a way they were easing to remember (nor made a reference chart, although I had one for enemies).
- Theme: I wanted to do something original and, while I think my idea of going for a Borrowers theme was nifty, I don’t think I was able to put that on the game.
- More mechanics: I wanted to keep the game short, but the biggest improvement I left out was adding a new set of enemies and levels based on “ice” (the food section). I think I have almost exploited fully the tools I had for designing levels. The game is quite easy as it is now, but I have tried to don’t require the player to use double jump or the wall jump.
- Testing: I only had 2 other computers at home without development environment, so my test cases weren’t able to cover the full range of problems people have been finding in the game. I should have added more error checking code and a MessageBox, so I can find why people can’t run the game. Next time, I will do a very simple warmup game with the boilerplate I’ll use and try to test it in as many machines I can find.
I had a lot of fun programming Arnold Bros and I plan to refactor the code and try improving the graphics as a way to get some pixel art skill for the next Ludum Dare. If I can I’ll try to get friday and monday off work so I can squeeze some extra hours to add ambition to the project and to do some preparation before the jam.
I have known the competition since, maybe, five years and I have always wanted to participate. Last week I saw that this edition is the 10 year anniversary, and I decided to jump in this time. I wasn’t able to schedule all my weekend (and maybe take a day off monday) to commit to the compo, but I’ll try to make the best of the hours I have.
As a first timer, my objective this year is submitting something. My tool choices may not be the best, but without almost any preparation I haven’t been able to test a tile map editor or a different music creation tool (I feel this year most of us will use Otomata for the music).
Programming: I’ll code in C++ with Visual Studio 2010 using SDL (with SDLImage for loading PNG, sdl_picofont) and TinyOAL for audio. bss_util looks quite useful (and seems it’s quite similar to TinyOAL), but as I don’t know it very well, I’ll stay with the STL. For my VCS I’ll use Plastic SCM.
Graphics: PyxelEdit, GIMP and Color Scheme Designer 3
Sound: sfxr and Otomata
Good luck and greetings from Barcelona. The city, not the planet.