In this usecase you need server side physics instead of navmesh.
Still we need the mesh, with which we can create a CollisonShape on server side. Add both player and the mesh’s collision shapes to bulletPhysics engine, then waiting for user input.
When user pressed WASD key, calculate the right ‘walking direction’ and send it to server.
On server side you can set player’s walking direction, then let bulletPhysics do the left stuff. Send player’s physical location to client per frame/tick.
On the client side, we update the player’s visiul parts with when received data from server.
I believe that there must be an example in sim-eth-es. It use bulletAppState as a System, processing Direction component and update Position component. But I cant find the link by now.
I made one in my own study project. I use zay-es in this game. InputState handles the WASD keys, CollisionState do the physics.
As I know, in real online game there should be physics engine on both clients and server. Client use physics engine to make player’s movement smother, the data received from server it used for validation. If the position on client side it not equal to the position on server side, player will “blink” to the server side position. It happens a lot when the latency is too high.
On server side, the terrain mesh is usually cut into small pieces. So the player’s collision shape can only do the math work with nearby meshes, that will make multiplayer online game server runs a little faster.
Someone talks about this problem before us