There are so many “depends” what the game is.
Simple games such as chess shouldn’t be a problem, game session state consists of 64 elements in simplest implementation. There is no frames, and state is changed only on user interaction. The rest are functions that should guard legal/illegal moves and are called only when user interacts with backend.
But games such as Call Of Duty, that should handle N player is rather challenge. Here you need to think in frames, hence, you need to process all relevant data in “single pass”. This is not concurrency problem, it is rather parallelism problem when you have to execute game logic in single frame, in other words you have max 16.7ms to process state and respond to all clients.
I don’t say it is impossible, but it depends how demanding processing is. Erlang gives you process isolation out of the box, and that is fine for communication, but you will find challenging the part with parallel processing.
I do think that ECS can be implemented, where state is stored in ETS in form of components, then use pipeline (GenStage) processes to run game logic you need. For instance here is one frame:
- query player bullets, recalculate their new positions store in ETS
- query players and bullets, check if player entity is in collision with bullet… store player status and bullet status in ETS
- query survived players and move them in requested direction
Of course, you can filter or split entities in stage before the one that will execute above, then process each chunk in parallel. Good example is when some players are in one room while others are in other room. Then you can split processing in two parallel processes and handle each separately, since bullet can’t pass through room walls…
Of course, ECS is not the only game engine interanls, there are others that maybe be better fit for your case, but at the end, you will have to think how to slice data into smaller chunks so you can quickly process it.