I'm excited to participate in my first Ludum Dare! I'm using a custom physics engine that I've been working on for a while, video below:

https://user-images.githubusercontent.com/25427895/211033100-e8814297-52ed-4997-bae8-9c0114c945d8.mp4

Looking forward to seeing the amazing games everyone creates!

Engine: Custom physics engine!

Language: C++

Other SW tools: Dear ImGui, Catch2

I'm heeding the cautionary posts I've read about paper prototyping, defining scope, and keeping things completely within my wheelhouse.

This is my first game jam ever, and I'm using my home-grown physics engine as the only game creation tool with Dear ImGui for UI. All of the mechanics are physics-based, which simplifies some things (no rigging up animations), but makes some things harder (tuning parameters, staying inside cpu budget). Here are some of the pros and cons I've noticed so far:

Physically simulated environment and character model

Everything in the game map is physically simulated. The player character is a collection of rigid bodies held together by constraints and forces defined in a config file.

Pros

It's really, really easy (well, kinda, more on that later) to make a map with intrinsically dynamic elements. Elevated spinning disk obstacle? No problem, just a squished cylinder, a revolute joint constraint, and a revolute motor constraint. Gear and linkage driving the motion of a path blocker? You got it.

Simulated contraptions can be tested outside of the game map. This is a huge win - being able to test things piecewise makes it much easier to isolate and fix bugs.

Cons

There's a persistent whisper at the back of my head that my CPU budget may be overblown at any second. Tuning constraint parameters, masses, and even initial orientations can be a pain (my engine doesn't have an editor - config files have to be made by hand).

Limited rendering features

My physics engine only supports a small fixed number of convex meshes and has zero support for textures or particles. It lets you color the meshes, though!

Pros

Having such an artistically constrained medium meant that 85% - 90% of my time was directly related to defining gameplay and mechanics, so I was able to build most of the game that I had in mind. Essentially, minimum viable gameplay is prioritized over visual style.

Cons

There is absolutely zero juice. The graphics are as bland as they could possibly be, and this will likely be a major detractor from reviewers.

Zero audio

Having an audio thread is nowhere near the roadmap for this engine.

Pros

One less thing to deal with, another point for minimum viable gameplay.

Cons

Immersion is almost non-existent.

Takeaways

I'll continue to toot my own horn. I'm surprised that this tool is as mature as it is. Granted there are still things that need to be changed, features that need to be added, and algorithms that need to be tuned. But on the whole I'm super proud that this thing is finding usefulness outside of its intended wheelhouse (it's supposed to be for simulating robots). The game that comes out of it might not be amazing, but this jam has identified one or two handfuls of features that would be super nice to have.

Thanks for reading, obligatory progress pic:

(You can have any color you want as long as it's... yellowish... orangeish)

Jumping bean harvester is ready for evaluation!