Ludum Dare 53 was this weekend, and I participated for the first time. For those who haven’t heard of Ludum Dare, it’s a game jam where participants can work with a team to make a game from scratch in a limited period of time. You can read more about it on the site, but I mostly want to talk about my experience, and some lessons learned.
First up though, let’s talk about the game I worked on. This event’s theme was “Delivery.” So I worked with my friends to create Demon Lord’s Catboy Pizza Delivery Service. Here’s a link to a playable version on itch.io.
My contributions were in three main areas, and those are the ones I’ll be focusing on for this retrospective.
Art
I did the art for the monsters you deliver pizza to, and also the hub zone, and the enemies. These were a lot of fun to draw. But we used a default tile set, and my art sticks out and doesn’t quite mesh with it. That said, they did get some positive feedback, so I’m glad people enjoyed looking at them.
I think there are two key things to recognize here. First off, I didn’t have a workflow set up to build pixel art, which meant my stuff didn’t match our pixel art tileset. Honestly, have no experience in pixel art at all.
Second, I want to keep improving my art to match themes and tones. I want to improve my abilities around color and palettes. I don’t have any plans of becoming a professional artist in the immediate future, so this will likely remain a hobby, but I want to provide stronger and more consistent art for the next time I do one of these with friends.
I also want to create more compelling and entertaining splash screens and covers, because I think that would drive more engagement. Right now our main screen and splash is fairly dull. It’s a small thing, but I think it’s important for getting more plays and feedback.
Background Swapping
The only system I wrote any large amount of code for was the background handling. My code dynamically swaps the background art based on hitting flags in the environment.
It was also an excellent demonstration to me that I haven’t written any code for a long time. My professional job is technical, but mostly demands a very specific non-code knowledge, along with a broad smattering of other technical knowledge. (Database structures, query languages, various endpoints)
Point being, if I need to actually design systems, I freeze up a bit. For the next jam, I think I need to prepare by writing more code and practicing in Godot prior to the event to have the knowledge base to contribute more effectively.
That said, I am happy that I just asked my friends how to do things instead of sitting and suffering and reading docs for hours. So at least my ability to prioritize in tight deadlines has improved slightly.
Level and World Design
I built out the world and level that’s present in the final game, as well as handled most of the enemy placement. There are two groups of lessons here for me: first the ones related to Godot itself, and second the ones related to just better game design practice.
First, Godot as a tool: we decided early on to do a single large world with multiple objectives. In retrospect, this may have been a mistake. Because of how Godot handles scene objects, this meant that having two people with branched copies of our full_world scene would need to resolve merge conflicts, and only one person in our team had the background knowledge of Godot to handle that.
The end result was a scramble of rebasing and not touching that scene to avoid those conflicts, and it sort of rushed things a bit near the end.
The second is the world design itself. I think there’s a lot of room for improvement in the world design, on multiple points. First up, navigation and linearity. DLCBPDS had a large open world, and the player starts right in the middle of it. The player is asked to select a quadrant of the world map, and then travel to a goal within that quadrant. The thing is, in order to keep people from getting too lost, each of the quadrants is separate from the others.
However, in playtests, I routinely saw players go into the wrong zone almost immediately, after which they would have to backtrack the entire way when they realized what happened. Or more often, after I told them.
Simply put, this was a bad design pattern on my part. It made it too easy to get lost, punished getting lost with a painful backtrack. If I was to build this again, I’d want to focus on a linear path, or adding more in-world indicators to really hammer home where the player is supposed to go.
The bigger issue, and the one I need to think about a bit more is level design in games in general. I came into this jam with an intention to make things “Fun.” While I do think the game succeeded in being fun, I’m not sure the fun arose from the world the player navigated. There are some sections people enjoyed, specifically the areas I have mentally labeled “Pit” and “Tower.” But this wasn’t the result of careful design on my part, and more due to trial and error of design. I threw a bunch of different patterns at the wall and saw what stuck.
There were four patterns I threw at the wall, and I want to talk about them briefly. Pit was a large hole that you climb down. Tower was a large hole you climb up. Dungeon was a series of caves with some enemies, and Outskirts was a large empty void I filled with rectangles.
Tower and Pit were the most popular from what I saw, and I think in that order. And that’s because they’re the areas where using the game’s core movement mechanics are the most enjoyable. These areas let the player use the grappling hook to pull themself up, use dash jumps and dodge around outcroppings as they plummet.
But I’d like it if I could make every area that enjoyable. For the next game jam, I think that means I need to study our intended core mechanics better prior to just building things, find the fun moments, and elaborate on them. At the same time, I’d also like to have a more exact understanding of those mechanics, for example exact jump height, exact dash distance. That sort of thing.
Other Bits
I have some other thoughts that aren’t specific to me, but I think are worth noting, and considering for next time.
Our file structure was kind of a mess. Agreeing beforehand on a general unified structure for objects would be a good idea, including things like locations for art assets.
Our coordination has room for improvement. There was a point early on where two people spent time working on the same thing, and someone’s work got thrown out. This was both a waste of time, and also felt shitty.
Repo structure. We tried to do a single main repo, with each person having a fork. This got abandoned almost immediately. I think a single repo that everyone pushes branches and requests to is the way to go for this project. Not as some sort of statement on version control, but because at least a few of us (me) are too incompetent with Git for much else to be worth it.
Builds. Our final build had issues, including crashing on scene changes in certain versions for no clear reason. We needed to build earlier, identify these sorts of things earlier, and either mitigate or be aware of them before there were only two hours left to turn in.
Controls and tutorials. If literally nothing else, we needed to include a tutorial level of some sort. Plastering the controls on every screen we could AND the pause menu wasn’t enough. It was really stupid of me to think that people would just naturally experiment and find the controls.
Conclusion
For a first time jam, I’m actually super proud. We made something, it has at least some fun moments. I wish my contribution was a bit higher effort, but I’m glad it was there at all to be honest. That said, there’s a lot of room for improvement and learning.
I’d also like to thank the folks I worked with for putting up with me and inviting me. It was really fun working with them. Kalloc and Slabity don’t have things I can shill. But Meptl has done some cool stuff, so I’m going to link that here.
- Made an entire music video and documented the process for their favorite VTuber duo.
So if you’d like to see some neat stuff, maybe check their projects out.
More game reviews at some point in the future, I promise. But most of my weekend was spent making games instead of playing them.