2D Physics vs. My Own Functions

BinaryOrange

I am wondering about using the built-in 2D physics in Godot for use in my platformer. Sure, it may be easier, but in my past experience when making a platformer you generally don't want to use built-in physics, as it can cause some issues. I have done some tests, and I think I can make my own functions to handle collisions and gravity/player movement, but I'm wondering if anyone else has an opinion on this matter. For example, have you used one method over the other? Which do you prefer and recommend? One other reason I may want to avoid the built-in physics is because of apparent jitter that seems to happen inside of Godot. However, I also noticed some slight jitter when using my own code to handle gravity:

extends Sprite # expose gravity var to change in editor export var gravity = 9.8 func ready(): &nbsp; set_process(true) &nbsp; func process(delta): &nbsp; # Add gravity to y position &nbsp; var pos = self.get_pos() &nbsp; pos.y += gravity &nbsp; &nbsp; # set the position &nbsp; self.set_pos(pos)

It seems to happen most often when I multiply gravity by delta, like so: pos.y += gravity * delta I will do some other tests and see where I get, but in the meantime I would appreciate your opinion! G: EDIT: I was just about to move this but thanks to whoever did! Didn't realize I hadn't posted it in this section because I had the wrong tab open. I should be more careful with multi-tab browsing!

Megalomaniak

[quote author=BinaryOrange link=topic=15418.msg15810#msg15810 date=1460927812]It seems to happen most often when I multiply gravity by delta, like so:[b]pos.y += gravity * delta[/b][/quote]Seems to me like the jitter might be a 'bug' caused by something to-do with the delta then, and should perhaps be reported to the tracker so the physics system could be improved for everyone's sake, even if you do intend to build your own solver.

BinaryOrange

Well, now I'm not seeing the jitter as long as I maximize the window. Multiplying by delta seems to be the way to go in that case. I will give the actual physics engine a try and see if I notice anything else about it.In the meantime, I am going to go for coding my own physics as I feel it will give me a little more control in the end, but again if anyone has any advice on what route to go I would appreciate it! :)

Megalomaniak

I wonder if this article might be of any help to you:http://gafferongames.com/game-physics/fix-your-timestep/Also, this:http://www.learn-cocos2d.com/2013/10/game-engine-multiply-delta-time-or-not/

UltimaN3rd

The jitter is caused my using[code]process(delta)[/code]which is asynchronous, which means it doesn't necessarily run every single frame - or it could run more than once per frame. What you want is[code]fixed_process(delta)[/code]which runs exactly once per frame. You'll also want to change your ready() function to[code]func ready():  set_fixed_process(true)[/code]

BinaryOrange

That does seem to help, but I still see some jitter occur, as though the game is lagging and the character will seem to jump to the new place instead of interpolate smoothly. I think I will use a combination of both - use the built in physics functions and customize some of them to get the results I need. Not that I need anything too special for my game, it's just going to be a really simple platformer!  G:

beelzy

I've read about the same issues as well. It's often preferable to roll your own physics functions, especially if your platform game gets to be complex and your characters will have a lot of real life physics defying abilities (usually stuff like climbing ladders, ledges, swinging, double jumps, etc.). I'm doing this in my game as well, which you've probably already seen. The other reason for that is animations. I think Jet Alpaca gets away with this because its animations are much simpler. When you have to distinguish when your character should play a falling animation when they're falling and an idle one when they're not, and when you want to implement something like slopes, it's pretty difficult if all you rely on is a built in physics engine. That said, it really depends on what you want; in the roll your own version, you have a limited set of slope grades you can use because of the way you have to set up those tiles, but it works more predictably with falling animations if you're using them. On the other hand, if you rely on the built in physics engine, you have more choices for slope grades, but it becomes a lot easier to implement when you don't have to worry about a falling animation.Since my game isn't Sonic like, and I'm fine with just a few grades of slopes, I went with roll your own. I did keep the simplest of static collisions to make use of the tilemap editor though. The only downside to that is that tiles that are exactly adjacent to your character count as a collision. Which means you can have a one tile gap below your character that your character won't fall through because the collisions on the tiles beside the gap are counted.If you do eventually plan to roll your own, I'd suggest this guide: http://higherorderfun.com/blog/2012/05/20/the-guide-to-implementing-2d-platformers/comment-page-1/It contains most of the common abstract implementations for character abilities and platformer features. It doesn't have one for implementing swinging, but the source code in my game has one. I ended up looking up some existing platform games which have implemented those to get a feel for how to do mine.

BinaryOrange

Thanks for the suggestions, beelzy!Already I have had some frustrations with the built-in physics, primarily when doing things with velocities. In order for things to work "right" I have to clamp velocities, and I think that only contributes to the aforementioned "jitter bug". However, even when I use my own code and have nothing to do with the physics functions, I still see some signs of jitter, even when using [b]_fixed_process(delta):[/b]So the problem seems to be something to do with delta itself, and gets worse when you multiply values by delta in order to use "frame-independent movement". I will report it on the issues tracker so that it might get fixed. Others have said that it may get fixed when the driver support gets updated, and what's even stranger is that this seems to be an issue exclusive on Windows. Perhaps it is time to unbox my old iMac and use it for Godot!  8)

beelzy

Oh, so that's why I'm not noticing it. If it's a general problem with Godot, then I guess my implementation won't change that. However, I've never actually used the delta value with fixed process for anything. Maybe my implementation is too primitive, or the features don't require it.It is generally preferable to use integers when you get the final values for stuff so that the collisions work cleanly. But that's only if you are implementing a tile based (smooth) platformer.