 |
Attention | Topic was automatically imported from the old Question2Answer platform. |
 |
Asked By | Kyle Guarco |
I mean, StaticBodies and KinematicBodies exist, so why the redundancy?
|
Reply From: | Zylann |
Because it’s a PITA to have to disrupt your entire node hierarchy just to change the operating mode of the root in game. It is common for rigidbodies to be switched mode, i.e if you pause a subset of the game, enter a special game state like “spawn countdown”, make an “edit mode / simulate mode”, or switch to God mode etc. RigidBody is a full-featured node. StaticBody and KinematicBody are rather shortcuts to a simplified API if you know they won’t change mode.
Is it a good idea to have every single entity in your game derive from a RigidBody2D? The idea I have for a game requires a hierarchy, where every interactable object is derived from a parent Entity class.
Kyle Guarco | 2019-08-22 13:21
Maybe? I wouldn’t do that for clarity tho, but depends if it suits the game. Also, careful about going the “everything inherits common class”-way, to my knowledge it doesn’t work well because it forces you to always use the same node type as base (simply due to OOP). It might work if you are sure you always have the same base forever, or with a component approach.
Zylann | 2019-08-22 18:49
Could you explain the “component approach?”
Kyle Guarco | 2019-08-22 21:21
Component approach means you add a simple Node as child and put your script on it. So instead of a long chain of inheritance for which the common base can’t be changed, you compose behavior instead so it can be added as child of any type of node. It has its drawbacks too though, just a different approach.
Zylann | 2019-08-22 21:24
Thank you very much for your time! I’ll take what you said into account when I structure my scenes.
Kyle Guarco | 2019-08-22 22:41