Skip to main content

Browse GamesGame JamsUpload GameWinter Sale 2025Developer LogsCommunity
On Sale: GamesAssetsToolsTabletopComics
Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines
Alex's Account143 days ago

Yeah, I should have spent a little more time tweaking the controls. Or just had someone play-test it during the jam to show me it was a problem worth spending time on (It's my first jam, so, live and learn). I already implemented 2 of your suggestions for a post-jam upload. I may do the last one just to learn text boxes and how validating input works in godot.

I have no idea how to fix the non-determinism. I stripped down the code to bare bones and couldn't find where it was coming from. It just pulls to the right; which is noticeable in a game that relies on a bit of precision. I may try reproducing it on a blank project to see if it's me or the physics engine.

Thanks for playing my game, I appreciate the feedback

Reply
KoalaPanda143 days ago

If it's your first jam, then it is completely understandable. My first games were much worse than yours too xD. As for the non determinism, I suggest looking up solvers and/or integrals. Euler's method/Runge Kutta for example. Or if you integrated by a simple pos += vel * deltaTime, it is actually wrong integration (well, very accurate for the usual stuff, not so great for simulation). Integrating by half of the previous delta and half of the current delta will yield better results. But... the determinism only affects differences between runs, not the pulling to the right problem, sadly can't point you into a direction for that one except I guess debugging the code lol.

Reply
Alex's Account143 days ago

oh geeze, I found the bug that pulls it to the right.

The rocket physics is pretty basic. I don't do anything hand-rolled. Its just a rigidbody physics object that I apply some force to and let the physics engine handle the rest. But, I also applied a constant force to it so the player doesn't slow down too much for the longer levels. The problem is, I forgot to rotate that constant force in the direction of travel. It doesn't fix the determinism, but its still something.

Awesome! Thanks for your help!

Reply
someotherguy143 days ago

Just commenting as a sanity check: Is all your simulation logic done during _physics_process? If any part is in _process, maybe the non-determinism is due to minor timing changes since _process has no guarantees that it runs on a consistent time step.

Reply
Alex's Account141 days ago

The actual physics processing is done in _integrate_forces, but I set the flags to turn thrust on/off outside of that. I think this is where the discrepancy in the time-step is causing me problems.

I switched from 'add_constant_central_force()' to 'apply_central_impulse()' and it appears to have fixed it, but now I need to figure out how to integrate the "burn duration" slider back in. (it was just an await() to reset the constant force, but I didn't want to move that into _integrate_forces())

Looks like I have some refactoring to do now.

Thanks for your help!

Reply
someotherguy141 days ago

You're awaiting a scene tree timer https://docs.godotengine.org/en/stable/classes/class_scenetree.html#class-scenet... ? If so, having the timer run with process_in_physics set to true should be enough then. Since the physics ticks are on a fixed time step.

Reply
Alex's Account140 days ago

Yup, that fixed it. Saved me having to rework the sliders. Thanks.

Reply
AboutFAQBlogContact us
Copyright © 2025 itch corp · Directory · Terms · Privacy · Cookies