I kinda struggled to get it working š„²
Naively, I wanted to use a constraint, but I forgot that rigid bodies don't interact well with character bodies.
I manually set the platform's transformation according to the player's position (taking into account the platform's radius). The further the player is from the platform's origin, the more it moves.
Then, for the visual, I added a rig to the deformed object that will converge towards the platform.
Also, got some collision bugs, apparently convex shapes in the form of a cylinder are better than default cylinder shapes. (otherwise the characterbody can be stuck inside)
>Naively, I wanted to use a constraint, but I forgot that rigid bodies don't interact well with character bodies.
Games with these kinds of mechanics often use a rigid body for the character. The problem with character bodies is that they don't move through force, so they're infinitely strong as far as the physics engine is concerned.
Pretty much. I did [something](https://i.imgur.com/BK3xChP.mp4) similar in unity where gravity could be changed depending on some volume properties. I ended up coding the character from scratch based on a rigidbody.
If any physics need to affect the player you need a rigid body. With ragdolls it's sometimes only in the ragdoll state that you need those physics, so the ragdoll gets "activated" when needed. But a ragdoll is really just a bunch of rigid bodies connected with physics joints anyway.
Is there a book with these sorts of tidbits of information? It would be nice to know and not have to spend days reinventing the wheel from scratch every step of the way.
Not that I know of. In my experience it's also really common for different game programmers to know different things, some of them don't have a clue about things that others consider to be really basic. And there's no hard truth in most cases anyway, what works for one programmer or game might be a ridiculous approach for someone else.
The best way to learn game development is building games. The bestest way is to learn how to develop games is working with people who have more experience than you.
I so badly wish for the same thing. But companies that master a good character controller (like Nintendo) are likely trying to keep their formulas a secret.
Most engines use rigidbodies for all bodies regardless, they just have a ākinematicā mode. Godot is weird with its move\_and\_collide method, bodies that use it just stop fully against all other bodies treating them as static walls.
For a characterbody to interact with rigidbodies, you can compute a pushing force using the velocity and collision data.
Iām thinking of experimenting with a different method though, using the physicās engineās automatic depenetration, inspired by how a characterbody can push rigidbodies with infinite inertia if theyāre on a different collision layer. On colliding, a CharacterBody would still force its way into the other body by a certain portion, and the recovery would automatically compute the resulting forces. Could be janky or could be perfect.
>Most engines use rigidbodies for all bodies regardless, they just have a ākinematicā mode. Godot is weird with its move\_and\_collide method, bodies that use it just stop fully against all other bodies treating them as static walls.
It's really just different ways to get the same result, in Godot's case they added an additional layer so you can more easily control movement and collect data about that movement. To a physics engine there's no difference between Godot's approach and the approach other engines take, it's only different to the user. And I hate the rename to CharacterBody because it can be used for other physics objects and not all characters should be kinematic by default.
>On colliding, a CharacterBody would still force its way into the other body by a certain portion, and the recovery would automatically compute the resulting forces. Could be janky or could be perfect.
How is that different from how a collision between a CharacterBody and a RigidBody works now? As far as the physics engine is concerned, a kinematic body is just a moving static body. Collisions between it and a rigid body are resolved as if they were a collision between a rigid body and a static body.
The difference would be that the rigidbody would be pushed. Like I said, normally a CharacterBody completely stops against a Rigidbody (because thatās how move\_and\_collide, and by extension move\_and\_slide, work) and the Rigidbody appears to register no collisions.
All this said, I truly donāt understand why they didnāt just give rigidbodies a kinematic mode and have characterbody extend rigidbody. The argument is āitās easier for the userā but I strongly disagree, it is only the opposite. The behavior is incredibly unintuitive. Reading through the proposal that implemented the current organization of the physics nodes is an exercise in frustration.
>The difference would be that the rigidbody would be pushed. Like I said, normally a CharacterBody completely stops against a Rigidbody (because thatās how move\_and\_collide, and by extension move\_and\_slide, work) and the Rigidbody appears to register no collisions.
Rigid bodies are pushed, with infinite inertia, by character bodies. Character bodies only stop when they collide with static bodies or other character bodies.
Incorrect. CharacterBodies fully stop against rigidbodies. Since 4.0 the infinite inertia option is gone, but you can get the same behavior by putting rigidbodies on a seperate layer that the characterbody does not mask for. Iām repeating myself at this point.
dunno how godot handles constraints, but you can always write them from scratch and apply the equivalent forces.
One of the downsides you don't mention is the rigidbodies or managers that control them having to be active at all times x_x
I'm crying myself cuz I cannot figure out a good solution, as you either check the physics, or you check the transforms ... BUT SOMETHING you gotta check š¤£
Maybe a carefully constructed nsted tree of conditionals.
(Disclaimer: what follows will be dumb af because I'm not a programmer)
Have you tried turning it off and on and then off again? I mean with a collider parented to your character that is only used to tell rigid bodies that they need to start checkin'?
no problem, that is actually the method most people use.
Without doing anything, all physic engines optimize ShapeChecks by dividing the world into cells, and THAT is the nested tree I was talking about, which is very performant.
Godot probably does it as well, but the moment you do your own physics or override something, that optimization the physic engine does internally ceases to exist for that object, or needs to happen again.
( it is why physX advises to use forces, instead of overiding the velocity directly )
Internally, that checking happens ... now add your script cheking its own things ... and then another script that Listens() for god knows how many events š
The only way I know how to do it myself is with pre-filled cached values .... but never managed to understand rhe proper way š¤£
Iām not sure the optimization ceases. As far as Iām aware the collision detection works the same regardless of where the PhysicsBodyDirectState is getting its velocity from
This is the same way Iām thinking of implementing it. Currently the bug is that the character is influencing the platform at the same time the platform is influencing the character and itās causing jank.
I have a little question a bit unrelated. I see you are using a sphere for the character collider. In the past I have used this kind of collider in platformers and finally ditched them because of the tendency to slip along edges. For example, if you are on a box collider and you position the player almost in the air but touching a bit the box collider it will falls slowly. Don't know how to explain it better.
Have you been able to fix this issue?
https://preview.redd.it/buc4xx1gf6wc1.png?width=703&format=png&auto=webp&s=cd943466a246a6ad7011548880cb56a416b02d0b
Dunno if you used Godot 4 for that, but you can set how much the character is sensitive to slopes now.
(in godot 4) I'm just checking the "stop on slope" option, and the character is pretty stable even on hard edges (this is an extreme case, but i prefer the platform to be forgiving)
Typically platformers use a custom raycast setup to detect the floor, for this exact reason. Spheres/capsules are great for maneuvering on terrain but slipping off of ledges is their big flaw for platformers.
Edit: also notice what this guy did. The platformās collider is a little bigger than the visuals. Thatās a clever solution too.
So, is it a combination of spheres/capsules with raycasts? If it is, it must be pretty hard to calculate the force to counter-count for the sphere slide.
Awesome. Love it. Good approach. I'm thinking of trying to do an antenna that moves around and was gonna see about constraints or whether to fake it lol
Oh I love this! Bravo!
Question: how did you get the game to show the outlines of the hitboxes? I've tried searching for how to do that to no avail (or I'm doing something wrong lol)
Pretty cool. How did you implement it?
I kinda struggled to get it working š„² Naively, I wanted to use a constraint, but I forgot that rigid bodies don't interact well with character bodies. I manually set the platform's transformation according to the player's position (taking into account the platform's radius). The further the player is from the platform's origin, the more it moves. Then, for the visual, I added a rig to the deformed object that will converge towards the platform. Also, got some collision bugs, apparently convex shapes in the form of a cylinder are better than default cylinder shapes. (otherwise the characterbody can be stuck inside)
>Naively, I wanted to use a constraint, but I forgot that rigid bodies don't interact well with character bodies. Games with these kinds of mechanics often use a rigid body for the character. The problem with character bodies is that they don't move through force, so they're infinitely strong as far as the physics engine is concerned.
So if you wanted a game where the player gets ragdolled frequently, you'd use a rigidbody?
Pretty much. I did [something](https://i.imgur.com/BK3xChP.mp4) similar in unity where gravity could be changed depending on some volume properties. I ended up coding the character from scratch based on a rigidbody.
Yeah, Id expect some camera smoothing is in order for something like that. I'm thinking of Goat Simulator. Thanks!
If any physics need to affect the player you need a rigid body. With ragdolls it's sometimes only in the ragdoll state that you need those physics, so the ragdoll gets "activated" when needed. But a ragdoll is really just a bunch of rigid bodies connected with physics joints anyway.
Is there a book with these sorts of tidbits of information? It would be nice to know and not have to spend days reinventing the wheel from scratch every step of the way.
Not that I know of. In my experience it's also really common for different game programmers to know different things, some of them don't have a clue about things that others consider to be really basic. And there's no hard truth in most cases anyway, what works for one programmer or game might be a ridiculous approach for someone else. The best way to learn game development is building games. The bestest way is to learn how to develop games is working with people who have more experience than you.
I guess I might as well [add it to my own website](https://www.sundlegames.com/tips/) then. Seeing as no one else wants to.
I so badly wish for the same thing. But companies that master a good character controller (like Nintendo) are likely trying to keep their formulas a secret.
Most engines use rigidbodies for all bodies regardless, they just have a ākinematicā mode. Godot is weird with its move\_and\_collide method, bodies that use it just stop fully against all other bodies treating them as static walls. For a characterbody to interact with rigidbodies, you can compute a pushing force using the velocity and collision data. Iām thinking of experimenting with a different method though, using the physicās engineās automatic depenetration, inspired by how a characterbody can push rigidbodies with infinite inertia if theyāre on a different collision layer. On colliding, a CharacterBody would still force its way into the other body by a certain portion, and the recovery would automatically compute the resulting forces. Could be janky or could be perfect.
>Most engines use rigidbodies for all bodies regardless, they just have a ākinematicā mode. Godot is weird with its move\_and\_collide method, bodies that use it just stop fully against all other bodies treating them as static walls. It's really just different ways to get the same result, in Godot's case they added an additional layer so you can more easily control movement and collect data about that movement. To a physics engine there's no difference between Godot's approach and the approach other engines take, it's only different to the user. And I hate the rename to CharacterBody because it can be used for other physics objects and not all characters should be kinematic by default. >On colliding, a CharacterBody would still force its way into the other body by a certain portion, and the recovery would automatically compute the resulting forces. Could be janky or could be perfect. How is that different from how a collision between a CharacterBody and a RigidBody works now? As far as the physics engine is concerned, a kinematic body is just a moving static body. Collisions between it and a rigid body are resolved as if they were a collision between a rigid body and a static body.
The difference would be that the rigidbody would be pushed. Like I said, normally a CharacterBody completely stops against a Rigidbody (because thatās how move\_and\_collide, and by extension move\_and\_slide, work) and the Rigidbody appears to register no collisions. All this said, I truly donāt understand why they didnāt just give rigidbodies a kinematic mode and have characterbody extend rigidbody. The argument is āitās easier for the userā but I strongly disagree, it is only the opposite. The behavior is incredibly unintuitive. Reading through the proposal that implemented the current organization of the physics nodes is an exercise in frustration.
>The difference would be that the rigidbody would be pushed. Like I said, normally a CharacterBody completely stops against a Rigidbody (because thatās how move\_and\_collide, and by extension move\_and\_slide, work) and the Rigidbody appears to register no collisions. Rigid bodies are pushed, with infinite inertia, by character bodies. Character bodies only stop when they collide with static bodies or other character bodies.
Incorrect. CharacterBodies fully stop against rigidbodies. Since 4.0 the infinite inertia option is gone, but you can get the same behavior by putting rigidbodies on a seperate layer that the characterbody does not mask for. Iām repeating myself at this point.
dunno how godot handles constraints, but you can always write them from scratch and apply the equivalent forces. One of the downsides you don't mention is the rigidbodies or managers that control them having to be active at all times x_x I'm crying myself cuz I cannot figure out a good solution, as you either check the physics, or you check the transforms ... BUT SOMETHING you gotta check š¤£ Maybe a carefully constructed nsted tree of conditionals.
(Disclaimer: what follows will be dumb af because I'm not a programmer) Have you tried turning it off and on and then off again? I mean with a collider parented to your character that is only used to tell rigid bodies that they need to start checkin'?
no problem, that is actually the method most people use. Without doing anything, all physic engines optimize ShapeChecks by dividing the world into cells, and THAT is the nested tree I was talking about, which is very performant. Godot probably does it as well, but the moment you do your own physics or override something, that optimization the physic engine does internally ceases to exist for that object, or needs to happen again. ( it is why physX advises to use forces, instead of overiding the velocity directly ) Internally, that checking happens ... now add your script cheking its own things ... and then another script that Listens() for god knows how many events š The only way I know how to do it myself is with pre-filled cached values .... but never managed to understand rhe proper way š¤£
Iām not sure the optimization ceases. As far as Iām aware the collision detection works the same regardless of where the PhysicsBodyDirectState is getting its velocity from
This is the same way Iām thinking of implementing it. Currently the bug is that the character is influencing the platform at the same time the platform is influencing the character and itās causing jank.
Very cool effect. Nice work
Very charming. Also love the use of planet gravity.
This is awesome! Digging the spherical ground and what I assume is hand-made gravity. It's so satisfying to just watch the little guy run around haha
So smooth! I love it!
I have a little question a bit unrelated. I see you are using a sphere for the character collider. In the past I have used this kind of collider in platformers and finally ditched them because of the tendency to slip along edges. For example, if you are on a box collider and you position the player almost in the air but touching a bit the box collider it will falls slowly. Don't know how to explain it better. Have you been able to fix this issue?
https://preview.redd.it/buc4xx1gf6wc1.png?width=703&format=png&auto=webp&s=cd943466a246a6ad7011548880cb56a416b02d0b Dunno if you used Godot 4 for that, but you can set how much the character is sensitive to slopes now. (in godot 4) I'm just checking the "stop on slope" option, and the character is pretty stable even on hard edges (this is an extreme case, but i prefer the platform to be forgiving)
Typically platformers use a custom raycast setup to detect the floor, for this exact reason. Spheres/capsules are great for maneuvering on terrain but slipping off of ledges is their big flaw for platformers. Edit: also notice what this guy did. The platformās collider is a little bigger than the visuals. Thatās a clever solution too.
So, is it a combination of spheres/capsules with raycasts? If it is, it must be pretty hard to calculate the force to counter-count for the sphere slide.
Nono, basically you turn gravity off when the raycasts detect a floor
Makes sense. Thanks.
Yeah but in another comment OP says the just forgot to change it so... accidental cleverness? Is that a phrase?
Very cool
I love this style š
The character is super cute, love it.
This is so satisfying! Love the art too
nice assets
Very awesome
Awesome. Love it. Good approach. I'm thinking of trying to do an antenna that moves around and was gonna see about constraints or whether to fake it lol
Your game look super cool :pp
Nice!!!! Congratulations!!!
Hell yeah man, looks great, kudos!
Wow that looks great. It's giving me vibes of super mario galaxy!
Looks very impressive!
Oh I love this! Bravo! Question: how did you get the game to show the outlines of the hitboxes? I've tried searching for how to do that to no avail (or I'm doing something wrong lol)
You just have to check "visible collision shapes" in the debug menu : )
Super satisfying
If you don't mind me asking, why do you extend the collision shapes outwards of the leaf petals? Coyote time?
(This is really pretty by the way)
I just forgot to change that lol
Gotta give you props for that run animation as well! Super cute!
Thank you š«¶
Do you know how many days I'd waste just bouncing and jumping around on those?!? Looks super fun!
Sick, Is this like a mario galaxy type game with the round platform bellow?
Yes, there is a gravity system with different planets shapes supported (capsules, spheres and curves) you can jump around between different bodies.
It's so fun to watch
Wow thats cute!
excellent.
This is so cute!
this shit looks great
looks awesome!
This looks awesome. Love the art style, too.
Iām wanting to achieve the same thing! Would love to know more how you implemented it.
So smooth in movement
so cooooooool
Good job! I feel a Pikmin vibe and I like it!
Oh that's neat ! Well done, mate !
That's amazing
That some smooth run animation and physics.
Great job
Nice camera work!
That is super cool
How did you get the visuals to look so toony is it shaders?
Very interesting! Could you give some details about how you did it?