The original idea
Since this was my fist Ludum Dare I didn’t have ambitions to make anything unique from the other devs so I didn’t browse the website at all. That was a wise choice as all the quick progress by the other participants would certainly have demotivated me.
Like for many others, the first thing that came to my mind was making a game with a shape-shifting main character. The original idea was to be trapped in an arena to fight waves of monsters while some orc overlord watches and gives snarky comments about how you are doing. As a final surprise there was supposed to be a gigantic kraken randomly crashing on the arena, squishing the overlord and providing a boss fight.
What came of it
Well, it didn’t turn out as grand as I had hoped for. Time constraints made me abandon the idea of the final boss and I also had to let go of the commenting orc, although you can see his placeholder graphics in the top left corner.
In the end what remained was the core idea: An arena-style fighting game with a shapeshifting hero that had to defeat waves of monsters. Everything got very hurried in the end so I didn’t even have time to color the characters properly and had to go with a minimalist approach.
Play Grokh’s Arena here
The process: What went well
One of the most important pieces of advice for me was to be prepared. I spent some time getting used to the tools I wanted to use and I would have failed miserably if I hadn’t.
I had never used a game lib before and my choice fell on cocos2d-x since I liked the multi-platform compatibility and it has C++ bindings which I feel comfortable with.
I made a jump and run prototype before LD to try out how things work in cocos2d-x. I found some shortcomings that I could work around in advance. I had a working pipeline for the graphics that consisted of creating a spritesheet with TexturePacker and using a code generator I had written in python that creats C++ code which allows to load the images into cocos2d-x classes. Very convenient, saved a lot of time.
Graphically I feel most comfortable with Aseprite and decided to go with a very low resolution of 160×100 since art is not my strong suit.
When time started running out, sfxr helped me out a lot and allowed me to add simple sound effects in a very short time. Initially thought as placeholders, they remained in the final game.
About the music, I like to use Reaper and the free Sonatina Symphonic Orchestra VST plugin which allows me to write symphonic soundtracks on a midi keyboard. I like the outcome but I have to agree with some of the critics that it clashes too much with the retro visuals.
All in all I second the idea that drinking a lot of water, sleeping sufficiently and not binging too much on sweets kept everything together, especially since I rarely ever had as much stress as I had in these 48 hours.
The process: What didn’t turn out so well
For all the good things, there were a lot of issues that didn’t go over that nicely.
First, a beginner’s mistake: I didn’t stock up on food before, so I actually had to go grocery shopping in the middle of the compo. Super annoying.
Then of course, time management. While I think I made the most of the allotted time, working 30 hours of the given 48, it still wasn’t enough so I had to cut some corners, and it shows. No colours on the sprites, no awesome final boss, no details on the arena. Worst of all though, no victory screen. The game just quits on you after 10 rounds. Luckily the difficulty is just high enough so that only one player reached the end so far.
One very important thing I learned in this compo is not to worry if your code isn’t nice. I made a timelapse of making Grokh’s Arena and it becomes clear that I spent most of my time in Visual Studio.
That by itself may not have been so bad, had I not lost about 3 hours on the first day when I felt the need to refactor my whole code. Bad idea. I guess it’s not easy to maintain a balance between hacking it together and keeping it clean enough not to invite stupid bugs, but I certainly spent too much time worrying about good code architecture.
Another thing that I did too late was adding debug visuals. I had some nasty collision bugs that I only found out much too late when I added hitbox visualisation.
Then there are shortcomings to the tools that I used. Cocos2d-x for instance only allows wav audio in Windows projects. Really? Uncompressed wav in 2016? Maybe there is a way around that but I haven’t found it so far. Another thing is that it forces me to ship a lot of dlls that are not really used, like libmpg123.dll or websockets.dll. I may try to statically compile the libs into later games so that I would only include the code that I need, but I may run into licence trouble there. All these libs felt much too big for a little retro style game (We’re talking about 16MB of dlls against 11kB of graphics assets).
Outlook
So yeah, I learned a lot, I am eager for next time and I will be prepared even better. For this game though, I am planning on doing a post-LD version with improved graphics and maybe I can get the boss fight in at the end like I planned.
Tags: ld35 Postmortem
