Skip to main content

On Sale: GamesAssetsToolsTabletopComics
Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines
(+1)

I see... Sorry about that! I'm still pretty new to Godot so I think I used the wrong functions for movement (or put the controls in the wrong place...) 

Thanks for playing and for pointing out the bug! Shall (attempt to) fix it in a post-jam version!

I get that. I started using Godot for game jams a few years ago. I've been happy with Godot, but it does take some getting used to.

I assume the game handles the rotation in the _process(delta) function, so the quick fix is to include the delta argument in the calculation for how much to turn. The delta argument indicates how much time has passed since the last _process call, so scaling by the delta value will account for faster framerates. Godot can be weird, and sometimes it's needed and other times not. Eg. for KinematicBody2D, move_and_collide() requires multiplying by delta, but move_and_slide includes a delta multiplication already (though it's the physics delta, not the frame delta).

In general, though, since you're moving objects with collision checks, you should probably move the movement/rotation code to the _physics_process(delta) function instead. This function still has a delta argument, but it's always a fixed value (defined in the project settings, usually 1/60). This function is equivalent to Unity's FixedUpdate() function.

(+1)

I see, I see! So that's why there's both _process and _fixed_process! I learned something new today, thank you!