When mentioning foundational 2d driving models one simply can't omit Marco Monster (2003) [1].
Also Physics for Game Developers (2001) had a hilarious chapter dedicated to car racing simulation. Most of the chapter is dedicated building the scene in a minute detail - for instance pointing out that the center of gravity of the car will change during the course due to fuel consumption - only to simplify and cancel out most things at the end to leave the reader with just a handful of variables.
Let's not forget Dr. Brian Beckman's The Physics of Racing Series, at the time he was a researcher working at Microsoft on the Forza video game series.
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.
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.
Just the little bits of text glueing the (yes, machine generated) diagrams together as I recall, when I was indeed trying to finish the thing off in a bit of a hurry.
When you give even an inch to an LLM like this, people will assume you did it all like that. And it’s not a bad assumption given what’s out there these days.
As I said in the summary article, the core is a "textbook" 2D rigid body simulation (the "Brick" layer), and the Car bit is 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 many 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.
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."
GTA I and II had really fun car physics. Just driving around and evading police was fun, in a way the later 3d games in the series didn't quite capture for me
Losing control of the vehicle in birds-eye view felt closer to reaching my human limits than reaching the vehicle limits, I really missed that with the change to 3D. The whole city also truly felt like it was designed around the birds-eye view, like the group of Hare Krishna (GTA I) or Elvis impersonators (GTA II) behaving like virtual ants when rushing into them was always something magical and wasn't quite the same in 3D.
I also miss this a lot. I've been wanting a modern remake for so long. Hotline Miami wasn't even close.
All the GTA games before GTA3 felt like a mischievous schoolboy's notebook come to life. In fact, I'd be surprised if half the people growing up playing this in the 90s weren't sketching their own GTA2 maps when bored in class.
It still feels great to play! I love the history too, it's actually a great example of why prototyping "toys" is so important in product development. It allows you to play with isolated concepts without baggage or the expectation to make things production grade. Just getting straight to the point.
Cool project. Have you tried to implement articulating drawbar trailers[1]? The ones where the first axle of the trailer is fixed to the drawbar, making the front wheels turn when the drawbar moves. They seem to be much more common in Europe than in the US. In my experience, these are much harder to back up than fixed axle trailers.
I think the fractal solver is bugged, but maybe I am just using it wrong. It says placing a cone in the red zone will block the vehicle, but either the colors are inverted or the backend is off, because everything is red except a few spots.
Otherwise very fun. I managed to park a truck the solver called impossible :)
I ruined someone's car park learning to do handbrake turns, about 5 years before GTA 1 came out. But (coincidentally) only a few miles from Dundee where GTA was developed! I went to university with some of the people who had done Lemmings levels.
I knew about tires prices and cable wear on non hydraulic handbrakes so I really only played with the scandinavian flick or the handbrake on snowy days.
Interesting that he namechecks Thrust from 1986, an absolutely amazing game for the BBC Model B, and I guess the first 'physics' game I ever encountered. The 'towing' physics were amazing.
There was a demo of a remake in progress on the Archimedes which did the rounds back in the 90s which was also amazing https://www.youtube.com/watch?v=jssOIpGYH3E which was the first game I saw do real time anti aliased line rendering for the ship-ball connection.
This is really cool. A few months back I wanted to re-create the gta feeling in 2d myself with claude - I have no idea how to write games.. After about a few weeks it ended up in 3d, and completely different, and nowhere near as fun.
I have been trying on and off to achieve this for years and what really bothered me was at slow speeds (reversing into a parking space), my vehicle would move laterally to the wheel direction. I could never solve that issue without hacking it which really annoyed me. Last time I tried was during covid. I picked up "The Multibody Systems Approach to Vehicle Dynamics - 2004" for 99p in a local charity shop. Far, far too advanced for me but I did manage to simplify it with google and some questions on stack to get nice handling. Alas that slow speed lateral motion, just knowing it was there made me shelf it again.
I am determined not to use a LLM or even this article to solve it at some point in my life.
I made a parking simulator a long time ago. To make it realistic, you have to take into account that each wheel turns at a different angle. Both turning wheels need to turn at an angle that meets in the same point of a line that comes out of the back wheels. And, at low speed and acceleration, there is no drifting. To determine how the car moves, since all the wheels point to the same intersection point, just do angular movement of the car pivoting on that point, making angle * radious of the center of the drive wheels match the speed of the car. Wheel differential compensates for choosing the center of the wheels.
I'd like to see the code that goes with the diagrams.
I'm into go karts and they turn on three wheels because they are a solid rear axle, and the front wheels have a lot of caster. Is live to try to model that.
It's not bad but the challenge/balance really is off: I was maxed out everything around wave 10 and it's just never a challenge. Maybe it gets a challenge by wave 30 or so due to sheer number of enemies, but what's the point then?
That, saving and some nice splatter sounds would be add to the entertainment ;)
Yes, it feels like the memory I have of driving and sliding in GTA 1 and 2. Cool that you have posted this. I like the way you have modelled the physics as simply as possible while still giving a realistic feel.
Can you please add a "parking simulator" mode? Iam not joking, my SO wants a simple way to train parking and I think that could work very well. Or maybe just let one draw obstacles.
If you accelerate the Car, then switch the configuration from Car to Brick, the brick won't slow down.
Not sure whether is it intended but it feels wrong.
The original was very similar, but with minimum UI (no "Settings" panel), and it was just black on white line drawings, although I did add skid trails etc. after I'd got the core of it working.
StopTheMadness Pro users on iOS: exempt website, so you won’t keep selecting the text on the controls. May still highlight the “Speed Zoom on” line though.
>One weekend in late August 1996, I wrote a 2D physics simulation which later became the basis of the vehicle system in the eventually popular game "Grand Theft Auto" aka "GTA".
I don't mean to be... judgemental, but if you had the talent to go something like this, why devolve on the remake? One could think that a person with your level of skill would be one of the main vanguard for hand coding. Again, I don't want to be too judgemental, as I am not a great programmer and use assisted tools when planning and designing personal apps, but I am just curious.
Why needlessly do extra work when it's easier than ever before to modernize what is already made? Why would he want to be a vanguard for "hand coding"?
So often it feels like people lose track of the actual conversation happening in the comments in favor of posting a cute quip for points...
This thread originated with one poster expressing disappointment that someone of the author's acumen would choose this path, and another poster asked why the author (or someone of their skills) should have chosen a different path. I weighed in with an answer to that question.
Obviously the author did not see things the way I suggested, or else the conversation would not have happened.
If hand coding doesn't matter, why have your ai write a lengthy explanation on the implementation and architecture of some feature? You don't think this juxtaposition is a bit odd?
I never said manual coding doesn't matter and I don't think anything Kerr wrote implies that he thinks that either. Nor does using LLMs to code mean the implementation and architecture doesn't matter.
I've been a developer for not nearly as long as the author but long enough that at some point it felt like I was writing the same code and same abstractions over and over again and sometimes a new novel problem would reinvigorate my love of programming but today I'm happy to let an LLM write the tedious code while I give the more fun high level architectural direction and when reviewing the code sometimes I'll give it a nudge in a different direction. I suspect the author has written code like the 2d car physics many times over. Just my 2 cents.
When mentioning foundational 2d driving models one simply can't omit Marco Monster (2003) [1].
Also Physics for Game Developers (2001) had a hilarious chapter dedicated to car racing simulation. Most of the chapter is dedicated building the scene in a minute detail - for instance pointing out that the center of gravity of the car will change during the course due to fuel consumption - only to simplify and cancel out most things at the end to leave the reader with just a handful of variables.
[1] https://www.asawicki.info/Mirror/Car%20Physics%20for%20Games...
Let's not forget Dr. Brian Beckman's The Physics of Racing Series, at the time he was a researcher working at Microsoft on the Forza video game series.
https://www.youtube.com/watch?v=I8GQCZgCNw8
I built an OpenGL car physics simulation as an undergrad as a project (pre-Claude). It was very fun.
Oh yeah, Physics of Racing Series was fantastic. I’m going to have to dig that up again. Also did a deep dive into it in undergrad and had a blast.
Pretty cool to click the link and find it has been bookmarked for a decade on my end :-)
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.
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.
"One body, three behaviours"
Much of the text is generated as well.
Just the little bits of text glueing the (yes, machine generated) diagrams together as I recall, when I was indeed trying to finish the thing off in a bit of a hurry.
I wrote the rest of it "by hand" though.
When you give even an inch to an LLM like this, people will assume you did it all like that. And it’s not a bad assumption given what’s out there these days.
The first part read human written, then it degenerated into slop. Nice javascript demo though
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 is 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 many 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.
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."
GTA I and II had really fun car physics. Just driving around and evading police was fun, in a way the later 3d games in the series didn't quite capture for me
Losing control of the vehicle in birds-eye view felt closer to reaching my human limits than reaching the vehicle limits, I really missed that with the change to 3D. The whole city also truly felt like it was designed around the birds-eye view, like the group of Hare Krishna (GTA I) or Elvis impersonators (GTA II) behaving like virtual ants when rushing into them was always something magical and wasn't quite the same in 3D.
I also miss this a lot. I've been wanting a modern remake for so long. Hotline Miami wasn't even close.
All the GTA games before GTA3 felt like a mischievous schoolboy's notebook come to life. In fact, I'd be surprised if half the people growing up playing this in the 90s weren't sketching their own GTA2 maps when bored in class.
I still remember GTA 2 had the best radio
Laughing vampires dance!
I love the japanese girl screaming in the loony gang radio with the drum and bass!
"The world's on fire, man, when you swallow down Lithium!"
It still feels great to play! I love the history too, it's actually a great example of why prototyping "toys" is so important in product development. It allows you to play with isolated concepts without baggage or the expectation to make things production grade. Just getting straight to the point.
Great story, programming and mechanics.
Thanks. I'm glad you got something out of it.
no dynamics model (uses bicycle model) but i built a solver for parking
http://truckslop.joshu.dev/
Cool project. Have you tried to implement articulating drawbar trailers[1]? The ones where the first axle of the trailer is fixed to the drawbar, making the front wheels turn when the drawbar moves. They seem to be much more common in Europe than in the US. In my experience, these are much harder to back up than fixed axle trailers.
[1]: https://www.pacton.nl/en/products/drawbar-trailer/drawbar-tr...
The visualization of potential results is quite mesmerizing.
“One cone (Joshua)” is wild for the exploration it does before settling on a solution!
yeah that one really tortures it
That was a lot of fun to play with.
I think the fractal solver is bugged, but maybe I am just using it wrong. It says placing a cone in the red zone will block the vehicle, but either the colors are inverted or the backend is off, because everything is red except a few spots.
Otherwise very fun. I managed to park a truck the solver called impossible :)
Note: Using safari on an iPad of that matters.
can you post a screenshot? i haven't tested on ipad
This is pretty fun!
Is it actually solving anything though? It always seems to get stuck with the semi half sticking out.
try different maps, editing the constraints, etc? it's sortof a "torture the optimizer" but it does solve many things
This is what taught me how to do handbrake turns.
And shortly after I learned how expensive tyres were, I stopped doing handbrake turns.
GTA didn't exist back then, so I had to learn them from the lore.
And shortly afterwards, in addition to all the different physics-in-action experience, I learned about how car insurance excess works.
I ruined someone's car park learning to do handbrake turns, about 5 years before GTA 1 came out. But (coincidentally) only a few miles from Dundee where GTA was developed! I went to university with some of the people who had done Lemmings levels.
I knew about tires prices and cable wear on non hydraulic handbrakes so I really only played with the scandinavian flick or the handbrake on snowy days.
Interesting that he namechecks Thrust from 1986, an absolutely amazing game for the BBC Model B, and I guess the first 'physics' game I ever encountered. The 'towing' physics were amazing.
https://youtu.be/Dt44PEIWBRg?is=CbVTRyDfo8Nt56fH
Thrust was by Jeremy C. Smith who went on to work on Exile with Peter Irvin
There was a demo of a remake in progress on the Archimedes which did the rounds back in the 90s which was also amazing https://www.youtube.com/watch?v=jssOIpGYH3E which was the first game I saw do real time anti aliased line rendering for the ship-ball connection.
To the creator, thank you. I spent many years almost 2 decades alter playing multiplayer gta2 with my good friend during late night sessions.
Thank you for a great little physics engine
You're very welcome.
This is really cool. A few months back I wanted to re-create the gta feeling in 2d myself with claude - I have no idea how to write games.. After about a few weeks it ended up in 3d, and completely different, and nowhere near as fun.
https://2e7b8cb5.city-driver.pages.dev - remember to do ignition, and start the car
I have been trying on and off to achieve this for years and what really bothered me was at slow speeds (reversing into a parking space), my vehicle would move laterally to the wheel direction. I could never solve that issue without hacking it which really annoyed me. Last time I tried was during covid. I picked up "The Multibody Systems Approach to Vehicle Dynamics - 2004" for 99p in a local charity shop. Far, far too advanced for me but I did manage to simplify it with google and some questions on stack to get nice handling. Alas that slow speed lateral motion, just knowing it was there made me shelf it again.
I am determined not to use a LLM or even this article to solve it at some point in my life.
Thanks for sharing.
I made a parking simulator a long time ago. To make it realistic, you have to take into account that each wheel turns at a different angle. Both turning wheels need to turn at an angle that meets in the same point of a line that comes out of the back wheels. And, at low speed and acceleration, there is no drifting. To determine how the car moves, since all the wheels point to the same intersection point, just do angular movement of the car pivoting on that point, making angle * radious of the center of the drive wheels match the speed of the car. Wheel differential compensates for choosing the center of the wheels.
That's an interesting problem, and I can't immediately see why you would keep getting a side-effect like that.
Good luck with figuring it out!
Hello. I am the Pat Kerr in question.
Where can I look at the source?
I'd like to see the code that goes with the diagrams.
I'm into go karts and they turn on three wheels because they are a solid rear axle, and the front wheels have a lot of caster. Is live to try to model that.
Just use "view source" from inside Motion Lab.
I deliberately kept it as plain JavaScript with no aggressive obfuscation.
There are even some comments! ;-)
https://games.zabaca.com/games/roadkill/ just created this and added a zomebie survival mode on top
I just sunk an hour into this. I'm feeling better already.
It's not bad but the challenge/balance really is off: I was maxed out everything around wave 10 and it's just never a challenge. Maybe it gets a challenge by wave 30 or so due to sheer number of enemies, but what's the point then?
That, saving and some nice splatter sounds would be add to the entertainment ;)
omg yes thats awesome, please add save-game functionality i wanna play more later but i have to go touch grass
I wrote a 2D car physics engine, using Verlet integration. Unfortunately, I wrote it in ActionScript instead of something sensible.
It did work great though.
Yes, it feels like the memory I have of driving and sliding in GTA 1 and 2. Cool that you have posted this. I like the way you have modelled the physics as simply as possible while still giving a realistic feel.
Can you please add a "parking simulator" mode? Iam not joking, my SO wants a simple way to train parking and I think that could work very well. Or maybe just let one draw obstacles.
There are various games that do this pretty well. For example: https://store.steampowered.com/app/4265570/Parking_in_Tight_...
It's probably not a realistic enough simulation to be a viable learning aid, but that's a funny idea.
I might build something else on top of this though, and will try to keep parking in mind!
Its more like focusing on more than one thing (little momentum) while also figuring out how to steer. It doesn't have to be overly realistic.
Nostalgic!
It'd be amazing to hook is up with the engine sound simulator: https://github.com/ange-yaghi/engine-sim
I just learned that when you are going 300mph,if you turn, you'll come to a smooth near sudden stop
I built a 2d iOS game using this concept a while ago. It was built using SpriteKit: https://apps.apple.com/us/app/drift-mania-infinite-car-racer...
This feels incredible to play, even with the simple graphics. Wow. Top class
Thanks. I'm glad you liked it.
Oh how I loved driving around in GTA 2!
Thank you for your great work there and for sharing how you did it. I felt nostalgic playing with the model.
Why I like it and always have:
1. Hold accelerate for three seconds
2. Press handbrake and right for half second
3. Hold decelerate for three seconds
4. Press left for half second.
5. Goto 1.
If you accelerate the Car, then switch the configuration from Car to Brick, the brick won't slow down. Not sure whether is it intended but it feels wrong.
There isn't much "air resistance" (or general velocity dampening) on these things, and the velocities carry over when you change the body's "shell".
So, it's sort of intended, but also not very significant one way or the other.
Going backwards while holding handbrake makes perfect circle :)
It's an interesting project, although not a physics expert I am so curious what the original version looked like!
The original was very similar, but with minimum UI (no "Settings" panel), and it was just black on white line drawings, although I did add skid trails etc. after I'd got the core of it working.
I speak for an entire generation of people when I say thanks, nice job with this
This is painfully awful Claudeslop. They didn't even bother changing the default style.
Correction, it was some mildly ChatGPT-assisted PatSlop.
I speak with some authority on the matter. ;-)
Even that little simulation is really fun. I’d like to play a little 2D game with this mechanic.
Maybe I'll make one, if I get time, and am not distracted by other things.
the classic ship feels great to control. It reminds me of flying FAO in Elite Dangerous. Thank you!
Really nice. GTA 1 & 2 were really amazing. I had a lot of good times with them.
d doesn't turn right for me, but shift+d does. Arrow keys do work though.
Likely to be widely used
I think this is just Autodesk Vehicle Tracking
Can we implement this inside an original GTA / GTA2 port?
Feels like the original, just need some thing to run over.
GFA Basic !… So many memories are coming back to me.
I liked your idea. It was really cool.
AI content.
Learn from the old master... with a big stinkin' LLM interposed!
Partial AI use, yes, on the diagrams -- somewhat as an experiment to see whether it was any good. I thought it was better than nothing.
But the core text was hand-written, and the code faithfully represents the logic of the hand-crafted original from 30 years ago.
The overuse of words such as ”deliberate” give it away.
I actually use that word quite a lot in normal writing, and find that my general tone is quite bot-similar.
I am nevertheless unworried by this. ;-)
#replicant
Now we know The Source!
Really nice game
no understeer? fronts are too grippy
> It began as a little wireframe demo written in GFA BASIC on my Atari ST home computer (and was later ported to C for use in the actual game).
The Atari ST is in the news today on HN! (there was a TFA about the Atari Falcon, which was a really big Atari ST).
StopTheMadness Pro users on iOS: exempt website, so you won’t keep selecting the text on the controls. May still highlight the “Speed Zoom on” line though.
no clutch = no clutch kick drifting
>One weekend in late August 1996, I wrote a 2D physics simulation which later became the basis of the vehicle system in the eventually popular game "Grand Theft Auto" aka "GTA".
I don't mean to be... judgemental, but if you had the talent to go something like this, why devolve on the remake? One could think that a person with your level of skill would be one of the main vanguard for hand coding. Again, I don't want to be too judgemental, as I am not a great programmer and use assisted tools when planning and designing personal apps, but I am just curious.
Why needlessly do extra work when it's easier than ever before to modernize what is already made? Why would he want to be a vanguard for "hand coding"?
Sometimes the reward lies in the doing, not in the done.
He's already done the doing.
Yes, I recall well the famous words of Claude Monet: "Well, I painted one scene of water lilies. That should be more than enough for a lifetime."
LOL!
I am the author of this thing, and I find your comment very amusing. ;-)
And for that same reason people knit their own scarves but they don't expect the scarf they see at the store to be hand knit.
> Sometimes
Ah, another [0] manifestation of the literacy crisis. A tragedy.
[0] https://news.ycombinator.com/item?id=50036647
And sometimes not.
Seems the author chose option 2 and focused on the article instead.
So often it feels like people lose track of the actual conversation happening in the comments in favor of posting a cute quip for points...
This thread originated with one poster expressing disappointment that someone of the author's acumen would choose this path, and another poster asked why the author (or someone of their skills) should have chosen a different path. I weighed in with an answer to that question.
Obviously the author did not see things the way I suggested, or else the conversation would not have happened.
If hand coding doesn't matter, why have your ai write a lengthy explanation on the implementation and architecture of some feature? You don't think this juxtaposition is a bit odd?
I never said manual coding doesn't matter and I don't think anything Kerr wrote implies that he thinks that either. Nor does using LLMs to code mean the implementation and architecture doesn't matter.
I've been a developer for not nearly as long as the author but long enough that at some point it felt like I was writing the same code and same abstractions over and over again and sometimes a new novel problem would reinvigorate my love of programming but today I'm happy to let an LLM write the tedious code while I give the more fun high level architectural direction and when reviewing the code sometimes I'll give it a nudge in a different direction. I suspect the author has written code like the 2d car physics many times over. Just my 2 cents.