Opher Vishnia

Thanks for the PR! This is planned as a server feature, rather than a client feature. (Delay on sends rather than on receives). I don't know that I'd want to...

Definitely in the roadmap for the future. The major issue with scaling is actually the communication part. Currently Incheon handles client communication via websockets (and in next releases - WebRTC),...

The real question is how much latency does Redis add as a bounce between the client and the game server, and also there's the huge matter of how to to...

@SkyzohKey The thing is the main use case would be for different servers to handle different sections of the world, not run the the same instance of the game server...

@SkyzohKey that architecture wouldn't work. To elaborate on @dougmoscrop's point - Imagine you have a physics engine in your game. That engine needs synchronous read/write access to the world data...

Good catch! Thanks I added a fix and will close the issue once this gets merged to master in the next version

Actually it's very relevant for all games. It's because the JS gets halted/throttled down once a tab is inactive... I wonder what can be done about it. Maybe detect an...

Hi @tomknappramos ! Lance founding and core member here. Happy to answer you questions :) I gave a talk about this once in a conference, their audio is not great...

In a way it's already a singleton, just not very explicit. I don't have an issue with it being a singleton to clean up the API a bit on both...

@MaZZly The problem is that there are no good node-server based implementation for WebRTC, especially ones that implement unreliable data channels properly. WebRTC in itself was designed to work peer-to-peer...