Ludum Dare 39 Devlog
Ludum Dare 39's theme was Running out of Power. Despot 3900 is a small simulation game where you play a despot whose power is waning. The goal is to accumulate as much wealth as possible and survive for as long as you can.
Download for Linux and Windows on itch.io- Source code on GitHub
Getting Started#
Writer's Block Every Time#
I should really make a personal wiki to keep track of all my game ideas and have them ready to look up for game jams. Here are some of the things I thought up on Friday night for Running out of Power:
- Space ship stranded in a faraway space sector, inspired by Star Trek Voyager.
- Post-collapse survival in an advanced city that was over-reliant on power.
- Text adventure game about not paying your utilities bill.
And finally,
- A dictator running out of power, losing his grip on the nation.
Planning All the Work#
I've been using HacknPlan for the past year to track and manage all my work, and it's been working really well for me. It's a very intuitive way to see where my projects are standing and a significant improvement over todo.txt files littered everywhere.
I used to be reluctant to formally plan jam work, because I thought that 48h was too little time to micromanage like that. My modus operandi was to work non-stop on whatever was in front of me until the clock runs out, with a hazy idea of what it meant to "complete" the project. I turned around on this at 7DRL in March, when planning my work for each day of the week in advance helped keep me on track and deliver my most complete jam game yet.
I made a Hacknplan project for Despot 3900 with Mechanics, Graphics, Sound, and Packaging as milestones. Now I had a tangible goal for the end of the jam: get each milestone to 80%. This also let me focus exclusively on implementation once the game design was done and broken down into tasks, and I never had to spend any more time deciding what to work on next.
Visuals#
I like reduced color palettes, they make it faster and easier to draw consistent graphics. I'm also partial to the old CGA aesthetic, I think it's a cool look.
Coding#
Automate and Reuse as Much as Possible#
It's all about saving time and having your past work keep working for you. For example, I wrote a script that generates a skeleton project that draws a box on the screen which you can move with the arrow keys. With a single command-line call I have a working graphical program that I can immediately start adding game-specific features to and not waste any time setting up. The script even creates a new git repo and populates the .gitignore.
1 2 3 | |
At this point I've also gotten more pragmatic about reusing code from previous game projects. Making everything modular, encapsulated, and following a consistent standard really pays off here. Some .c files can be carried from one project to another with little to no changes, especially utilities like drawing progress bars or scrolling text messages.
Simple Game, Simple Code#
At some point last year I started using the Entity-Component-System (ECS) architecture. However, it's all about using the right tool for the right job, and ECS is too heavy for a game that's essentially a collection of numbers (despot's age, health, popularity etc.) instead of a collection of complex objects that interact with each other. ECS made sense for my 7DRL roguelike, but a few simple structs and globals are all that was needed here.
The Refactoring Trap#
If the only goal is to get as much done as possible in the 48 or 72h, then you should probably resist the urge to refactor the code even as the project changes and screams for it. Just keep moving forward and add features to what you already have.
Aside from making a game, my goals were to also prototype new ideas, find areas where my engine is lacking, and improve my skills in whatever small ways I can. At the time I thought it right to circle back to certain things I already implemented and make them a little nicer. Now that the deadline passed, I wonder what features or balance adjustments I could have done during that time instead.
Lessons for Next Time#
Time Management#
Even though I planned all my work in detail, I did not schedule it. Next time I will book actual blocks of time for each category like Mechanics, Graphics, Packaging, etc. and switch working between them. The last few hours could be a catch-all to tie everything together.
Web Games#
I built Despot 3900 for Linux and Windows, but I think it would also work well as a browser game. I'm looking at Emscripten and compiling my engine with it, so that more people can easily play my games in the future.
Screenshot Log#
