Physics-based car driving

.capx https://www.dropbox.com/s/lpnr1lvd6eerzvk/RaceTheRadar%20v%201-9.capx?dl=0

EVENT SHEET: E Car Controls

I'm trying to set up a simple racing game where the driving is all based on physics. (I'm getting help from sqiddster, too, but he's busy with his game Airscape, so I don't want to solely rely on him). The ultimate goal here is to allow for smooth drifting through turns that are natural and flowing. I have been trying to use the Car behavior, but I can't quite get the mechanics solid. At best it's manageable; at worst it's like the car is sliding on ice through turns.

My initial efforts are basic; just setting up the acceleration. My issue is that no matter how even I try to apply the force, the car continues to drift laterally to the left and enters a spin (the wheels also get disjointed when colliding with the layout boundary or an invisible wall I have set...makes me very glad I'm not in the car sales business anymore).

I have made sure the car height (with frontend initially facing right, or 0 degrees) is an odd number so that the center point where the force is applied is "dead center". But this still had the car drifting laterally. So, I applied force to both of the rear wheels to try to balance out any lateral drifting...no dice; it still starts to spin slowly.

Now, I get the general gist of physics here...well...what I remember from 8th grade. LOL But as applied in C2, I'm having trouble understanding what C2 is "thinking" when taking what I've programmed. I'm trying to read C2's mind so I can figure out what I need to change and why it's processing something different than what I intended.

I'd appreciate any input and suggestions to solve this matter and to understand the C2 physics engine.

(PS - I have read the manual and the tutorial by ASHLEY.)

BUMP

I'll ask some questions while I humbly offer my thoughts - I hope this makes sense! Firstly - why use physics - is it to enable car bumping and the like on the track? If so, seems like a good idea to get around the problem of overlapping car sprites etc. I can't think of another reason to use the engine for this type of game.

I see no point in applying forces to the car's wheels to make the car move. In fact, I see no reason in attaching the wheels as physics objects to the car by using joints - remember, it's a viewed from above racing game, so you can manipulate the main car sprite to achieve the 'being driven' visual effect that you desire without making it too complicated to manage under the hood.

Also, rather than applying a force to the car, I would manipulate its velocity directly through events. Doing that won't kill the physics behavior but it will allow you more precise control over the car's velocity - like whether it goes where it is pointed, how quickly it rotates and appears to turn etc (so you can make it change direction on a dime or appear to slide - heading and velocity vector not the same, for example).

I have no idea why it should veer to the left like that in the example - perhaps the wheel positions are not equidistant from the car's center of mass, which causes the gentle apparent turn. I also saw that collisions between the car and the wheels were not disabled, so all sorts of strange joint fighting could be going on between the wheels and the car's body...

Just my 2 pennies' worth - hope it helps!

Colludium - Dude, that was like a whole DOLLARS worth! Thank you!

The reason for the physics at all was at the suggestion of Daniel (@sqiddster), whose judgment I trust. He's certainly a lot further along than I am and his game, "Airscape", proves to me he's got insight where I don't. And he set up a pretty solid sample car driving capx using physics. So I was just following his lead.

In his example that he created for me, he was using for wheels rather than just applying force to the body, as you described. So I was trying to emulate his lead.

Anyway, all that's to say that I'm still trying to figure these finer details out. LOL

And yes, the purpose of the physics behavior was specifically so that objects - cones, tires, barrels - that are collided into react as believably as possible. But the vector manipulation does sound more adaptable and easy.

Colludium

My thought process behind giving the car actual wheels as opposed to just making it a box, was that it would be much easier to get realistic driving naturally. This way, the driving physics work just like they do in real life without any weirdness behind the scenes. You can also do things like adjusting the friction coefficients for the tires etc.

Why would you apply velocity rather than use forces? You say it won't kill the physics behaviour, but it certainly won't play nice - there's really no reason to *not* use forces as far as I can see.

In terms of 'why use physics at all', it's definitely a valid question, but if you've seen how bad the car movement felt when running into anything (i.e. it would come to a dead stop when just skimming a wall), then you'd be able to see why I suggested the move to physics. I'd be open to seeing a counterexample, but physics just seems more intuitive, and quick to get up and running, which is key!

I cant check at the moment but turning on prevent rotation for the wheels/ tyres should stop the slow spin. Although i have never made a game like this i assume you need gravity set to zero in which case i am not sure how you can apply friction in a true physics sense.

—, I didn't mean to come over as if I was flaming the use-physics idea. I think I would also use physics to tackle this, just for the collision behavior between cars. I'll try and put together an example of how I would address the controls etc - either I would not use extra physics objects at all (and just manage the car's velocity and rotation by equations and variables) or, more likely - use a physics action object attached to each of the car's axle points (intuitively easier to manage the car's behavior, but I suspect that controlling skids, understeer and oversteer would be v hard).

Here you go - try L Race 1 because there are a few obstacles in the way for you to steer around. No forces, only manipulation of the car's velocity to accelerate at the car's angle, to decelerate when not accelerating (you would need to add to this to make it variable to whether or not the car is skidding), and to control the car's angular velocity if it's steering (same deal with respect to whether or not it's skidding). Hope this helps!

link to file in dropbox

sqiddster - "In terms of 'why use physics at all', it's definitely a valid question, but if you've seen how bad the car movement felt when running into anything (i.e. it would come to a dead stop when just skimming a wall), then you'd be able to see why I suggested the move to physics."

THAT was more of my doing because, given the drift settings in the Car behavior, certain collisions resulted in odd sideways movement that ought not to have happened. It was the lesser of two programming evils. I was trying to figure out a work-around and that was what I came up with at the time. ALSO why I decided to push back the near- and on-track obstacles as we had talked about.

Colludium - Thank you. I shall check it out.

One of the things Daniel has been trying to help me with is to keep to the KISS principle so I can actually FINISH a game AND make it FUN. So, I've been struggling to strip back features while still maintaining a quality game at its core. I've spent the last two years slooooooooowly learning how to do that AND how to program with C2, itself. Anyway, long story short, I appreciate the feedback and the suggestions. I need it so I can try things out and figure out what works for my ultimate goals.

spongehammer - I realized (or Daniel pointed out to me) that part of the problem was that the wheels are attached at a single joint and not being made to stay straight. They were simply reacting to the in-game physics...even if I was applying force dead-center.

Colludium - Just tested your example... WHOOOOAAA!!!

That might work!

I've spent the last two years slooooooooowly learning how to do that AND how to program with C2, itself. Anyway, long story short, I appreciate the feedback and the suggestions. I need it so I can try things out and figure out what works for my ultimate goals.

This is exactly the same boat that I find myself in. I've had a bunch of false starts and only recently found satisfaction with my sketch book project. I enjoy the maths and technical side of working with the c2 editor but it takes so much more to stick with it until everything is done to a good standard.

More than happy to help!

Colludium - Alrighty...looking over your revision, in the first Function, "speed and velocity calc", you take the square root of the the sum of the X and Y velocity values each squared.

Why the square root? What is the meaning of the maths here? LOL

Also, what is an "arccosine". Even in my brief time in Trig/Calc in high school, I do not recall ever learning about this.

Rhindon, maths, trigonometry and engineering physics are my forte - but not when I'm tired LOL - which is why I love C2 because I'm also, it seems, unable to learn how to code effectively (and I've tried - I just don't have the patience / aptitude!).

Why the square root? What is the meaning of the maths here? LOL

All I was doing was applying Pythagoras' Theorem to the data from the physics behavior. It's a fancy way of saying that I took the velocityX and velocityY values from the physics behavior and added them together to determine the overall velocity of the object. They can't just be added together, though, they need to be squared before they are added - by taking the square root of that sum it allowed me to work with a pixels per second value, which is easier on my brain, although not strictly necessary. This explanation does a better job than I can to explain how it works, if you're interested!

Also, what is an "arccosine". Even in my brief time in Trig/Calc in high school, I do not recall ever learning about this.

The arccosine of an angle is simply the inverse of the cosine of an angle. LOL - I must have been tired when I put that example together - luckily I stopped trying to calculate whatever it is I was thinking of by using that equation. It simply won't work - if the velocityY is zero it will return NaN.... Oh well... I'll go and edit it out of the original - the shame!!

The correct equation would have been: velocity angle = arccos( velocityX / sqrt(velocityX^2 + velocityY^2) )

Colludium - Thank you for the explanation. I will surely need to study up, but I think I follow at least a little. I may call on you later for further assist.