Game Mechanics Car game mechanics

[Raiwo]

Hi,
I am currently learning GMS2 and trying to get more into it. For to me learn things i am making drag racing game which is 2D and from top view. So basically button for gas and buttons to up and down shifting. Before i start to play with tire size, gear ratio speed calc, etc. i want to know what are all the different GameMaker built-in properties that i could use.

speed and friction i already know. But i don't really understand the phy_mass, which is calculated automatically. Can i set fixed value like "This object weights 1200kg" and it affects in speed automatically, or do i calculate everything manually and make the output be suitable for GMS speed property?

I want to use as much as possible built-in features, and everything else i code myself.

 

[RefresherTowel]

This is more of a programming question rather than a design, but whatever. There's a bunch of things that are going to be non-intuitive when you're at the start of the learning process. For instance, the inbuilt variables: speed, direction, hspeed, vspeed, etc don't relate to the physics system at all. The physics system: the phy_mass, phy_rotation, physics_apply_*, etc is a completely separate system from the normal inbuilt variables and if you try to use both the physics and the inbuilts, you'll very quickly break whatever you are trying to do.

If you want the car to use the box2D physics system, you'll have to use -only- the physics system. This includes checking the Use Physics box for the objects, turning physics on in the room you are using and then just using the physics based variables to apply forces and torque and stuff to your instances. However, I will say that using the physics system is probably going to be more obtuse to beginners than not using the physics system. It's hard to get the physics to feel right for particular things (for instance, car acceleration, skidding, etc) and without having a good working knowledge of how to tweak coding systems beforehand, you'll be staring into a black box that you cannot control properly.

On the other hand, using "normal" games programming that doesn't rely on box2D physics will be difficult for some of this stuff as well. Realistic physics collisions are harder to do without the box2D physics system and there's a few other things that will be a bit more difficult to get to behave "realistically". On top of all this, using the inbuilt variables (speed, friction, checking the Solid box, etc) can lead to unwanted behaviours in some circumstances. This is why when most people move into more intermediate territory, they end up "reprogramming" a lot of the built-in stuff themselves, so they have greater control over exactly when and how things will be applied. This is why when you see tutorials on RPG movement, for example, you rarely see people code:

if (keyboard_check(vk_left)) {
   speed = 5;
   direction = 180;
}

Or whatever. Generally, they will be doing something like:

if (keyboard_check(vk_left)) {
   x -= 5;
}

If I had to offer a suggestion, I would say forget the physics system for now. You'll find a lot more help and tutorials online using non-physics than you will using physics and, as you are a beginner, tutorials and online help will be your bread and butter of how to do things, at least until you get a handle on it yourself. Just experiment and research and play around. You will definitely not make a great thing on your first few times (or your first few hundred probably), but have fun in the learning and doing rather than the final product and you'll eventually get to the spot where you can execute on what you want to do solidly.

 

[Raiwo]

This is why when most people move into more intermediate territory, they end up "reprogramming" a lot of the built-in stuff themselves, so they have greater control over exactly when and how things will be applied.

First of all: Thanks for the really great reply! That gave me lot.

I bolded part your explanation that caught my eye, because that already happened to me in first hours of GMS2. I felt like i didn't have enough control and i started to do my "RAW" programming, but in the progress i was thinking that if i am trying to invent the wheel again. But your explanation convinced me that, that really might be better way to go.

And i also forgot to mention, that i am not new to programming. I have 20y of experience of programming in software / web side. So i am trying to get my feet wet in GameDev side too.

 

[Yal]

I find the built-in systems work fine for things like debris and bullets, where you just kinda "fire and forget" the objects and it doesn't really matter when whatever they're doing resolves, it's just the player and bosses that needs more precise timing. (Collisions can be handled with place_meeting and a number of different functions, so even if you use the built-in system for bullets and trash mob enemies, you can handle collisions with them whenever makes sense in your tightly controlled player physics pipeline)

Since you're coming from a proper programming background, it could be worth pointing out that GM objects traditionally are really expensive CPU-wise and are meant to represent physical game entities (the next major update will add lightweight data objects) and it's better to represent processes with global data and storing scripts for behavior (if(!is_undefined(state)){script_execute(state);} and such constructs). GM is like perl, you can hack something together that works really easily but it's hard to make something that's readable and organized unless you REALLY try.