Ludum Dare 48 Postmortem
Ludum Dare 48 was this past weekend, and I decided to jump in at the last minute. I had attempted a Ludum Dare jam many years ago, but I never submitted it because it was barely a game when the jam ended. That jam failed due to spending an inordinate amount of time making a level editor and accompanying UI rather than making the game.
I had decided to go into this event with the intention of making something that explored a sci-fi setting, then try to mix in the official jam theme.
Tech
For this project I decided to stick with C++ since that is what I’m most confortable with. For graphics and sound, I decided to try out using RayLib. For compiling, I stuck with the simple and effective “unity build” where the whole game is compiled in 1 translation unit via a simple build.sh or build.bat. The game was written on Linux, and it only took about 15-30 minutes to get it ported to Windows once I was done.
Setting
I recently gained an interest into the whole dystopia/cyberpunk/high-low tech sci-fi trope. For this game I made an environment that was a combination of under-developed desert village with mud buildings combined with high technology like pnumatic doors, computer displays, radio towers, etc. While I didn’t create an expansive environment, it was fun to explore this setting.
Gameplay
I’ll admit, I fell short on gameplay. The theme being “Deeper and Deeper”, I chose to do the obvious gameplay trope of continuously exploring “deeper” levels of increasing difficulty. Basically some tunnel system under the desert village was infested with robots that needed to be cleaned up.
Where I fell short here was two fold. Firstly the tunnel system was put together pretty hastily. Not much art was done, and could have been made more to look more like a tunnel system with changing art on different art. Secondly, I had only developed two types of “enemies” that didn’t fight back. The game could have been way better if a challenge was introduced by having the baddies fight back.
The ending was also hastily put together with a small attempt at a humorous dialog to close off the story.
Code
One thing I wanted to play with is a different way to handle entities. Instead of splitting the various types of entities, such as door, lootbox, NPC, etc. into separate structs…all entities were composed from a single Entity type and the differing functionality was implemented by setting values or flags.
I’d say it was a pretty successful experiment as I was able to compose new entities as the ideas came to mind without having to do much work or spend time fixing bugs. The point of doing this was to try and make the entities all share the same code path, reducing development time and bugs. Where this technique broke down was when entities ended up needing specific functionality. For example, both a door and a lootbox get the INTERACTABLE flag set, however they want to do different things when interacted with. The door wants to open and change it’s collision rectangle, whereas the lootbox wants to spawn an item. So while entities can’t entirely share a single code path, it was really nice being able to specify logic only when needed and not having to specify all the logic for every entity type.
(Yes, inheritance is commonly used to do this same thing however that comes with it’s own costs and tradeoffs)
Discovery
One neat thing about this experience was the idea development that occured. The game started out as just colored rectangles where I implemented the platforming mechanics. After that it was just a matter of letting the ideas flow. Wanted to do a desert motif, so I did the art for that. Then the idea of having a robot at the start, and did that…then the loot box and a town behind a lock door, then being able to enter the building, etc. As one idea was gained and implemented, the next idea flowed.
I think this really taught me that not everything needs to be fleshed out before hand. Being able to easily and quickly experiment adding things make this process easy and flow well. That’s one of the main benefits of writing in C++ and using the unity build for this project. Compilation time was less than a second, so I could quickly add something and test it with a very short turnaround time. This is something that is really lost in modern-day game dev, and is likely the cause of the lack of cool and innovative games.
Overall
I consider the jam a success just for the fact that the game has most of the things the make up a game: the setting, some art, some gameplay, some story, a beginning and end. While it could be much improved in the gameplay and fun factor, the attempt succeeded in doing what I wanted to get out of it and that was just making a playable game and shipping it.