@ViperV said:
Hi. New here and I hope I'm in the right section of the forum for this question.
So, so far, Godot is a treat to dev in and I got all the basics down and working.
However, in terms of performance and the way my game is designed in the first place, is it better of faster if I opt out of using physics and just go for process and basic math calculations?
Well, it depends. _process is called every time a frame is rendered to the screen. So, if your game runs at 60 FPS, then _process will be called 60 times. _physic_processis called a fixed amount of times per second, regardless of how many frames are rendered to the screen. I believe the default is 30 or 60, so for each second, it will be called that many times.
Say, instead of Area2D's to to detect collisions, a distance check or AABB collision would be better?
Since my game has also a flat floor with a fixed y coordinate, I'm also considering removing the static body floor and kinematics of the players/enemies.
I would suggest using Area2D nodes to detect collision. The reason behind this is that the C++ code for an Area2D will be faster than anything you could write in GDScript or C#, and the Area2D node will use the physics engine to detect overlaps when they happen.
Using a distance check or AABB collision requires running the conditions for every physics object every _process or _physics_process call. An Area2D can save performance since it knows (roughly) which other physics nodes are close, making it more performant.
The final reason is that the Area2D node already has everything you need written in it, not requiring you to write anything custom! It also supports collision layers, using the Godot editor to set collision shapes, and more.
Will going all _process give significant performance boost? Or how about a hybrid? Like a custom quadtree where if the process detects the math collisions, it starts doing physics process for more complex type of collisions?
No, using all _process or _physics_process is not going to give a significant performance boost one way or another. In theory, _physics_process is best for more complicated calculations because of its consistency that is separate from the FPS of the game, but in practice it doesn't matter too much (from my observations). I generally use _physics_process for most everything, with perhaps the exception of input that I calculate in _process, but that is mostly just personal preference.
The best way to get performant code is to break your code up into smaller functions, and only calculate what you need when you need it. If you have complex code, but it only needs to run once or twice, then writing the code so it can be isolated and ran only when needed will help performance.
