This is a postmortem of my Ludum Dare 43 jam entry, The Pursuit of Profit.

Successes
The biggest success is that I created a complete (albeit simple) game in 72 hours, had a lot of fun doing it, and didn't sacrifice my health or sanity. I slept mostly normal hours, ate regular meals, walked the dog, and took care of other obligations. I did have a little trouble getting to sleep on the final night, but other than that the game jam was minimally disruptive.
As for the game itself, I think the illustration and overall atmosphere and mood turned out pretty good. The fog effect is very effective considering how simple it is (several parallax layers of the same texture with different tints and scales). The capitalist pig and baby artwork turned out well, and it was fun to brush off my illustration skills.
Using the Godot game engine was great. I have only used it before on one project, with a completely different style of game, so I was worried I would struggle with the tools. But, Godot turned out to be quite easy to use, with pretty good documentation and many tutorials on the internet, including how to make platformer games.
Also, as someone who enjoys puns, I'm pretty pleased with the title I came up with. :smirk:
Unsuccesses
There are two major, and interconnected, areas where the final game was not successful. Due to lack of time, the gameplay and the message of the game both had to be stripped down to their absolute bare minimums, and as a result both are much too simplistic and blunt.
The message was supposed to be about how a capitalistic economy (specifically the profit motive and competition) leads to an accelerating runaway process, forcing you to make morally compromising decisions to stay in business, and leading not only to the destruction of the environment and other people, but often to the ruination the capitalist himself.
The game mechanics were supposed to reinforce this message. In the original concept, the pace would start off leisurely, in a wilderness setting. You would pick up some trees or coal from the ground and throw it into the robot's mouth. The robot would pause for a moment, then spit out some coins, which you would run around to collect. But as the game progressed, the robot would move faster and faster, the scenery would shift from wilderness to rural to urban, and resources would get scarcer and scarcer. To stay alive, the player would be forced to sacrifice animals, then human workers, culminating in sacrificing orphans and babies. In an emergency, the player could also feed it a sack of money, sacrificing points to delay the robot.
This was, of course, a very ambitious vision for one person to accomplish in three days, and I knew going in that I would have to cut a lot of it. But I didn't realize how much I would have to cut basically all of it.
In fact, I wasn't even sure until the final day that I would be able to make the robot move, which was essential to the concept. Out of desperation, I ended up directly modifying the robot's position, which you are not supposed to do because it causes the physics engine to glitch. This is why the robot often flickers when it starts to walk, and the babies suddenly go flying away. But, it worked well enough for a game jam entry.
One concept that did make it through is that the more money you accumulate, the worse the ending you get. This was meant as a deliberate subversion of the assumption that you should accept the criteria for success that are presented to you. But, like the rest of it, it ended up being much too simplistic and blunt.
Final thoughts
If I could send a message back in time to myself, my main piece of advice would be to pick a simpler concept, even if it is not very interesting. I think the original concept would have been feasible for a team of three, or even two people with a lot of energy and experience. The biggest challenge doing a game jam solo is that you are forced to divide your attention and frequently switch contexts, from game design to programming to art to sound. Teams have a dual benefit: there are more people to divide up the work, and each person performs better because of reduced cognitive load and more opportunity to focus and stay in flow.
Otherwise, there were several time sinks I wish I had avoided:
- I spent too much time tweaking and fine-tuning little details, like how wide the robot mouth opens, and the angle and speed you throw babies. Those details would be important to tune for a real game, but during a jam they are mostly a waste of time.
- I ran into a bug in Godot where the player and babies would fall through one-way platforms. I spent a long time trying different workarounds, before giving up and making the platforms solid from every direction.
- Generating the music with WolframTones is extremely hit-or-miss. It took me a long time to find a melody that wasn't terrible, then to tweak the instruments. I would not recommend using WolframTones unless you are not picky at all, or you actually want weird random songs.
I would also use a different approach for the robot physics, using only kinematic bodies instead of a rigid body and joints for the jaw. It would require additional up-front effort to program collision responses, but it would have been more stable. Unfortunately, when I started the jam I wasn't confident enough in my understanding of Godot's physics engine to attempt this.
What's next for the game? Probably nothing. It's too bad I didn't have time to realize my original concept, but I don't think it's really worth pursuing outside of a game jam. It's not a game I would normally choose to make, outside of a game jam with a specific theme and time pressure. There is a small chance I might try polishing it to practice my skills, or for the satisfaction of a job well done. But otherwise I think it's best to leave it and move on to other things.