Hello! 
I am working on first-person-shooter, an open source app using Meteor for the real-time communication, as well as LUME’s 3D HTML built on Solid.js templating and reactivity:
The first demo of first-person-shooter is up and running. Share the next link with someone to play multiplayer! However, expect the networking not to be so great at the moment, as I haven’t optimized it yet:
https://first-person-shooter.meteorapp.com/
It was my submission for SolidHack (a Solid.js hackathon). Go there and check out the awesome projects, and vote for your favorites in three categories!:
The Goal
I’d like to chat in this topic about how we might be able to use Meteor’s real-time full-stack-reactive networking in the most optimized way for the purpose of syncing game state as quickly as possible.
I thought that perhaps we want to sync game state to clients using a Meteor publication, but without it being tied to the database in the backend. That led me to these topics:
But thinking about it, I don’t think it matter to the client if the backend stores data in the database or not for the real-time game state that does not need to be persisted. Essentially it only needs to be a single object that gets updated over time. To the client, this would appear as a collection that always has a single item.
What I haven’t experimented with yet, is coming up with a binary TypedArray representation of game state, and sending the state as binary to the clients.
Right now, there are multiple objects in the backend players collection, one per player, and the game state is updated by updating each player, which means that the client receives multiple updates for multiple players, rather than one update at a time for a single game state object.
I think merging into a single object will be beneficial, even before converting to a binary format.
Another thing is EJSON: do the game messages always have to be in an EJSON wrapper? It seems that to avoid that, I would have to drop down to DDP, or maybe just to manual WebSockets.
But what I don’t want to lose is the automatic full-stack reactivity that Meteor is know for.
Without Meteor’s out-of-the-box full-stack reactivity, there’s no point in using Meteor, in my opinion. That’s what I’m here for in the first place.
So, maybe there are two main sub topics here on the full-stack system:
- how to make use of the current system as efficiently as possible for purposes of real-time games, and
- how may we be able to improve Meteor’s implementation to make it even more performant for this use case that is currently possible.
Another thing to explore is, would vertical scaling help? What about horizontal scaling?
Throttling updates is also something basic that probably needs to be employed regardless of any of the above. I linked to some ideas and methods for that here:
So let’s get the fun started 
What are your thoughts or ideas? Have you seen any Meteor apps solve similar problems? How did you overcome any networking bottlenecks you’ve encountered? Any existing code repos we can look at?
