Why move_and_slide of 200 units leads to heavy fps drop

Question

I'm making 2D isometric game.

I've got like 200 instances of unit, which is kinematicBody. When nothing is happening physics process is running 200 times.

When I take like 50 units and move everything seems to be ok, fps drops little but movement looks smooth. Later I noticed that even when movement looks smooth, _physics_process keeps jumping between 200 and 400 calls.

When I take like 100+ units and move, fps drops heavily (like 1 fps) and profiler shows _physics_process 1600 times.

I 've found out that main problem seems to be move_and_slide (I've stripped all other functions)

Why is this happening?

EDIT:

move_and_slide is not the issue, _physics_process without it behaves almost the same.

My movement starts with click on navigation polygon, which returns simple navigation path, then simplified process looks like this:

func _physics_process(delta):
 if state.navigationPath != null:
  if state.navigationPath.size() != 0:

    state.movementTarget = state.navigationPath[0]
    state.movementVelocity = global_position.direction_to(state.movementTarget) * properties.movementSpeed * delta

    if global_position.distance_to(state.movementTarget) > 5:
        global_position += state.movementVelocity

  else:
    state.navigationPath.remove(0)
    if state.navigationPath.size()==0:
        emit_signal("statusChanged","idle") 

Comments

This appears to me to be the amount of calls made within a fixed amount of time.

All the calculations necessary takes more time when called within nano seconds of each other.
To prove this is not just a physics based issues like calling move_and_slide try moving the unit yourself like adding to the transform's translation or using move_toward or lerp and you'll see the results are minutely greater but practically the same.

All of this said based on observations but since you know the practical limits you can create a cool reason for why this is so in your game

---

Hi, thank you very much for reaction.

As you said, result was the same, but I can't understand which calculation could take so much time.

What am I missing or done wrong? Thanks

-- I've edited question with new observations and code.

Answer 1

I figured it out. Main problem was in Area2D, I had to disable all unnecessary
CollisionShape2D/CollisionPolygon2D.

Luckily I can work with collision shapes on demand and don't need to have it on all the time.
I didn't realize that they consume too much resources, when too many units are close to each other.