Ludum Dare 49 Postmortem

This was my first successful Ludum Dare compo, after several shifts from compo to jam or failures altogether.

I didn’t like the theme. No surprise there. It’s the nature of Ludum Dare. But it could have been worse.

Saturday

I woke with a few ideas that could go somewhere and spent a couple hours writing them down. This took the form of a bulleted Word document. Some highlights:

Fix Broken Code: Play a normal game, the game breaks (unstable), and you need to update the source code to fix the problem, allowing you to complete the level/area/etc. This was clearly of massive scope, and I would need to look into how to handle the code. Parsing it myself would be a huge undertaking, and I knew nothing yet about Godot’s on-the-fly script compilation, though I’d heard it was possible.

Unstable Physics: This eventually became the final project. Train car moving automatically on a rail, bed of train tilts left/right depending on weight of objects on it. If the bed tilts into the rail, the train slows down. Must balance items left/right to maintain stable train and reach maximum speed.

Unstable Economy: This was the first I started on. GUI interface to control hiring, firing, establishing new companies, etc. Player must reach a balanced economy that sustains itself for X amount of simulated time. Largely a numbers game, finding the perfect salaries. Balance between salary and happiness—low salary results in less spending/saving and makes employee unhappy, might quit the job.

I saw someone post on the LD page about how everyone’s idea was to aim for stability in an unstable system, and they wanted to see the opposite: a game where you destabilize an already-stable system. So I explored variants of all the above in reverse, and none of them clicked.

With all these ideas out of the way, I fleshed out Unstable Economy. I learned a lot about the Godot UI system (which luckily is similar to Unity’s, so very familiar) and more about dark corners of Godot I hadn’t explored previously. I had something working around 1pm but it wasn’t fun.

I didn’t think I could make it fun. I added a progress bar and auto-advance for some animation, realized the core was kind of clickery and that I should head in that direction, but by the end of the day I wasn’t feeling it.

Sunday

I made the decision when I woke up to switch projects. In the night, I’d developed a clearer vision of the Unstable Physics idea and even outlined how to implement it in my head. So work began immediately after breakfast.

I started with placeholder art so I could see what’s going on, and implemented the movement and physics. I had most everything working by lunchtime except the jump and level loop. Music, bug fixing, jump mechanics, the overall game loop, and some rough balancing took the remainder of the afternoon.

I had a slight panic at 5:30pm when I discovered the build system required a lengthy download. The submission hour meant I had 1.5 hours left, but if there were any major issues in the exported build, I would need to get them fixed by 6pm. Luckily, the builds worked perfectly and getting them exported was a breeze.

What Went Wrong

Physics-based game. I knew from the start that I wouldn’t want to rely on rigid bodies. I used kinematic bodies for tighter control. However, it was still difficult to get the numbers and the feel right because of the chaos of a physics system, and some edge cases caused wild things to happen, needing silly hacks to force into place.

Placing the held box above the player. Instead, I should have revealed a box sprite above the player and removed the held box from the game, then added it back on the throw (hiding the sprite in the process).

Manual physics. Yes, it was good to have tighter control, but rigid bodies would have made the throw and collisions easier to get right. Also, would have avoided the awkward lack of rotation for boxes and the player.

Not enough time to balance. If I’d started Train Tilt on Saturday, I would have left most of Sunday for balancing and fixing edge-case bugs. The game could have used some variation in box weight and more opportunities to use the jump/throw to your advantage, plus a fix for getting buried under boxes and better level length calculation.

What Went Right

Using Godot. It’s amazing. So much of GDScript is Pythonic, the documentation is fantastic, the error messages are clear and useful. Something about the object-oriented node system makes more sense to me than the entity/component-driven Unity system. I also love working in pixel coordinates. So many things are designed better with games in mind, like the input manager and pause handling.

Changing direction on Sunday. Although this left me less than nine hours to complete the project from scratch, the first game would have been unplayable and boring had I stuck with it. I think I had the framework for a clicker game there, but it needed bettering theming and more thought put into the play aspect before it could be fun. Plus, it may have taken longer than the remaining single day.

Making the placeholder art first. This helped me get a feel for the game and, had there been more time, I could have further polished the art later. Then again, maybe not. I’m not great at visuals.

Recording sounds instead of finding them. The entire sound effect library took me about five minutes to record and place. Had I been searching for specific sounds, I would have taken significantly longer than that.