I'm sorry, I really want to like and understand this, but the diagrams are worthless and mostly incomprehensible.

I would've liked to understand more about why it works the way it does, how it achieved the correct feel etc, not just regurgitate whatever the code does.

I would've liked to know more about how the author achieved what they did, not a blog post anyone with an llm could've written.

What in particular would you like to know?

As I said in the summary article, the core is a "textbook" 2D rigid body simulation (the "Brick" layer), and the Car bit mostly a matter of deciding what forces are applied to the tyres.

In short, the tires "like" to go back and forward, but resist going sideways (relative to the direction they are pointing in).

The forces which are applied at the tyres are roughly equivalent to friction, but not quite (friction is stranger than people think, and is not actually very velocity dependent). In some ways my tyre forces actually behave more like a form of "viscous drag" actually. I knew this was a bit dodgy at the time, and it was a sort of conscious "hack" that was chosen to produce "playable" behaviour as simply as I could.

The diagrams seem to have been written (or generated[1]) while looking at the project source code, and use the sort of bass-ackwards approach to code documentation of giving a “post-hoc summation” that only makes sense when you’ve already read the code, rather than serving as an introduction to the code for someone who hasn’t read it yet.

That being said, AFAICT, the diagrams are also basically irrelevant to the article in its capacity as a high-level overview of the project. You can just ignore them for the purpose of reading the article.

It’s when digging into the project source code that you should look at those diagrams, and then feel frustrated by how much they suck. :)

===

[1] This seems to happen a lot with LLM-generated code docs / diagrams / etc, when the docs are written in the same session as the code itself, but later; the LLM seems to see the docs as “following” the prior work in its linear context, and so mistakenly writes as if the reader of the docs will have also read whatever’s in the context before getting to the docs. That assumption, of an incrementally-growing shared context that can be implicitly made reference to by “later” text to compress that “later” text, makes a lot of sense when generating one long linear stream of prose, or even when generating a series of chain-linked entries (like conversation responses, or chapters of a book); but doesn’t work out when generating a web/graph of separate bits of text. This is kind of a fundamental flaw in producing coding agents as fine-tunes over conversational base models, and it’s one that coding-agent harnesses have yet to really focus on addressing.

Yes, without really solid direction, agents will produce absolutely impenetrable diagrams. "The single biggest problem in communication is the illusion that it has taken place."