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.
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.
- 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 game 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% completion. This also allowed me to focus exclusively on implementation once the game design was established and broken down into tasks, and I never had to spend any time deciding on what to work on next.
I like reduced color palettes because 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.
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
1 2 3
$ a2x_new MyGame $ cd MyGame/make/ $ make run
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. I can literally drop
.c files from one project to another with little to no changes needed, for things like drawing progress bars or scrolling log 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 here were also to prototype new ideas, find areas where my game engine is lacking, and improve my skills. At the time I thought it right to circle back to certain things I already implemented and make them a little better. Now that the deadline passed, I wonder what features or game balancing I could have done during that time instead.
Lessons for Next Time
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 (Mechanics, Graphics, Packaging, etc.) and switch working between them accordingly. The final 8 hours could be reserved as a "catch-all" to tie everything together.
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.