We know how collisions behave (in a basic way) in godot, when the collision figures approach more than the defined margin they will brake suddenly and, in case of transfer due to a calculation error, the bodies will be abruptly displaced outside the body However, I thought that for my project maybe it would be better if (speaking of the npc entities and players), instead of blocking each other so rigidly there would be a way for the entities to move smoothly as if a force field It would be treated, with a varying amount of force depending on the proximity to the center of mass of the objects to give the sense of an obstacle but at the same time offer the opportunity to have greater contact between said elements.
I repeat, if it were possible, I would prefer this to happen exclusively between NPC entities and players because it seems to me that to calculate the scenario, the basic behavior of collisions would be essential.
Does anyone have any suggestions or comments to better understand what this dilemma would represent?
flexible collisions?
I don't think the physics engine has a built-in feature to support that.
You could implement it by applying forces, or changing velocities, based the positions of the objects.
Depending on the type of objects, you can use collision shapes as proximity detectors that don't affect the physics, which would reduce the amount of manual proximity detection needed.
- Edited
DaveTheCoder I could try it, but I don't know if that method would be practical for performance
MX0C 2D or 3D?
You can do your own physics in godot, you don't have to use rigidbodies.
CharacterBodies have a method called move_and_collide, which returns the collisions of the body for you to create your own behaviour. I saw it used to create a unique jumping mechanic in an UP-like game.
Other nodes also have similar things with the RIDs and PhysicsServers, and you also have raycasts.
But you must know the math in order to create these behaviours, it can be very difficult, so read some book on physics or try and try until you get an math formula that does what you need.
Sorry for the delay, I had things to do, but I was doing a little research on the move_and_collide and test_move methods, but not enough so I decided to postpone these methods and make sure it works first with areas to have the principles of the behavior ready.
However, I have encountered several inconveniences, such as, for example, handling vector 2 in a mathematical operation that requires multiplication/division, if any of its values turns out to be a perfect 0, you will imagine that it does a strange behavior,
The second one that I fixed for the moment but I was a little dissatisfied is that instead of gaining more strength as I get closer to the object, it is the other way around that I leave you the modified code based on the basic_movement project from the documentation tutorial.
https://docs.godotengine.org/en/stable/tutorials/physics/using_character_body_2d.html
extends CharacterBody2D
var speed = 300
var last_vel : Vector2
func get_input():
var input_dir = Input.get_vector("ui_left", "ui_right", "ui_up", "ui_down")
velocity = input_dir * speed
return input_dir * speed
func _physics_process(_delta):
#move_and_collide(velocity * delta)
move_and_slide()
get_input()
func reject_body(BODY_POS:Vector2):
var vector_cero = Vector2(0,0)
if velocity != vector_cero:
last_vel = velocity
var dir : Vector2 = (BODY_POS - global_position)
var dis = dir * dir.normalized()
velocity = get_input() - dir.normalized() * (Vector2(100,100)/dis)
print((Vector2(100,100)/dis) )Remember to also add an area with this code
extends Area2D
# Called when the node enters the scene tree for the first time.
func _ready():
pass # Replace with function body.
# Called every frame. 'delta' is the elapsed time since the previous frame.
func _process(_delta):
for bodies in get_overlapping_bodies():
if bodies.has_method("reject_body"):
bodies.reject_body(global_position)