Thank you @Wondersye for you thoughts:
-
If we write a transport for Mirror, then erlang server will be a relay server. Like you pointed - huge chunk of work. For some of the network protocols like kcp, litenet, etc - there are no libraries which are well maintained. One has to stick to tcp for good quality libraries.
-
If server side libraries are different from Unity libraries for physics and collision - there might be a chance of different results between client and server.
-
NIFs have their own problems (particularly if they are complex third party libraries).
-
Game environments (say the objects, obstacles, trees, etc) should be same in both Client(unity) and Server(erlang) for consistency. If there is a way to import scene data into erlang for object positions, etc it would be ideal. I don’t know if anyone does this using erlang.
-
A game server need not achieve huge concurrency levels like application servers. Horizontal scaling is good enough. Containers have simplified this problem. New servers will be spawned based on demand. Only players who are playing together need to connect to the same server. Playfab, Google Agones, Unity Multiplay and AWS offer game server hosting service which auto scale based on player demand.
A lot effort is needed to build game servers in erlang which are not relay servers. This needs exponential resources and time when compared to writing a performant application server.
I would not use erlang for anything other than relay server or casual turn based games. One can go live say within 3-4 months using Mirror or other libraries - same cannot be guaranteed using erlang(speaking for developer like me).
I feel Rust is better placed when it comes to building game servers compared to erlang. There are many game frameworks being developed in Rust like bevy, etc. Rust libraries like tokio + bevy, etc are promising (i have not built one yet).