Click here for Wrecking Blob.

Ludum Dare 33 has been a great learning experience for me. Over the course of the jam and afterwards, I made a number of observations about the quality of my game development process and my abilities as a developer. This is my postmortem.

What Worked

Simplicity

Making a new game is an exciting opportunity, and ambitious projects tend to be the most fun to brainstorm. However, ambition tends to lead to complexity making those ideas risky. With so little time, game jams are not where I would reach for the stars.  

Finishing a project (as finished as a jam project can be) is more enjoyable to me than working on something and ending with nothing to show. Having experienced both results, I chose a simple idea as I felt that was key in completing my group’s project last Ludum Dare. I believe this choice made development easier, smoother, and more fun. I’m glad I went with a basic idea, and I will do so again next Ludum Dare.

Working Alone

Generally, I try to be part of a team for game jams. I have limited art, music, and sound skills, so having people to cover those areas makes for more well-rounded products. Plus, working in a team is good practical experience, but perhaps most importantly, it’s fun to make games with friends.

This Ludum Dare I was flying solo, and while I no longer had access to quality assets, there were a few benefits. Being the sole developer gave me complete creative control. Working on exactly what I wanted was more creatively rewarding than when I worked on a team. Not only that, I was free to experiment and learn in the areas of game development in which I was most interested. I don’t prefer to work alone, but sometimes, it can be refreshing.

Don’t Sweat the Small Stuff

Game jams are short affairs. One can only accomplish so much, and there are more issues to deal with than time allows. Knowing when to let bugs slide or move on from polishing a texture or particle effect is important to maximize productivity.

In my game, the player can move around during the fade in and out level transition allowing them to interact with objects. Ideally, I would have fixed this, but I figured that players were unlikely to notice. This bug wasn’t game-breaking either, so I left it as is. The time I could have spent trying to fix it, I instead used to flesh out and improve more important parts of the game. I felt I did well making these types of decisions and will keep them in mind next jam.

What Didn’t Work

Simplicity

Simplicity was helpful, but it also hurt development. The idea I went with wasn’t particularly exciting, so my motivation was lower than it may have been with a more ambitious and complex idea. Also, the way I envisioned the implementation seemed quick, leading me to underestimate the time I needed to work. As a result, I took it easy the first day, and that low productivity damaged the potential quality of the game.

Working Alone

While working alone gave me total creative control, it also limited the project’s overall creativity. Simply put, two minds are greater than one. Having more than one brain to come up with ideas even just during development would likely have made for a better final product.

Additionally, the accountability of working with another person was gone. This lowered my motivation, which compounded with the other motivational issues I mentioned above. Now that I’m aware of this, I believe I can mitigate this problem next time I work alone if I handle the issue below.

Lack of Scheduling

Game jams are informal events, and I try to have fun with them. I don’t find making a schedule and deadlines particularly fun, so I didn’t bother with them. If I had, I think I would have not only been more productive but also had more fun.

With just an impromptu task list to guide me, I went with the flow and worked on whatever motivated me or gave me a clear idea for implementation. Unfortunately, those two conditions were not always true. As said earlier, I felt I had plenty of time to work with, and when I did not feel ready to jump into a task, I would take a break till I was ready to get back to it. This lasted for the first day and a half, when I started to feel like time was catching up with me. Ultimately, I finished the basic gameplay a few hours before the deadline. By not working harder earlier, I only had that short remaining time to make levels, and the game reflects that.

This outcome disappointed me, and the rush to scrape together levels was not enjoyable. Making a schedule would have helped keep me on track to work harder earlier. With deadlines to work towards, I would have had a better idea of when I was falling behind. I believe these changes would have ultimately made for a more enjoyable and fulfilling development experience in spite of the initial drudgery.

Room to Improve

I’ve been working on and off with Unreal Engine 4 to prototype some game ideas, but I’ve never gone through the packaging process or looked into resource management. When I first packaged my game for submission, I was quite surprised to find it taking up over 500MB. There was no way I could expect users to download a game that size. Fortunately, the documentation explained a mistake I had made in including hundreds of unused assets when I first created my project. After taking steps to fix this, I was able to shrink the package down to 100MB, which is still large but at least not unreasonable. Now that I’ve realized this could be an issue, I will look into further steps to keep file sizes low.

 

I didn’t experience slowdown on my end while developing Wrecking Blob, but several players reported it in the comments. I’ve never worried about slowdown in the past, but it looks like I need to start being conscientious of resource management so everyone can have stable performance.

One easy improvement I could have made to Wrecking Blob would have been to make the player model a blob instead of a sphere. However, I don’t know a thing about modeling, so even  something that basic is beyond me. I believe, with just a little knowledge, making a blob would be a simple task. Learning the basics of a modeling program, Blender perhaps, would allow me to make such a model, and then I could make glorious programmer models for my other 3D projects.

With Ludum Dare 33 complete, I’ve learned how I’ve grown since Ludum Dare 32 and how I can continue to grow. I have a better grasp of my limits and how to choose an idea to match them. I get bogged down on details, but I’ve gotten better at letting go and moving on. The connection between productivity and quality is clear to me. I can use scheduling to bolster motivation helping me work consistently from start to finish. I realized that with Unreal Engine, even for a game jam project, I need to pay attention to performance and file size. Modelling experience will help me in future projects. I’m going to start learning though I don’t plan to go beyond placeholder quality. With all this in mind, I look forward to an even better Ludum Dare 34.