I've checked the source code of torcs but it seems quite simple (although the results are very convincing).
My goal was to model a (indoor) kart.
What you're looking for is broadly classified as Multibody Dynamics. You can model each part individually and connect them to make a complete simulation. There are two parts to building these types of models:
1. IDE and Language - Modelica, ADAMS, Project Chrono, SimScape etc. There are open source and commercial solutions for this.
2. Libraries - Claytex, Modelon etc. most detailed vehicle models and components are sold separately. These are typically written in Modelica. Some IDEs like MapleSim or Mathworks bundle it in their IDE.
You can build your own components from scratch but it takes time.
The closest to open source I found is: https://sbel.wisc.edu/2018/07/23/chronovehicle-template-base...
If you want to learn how to do it properly, you can easily find online versions of this book: https://www.elsevier.com/books/the-multibody-systems-approac...
What is missing from Torcs? It looks like a pretty good place to start, it has independent wheel modeling, and suspension, and mass shift of the car (I suspect it can handle mass shift of the driver if that’s what you’re after).
You can probably model frame deformation yourself by building a frame in a physics engine out of flexible parts and/or joints, but I’m skeptical that it’s worth the effort when modeling indoor karts, I’m not sure they flex enough to matter, but it depends on exactly what you’re trying to do.
The car physics my team built was made on top of the Bullet physics engine, so Bullet handled integration and collision dynamics, and we added transmission, braking, suspension, wheels, etc.
It’s definitely worth asking yourself how good you need the simulator to be, and how serious you are about this. It’s a multi-year project to get something “good” and/or better than Torcs. I would tend to agree with their answer to the FAQ question “should I start my own racing sim project?” http://torcs.sourceforge.net/index.php?name=Sections&op=view...
Flexing frames maybe overkill, you seem better placed than me to estimate that.
The FAQ answer address the difficulty of running an OSS project. It doesn't address the difficulty regarding the physics (which, I understand, maybe even more mindbending).
This is a hobby-level project. Nothing serious. I'm more interested in understanding the maths and physics. Having watched hundreds of races (my kid drives), I've seen behaviors which are pretty specific to karts (I guess). For example :
- driver mass shifts do matter (pilots constantly use them)
- karts jump when taking corners too fast and too tight (they usually slide, but when it's too much, they do jump, and decelerate...)
- turning wheels left/right very fast is used to brake during pit stops.
but you're right, I may be out of my league here :-)
The other thing I’d add is that the physics models is only half the battle. The car and track geometry is critical to making an accurate simulation. It’s easy to get wrapped up in the car physics and forget to deal with the angles and bumps and materials and temperature of the road surface.
Cameras are huge too, if you do anything other than a fixed interior cam. A naive follow can behind a car can totally undo all the physics.
So I completely agree, and I guess this FAQ answer is really meant to talk to the casual developer who doesn't know what they're getting into. The person who does know and does it anyway will (and should) ignore stuff this like. I don't think it was meant to be condescending, I took it more as a joking tone but with a real warning that it's a long road, which is true.
this is a good starting model https://github.com/spacejack/carphysics2d
I wrote an extension for it that handles loss of traction, power drifting and mapped terrain friction that I can share, it's all mit licensed after all, but it's in Java, it's simple enough to port it whatever language you want because it's just math primitives
Simulating this is what interests me because it seems absolutely non obvious.
As said by someone else, maybe I'm looking at a problem that his out of my reach (my physics skills are rather weak). That is, I have no idea of how that happens.
I'm not a physics person either, but wheel hop seems to occur when the force overcomes friction between tire/track, causing an oscillation between grip/no grip. It is a lot worse on vehicles with suspension, because they have more give.
I find it easier to visualize with a car, because it is more pronounced. Although with a car it is usually occurs on a standing start, whereas with karts it is a lateral force thing.
This karting forum suggests high center of gravity contributes to wheel hop.
But simpler games model cars pretty well, I’m assuming with a dozen or so parameters (turning radius, acceleration, tire grip, suspension..) you should get something. The “pako ios car simulation” (not open source), has a bunch of cars you drive around that behave more or less like actual cars.
before you venture there I suggest you move the control code outside of the physic code, abstracting car inputs into a throttle, brake, steer structure which is piloted by inputs elsewhere and feed into the physic update tick along with the car state, or it'll make exceptionally hard to build input prediction and lag compensation further on
Now just make it isometric with collision detection and use maps built with this (currently also on the front page):
I found that phaserjs is a good engine but you still have to do a ton of stuff that other engines give for free. Chiefly, the rich game dev UI that Unity, Godot, Unreal, etc. all have. Don't be discouraged by the different languages. Programming is like 15% of game dev and you can easily make a fun first RPG using examples and stack overflow, and get comfy with a new language along the way.
(But spoiler, it's just about moving relative to where you start touching... press then move up the screen to go straight.)
Both frontend and backend are open source and work straight away without bundling, if you want to fiddle around:
Pull requests also welcome! ;)
Yes, that turned out to be a legitimate concern... later on I saw people go a step further and write entire sentences out of cars... they probably didn't realize but it was effectively DoSing your server and preventing anyone else's socket emits getting through so all you could see is the text.
I guess it's a difficult balance if you want to allow playful hacking but don't want to be DoSed. (BTW it's easy to bypass the origin restriction by just injecting code into the browser), perhaps a better restriction would be a max sockets per session or IP, that would still allow some hacking but reduce chance of DoS intentional or not.
Anyway I changed tack to try implementing some basic bots in smaller numbers. Was fun to see how people interact with them.