On building an embedded physics engine

I am making great progress on the 2D game engine for the Teensy, named Pulse2D. Here are my thoughts so far:

It is thrilling working in an area where I am not an expert again, and I am not sure what to do next. But it reminds me a lot of how I made my first interpreter, VVTBI. For starters, wait, why does that say 15 years ago!?!? a friend of mine used to challenge me to work on a new, difficult project every weekend. The language for the interpreter is "Very, Very, Tiny Basic." Amusingly, I found an academic copy of an interpreter for a very similar language: "Very Tiny Basic." Stay with me - yes, they're different.

The past

What I did was build my own from scratch, using the academic copy as a reference and with my own take on the project design. Once I finished, I had written my first LR(1) recursive descent parser and lexer, something that left an imprint on me and that I would write many more times later. I would then use that project as my own reference implementation, write recursive-descent parsers again and again, and finally learn about grammars, parser generators, and parser combinators.

Ultimately, I built parsers and lexers so many times, starting with that first interpreter, that today I can build a full-stack compiler for a target ISA in a single weekend for a small language.

I have realized that's what I'm doing today with pulse2d. I found my reference physics engine, Box2D-lite, ported it, and made it accessible for embedded devices. Now I will always have a physics engine to use for embedded and future 2d projects. Some of the geometry and linear algebra I haven't thought about in more than 10 years, such as translation matrices, but I made sure to document the code in a way where I - or someone else who wants to use this with no experience - will never forget and can easily get started.

The future

Obviously, today, working on projects is a little different: AI has a grip on software engineering. But when you use it just right, you are still able to learn and create your reference implementation in a way where you aren't just "vibe coding" - you use it to fill the gaps in the same way a lecturer would. In 2012, I was lucky to find an academic copy of a VTBI interpreter with such good documentation. If I hadn't, I would never have been able to get started in compiler theory. I ported box2d-lite for embedded devices, then used AI to document it for me and help me write the tests for correctness.

Now I have a well-written embedded physics engine and understand the differences between a physics engine and a renderer pipeline. Of course, there is one caveat: the engine is well-written because I have the expertise in C++ to prove it. In terms of learning and education, AI isn't very helpful for things that you cannot verify yourself.

That is up to you.