Transform.position/translate VS Rigidbody2D.MovePosition/velocity

Unity Engine
1

Hello there, awesome people!

I am sorry if this question has been asked already or if it is somewhat stupid.
But I am currently working on an old school 2D platformer in Unity.

I’ve set up my own character controller which kinda works.

However, I noticed that in nearly every tutorial I’ve seen, people tend to use transform.position or transform.translate to move their sprites/objects and give them a kinematic rigidbody2D.

Currently, this is exactly what I do as well and it’s been working quite well.
I use raycasts for collision detection and stuff.

Well, the point is…

Let’s say the player stands directly in front of an enemy. The player and the enemy are both using the same controller script. The player is supposed to take damage if he collides with the enemy.

Since the speed is scaled by Time.deltaTime, there might be potential “skips” in the movement.
Let’s say a player has a real sh*tty PC and is running the game with a framerate of 10 fps.
Now during a frame the player moves, say 16 pixels, forward and so does the enemy.

Therefore, they practically “tunnel” each other and never actually collide.

So that’s why I wonder why people keep telling me to use the transform component.

What is the best way for a 2d platformer to handle such an issue? Should I just use rb2D.MovePosition instead? The built in physics just don’t feel “oldschool” enough, plus I would like to have total control over the physics of my game.

Should I avoid relying on the transform component completely?

I’ve been tweaking around and googling this stuff but I just can’t find the ideal way to handle this.

Your feedback would be highly appreciated.

Thanks for your attention, everybody!
Enjoy your day!

2

Did you finally run in that issue? Im asking cause Time.deltaTime is exactly made for that (to avoid such of problems).

3

What I meant is…let’s say I run the game on a really slow machine. That would result in Time.deltaTime being a relatively large number.

In my game (pixel based) The characters are 16 pixels wide and there are also bullets which are 8 to 10 pixels.

So say I want to move my player 150 pixels a second. Due to the computer being super slow (theoretically) Time.deltaTime becomes. let’s say 0,0333 which is 30 FPS So the movement would be 150* 0,0333 pixels = 4,995 ~ 5 Pixels per Update().

That would not be a problem at all. But, bullets are known to be pretty fast. So let’s say my bullet has a speed of 250. (Actually the desired screenwidth will be 256 pixels, so that would mean a bullet with a speed of 250 needs 1 sec to cross one screen. 250 * 0,0333 = 8,325 pixels, which is still okay.

But, I want my Bullets to become faster if my player shoots them while running, so that it does not look like he can somehow “catch up” with them. So the player’s speed is added to the bullet’s speed. 250 + 150 = 400. 400 * 0,0333 = 13,32 Pixels. This can already become problematic.

Let’s say the bullet is right in front of an enemy. With the next Update it moves 13,32 pixels. Assuming the enemy is moving towards the bullet with a speed of 3,9 ~ 4 Pixels…wait…maybe it’s actually not that big a deal!? oO…

Argh, it just bugs me to know, that the collision is not guaranteed. It depends on the framerate. Even though it would have to drop real low for this to have adverse effects on the gameplay. Still… I would be okay with the fact, that the game becomes unplayable with an abyssal framrate. But not in the “bullets don’t hit me properly so I become kind of invincible-ish” way…It’s just really annoying and I would rather like to be able to rely on a mathematically unbreakable system. Know what I’m saying?