Although I haven't gotten to that part of my game server, I've tried to design it to avoid any sort of physics, because of the potential latency between a client and the server. (I'm targeting mobile users.)
The only 'physics' that need to be calculated is when a player changes speed/direction, and you must calculate the path and detect collisions.
However, to minimize negative effects on gameplay, both the client and the server 'dead reckon' the position of players in their immediate view bubble.
In the client, this is done on a separate thread, on the server, a separate set of processes. Again, I don't expect my algorithms to be cpu heavy, but if they were I'd probably implement them in C and communicate with the erlang processes via message passing.
However, this may not be feasible if the latency is too much, in that case, C/C++ is probably more apt. However, you'd have to implement your own scaling, so I'd rather modify my game design than write the functionality that erlang already provides.
The only 'physics' that need to be calculated is when a player changes speed/direction, and you must calculate the path and detect collisions.
However, to minimize negative effects on gameplay, both the client and the server 'dead reckon' the position of players in their immediate view bubble.
In the client, this is done on a separate thread, on the server, a separate set of processes. Again, I don't expect my algorithms to be cpu heavy, but if they were I'd probably implement them in C and communicate with the erlang processes via message passing. However, this may not be feasible if the latency is too much, in that case, C/C++ is probably more apt. However, you'd have to implement your own scaling, so I'd rather modify my game design than write the functionality that erlang already provides.