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.
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
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.
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.
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.
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.
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.
I'd say you're fully off the mark here. That page contains serious architectural insight on how to make a "designed" car feeling work within a "physically correct" collision engine. Getting the balance right is super hard and he explains how to do it. I'm confident no AI could do that architecture, so this is most likely hours of hard work with a thin layer of LLM gloss on top.
No, I don't want to see the prompt. Yes it has some llm tics, but it's clear that he went back and forth before arriving at this. Why would I be interested in the transcript?
yes and? someone sharing the details of an extremely popular project is super cool. comments like this will not encourage more people to share more cool things.
I'd be ecstatic if more people used AI to share more cool things they've done. that'd be awesome. more of this blog post please.
But very little of the author shines through here, at least after the intro. I, too, would like to hear more about how someone built stuff, but this is not it.
>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"?
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.
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.
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. It was very fun.
This feels incredible to play, even with the simple graphics. Wow. Top class
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
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!
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.
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.
no dynamics model (uses bicycle model) but i built a solver for parking
http://truckslop.joshu.dev/
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.
The visualization of potential results is quite mesmerizing.
This is pretty fun!
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.
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.
Hello. I am the Pat Kerr in question.
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.
Nostalgic!
It'd be amazing to hook is up with the engine sound simulator: https://github.com/ange-yaghi/engine-sim
GFA Basic !… So many memories are coming back to me.
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.
Even that little simulation is really fun. I’d like to play a little 2D game with this mechanic.
d doesn't turn right for me, but shift+d does. Arrow keys do work though.
Really nice. GTA 1 & 2 were really amazing. I had a lot of good times with them.
> 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).
Really nice game
Feels like the original, just need some thing to run over.
AI content.
Learn from the old master... with a big stinkin' LLM interposed!
I liked your idea. It was really cool.
It's an interesting project, although not a physics expert I am so curious what the original version looked like!
I'd say you're fully off the mark here. That page contains serious architectural insight on how to make a "designed" car feeling work within a "physically correct" collision engine. Getting the balance right is super hard and he explains how to do it. I'm confident no AI could do that architecture, so this is most likely hours of hard work with a thin layer of LLM gloss on top.
No, I don't want to see the prompt. Yes it has some llm tics, but it's clear that he went back and forth before arriving at this. Why would I be interested in the transcript?
Pangram says the first half is human and second half is gen AI.
Ran out of steam, I guess...
Why didn't you check each sentence manually for signs of LLM use, and instead sloppily let Pangram do it for you?
yes and? someone sharing the details of an extremely popular project is super cool. comments like this will not encourage more people to share more cool things.
I'd be ecstatic if more people used AI to share more cool things they've done. that'd be awesome. more of this blog post please.
But very little of the author shines through here, at least after the intro. I, too, would like to hear more about how someone built stuff, but this is not it.
This is good shit
>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"?
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.
Sometimes the reward lies in the doing, not in the done.
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.
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."
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.
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.