Skip to main content

Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines
(4 edits) (+1)

So it is now known that the amount of speed you get from the big slide at the end of stage 1 on the slope is dependent on monitor framerate. I just did a test on 60hz vs 144hz monitor and on 60hz you literally can't get speed from the slope at all while on 144hz you can get insane speed from it to fly/jump across to the end. Not sure if you can do anything to fix this but its a huge problem because some people can't even Speedrun it if they wanted to now. So if it cant be fixed then separate categories will have to be made for different monitor framerates.

(+2)

holy smokes i cant believe you figured it out!
i guess dev will have to start locking framerates?

(+1)

credit to tryptech for finding that

(+1)

Yeah I noticed that inconsistency in the videos, been looking into it. I thought I programmed the physics to be framerate independent, but Unity can be weird.

(1 edit)

Are you using a deltaTime approach in the Update method or fixedDeltaTime in the FixedUpdate method?

Using deltaTime in Update. But that wasn't the issue. It was just a weird Unity physics thing. I just changed it so I manually calculate the boost speed based on the slope angle instead of letting Unity do whatever it was doing, and it works fine now.

(1 edit) (+1)

Ah, gotcha. To be fair, physics stuff is usually better off using fixed time for this very reason. This article is really helpful in understanding; maybe it'll be useful to you. The article discusses this from the angle of a different issue, but applying physics using regular deltaTime is impacted by framerate.

Great work, by the way, super creative!