I have a gaming idea where players have an avatar/character with a screen-position that gets pushed to each client so everyone can see where each player is - think simple X and Y “chess-board” at this point.
In Meteor, how would I implement the player positions? The positions do not need to be persisted to the database. They’re just real-time ephemeral values, but they do need to be shared/sent/published to all clients.
Server variables might work and serving them via Meteor methods, but how would I design it so new “sets” of player positions could be instantiated for each new game in the app? JS doesn’t support dynamic arrays right? If they were a database collection, it seems pretty easy. But I really don’t want to pass these values through the database as they’re more “real-time movement” and not turn-based values - there’s no need and it seems like that would just slow things down. There will be no need to save/reload the positions of the players.
What @Steve says is true - but you don’t have to use server-backed storage (as in a real MongoDB database). You can “roll-your-own” publications using whatever cunning method is appropriate to your use case. So, use a method to update the server and a roll-your-own publication to send the update to all clients.
Check out the Meteor.publish docs, in particular the use of this.added, this.changed, this.removed and this.ready. For a basic use case look at this example I prepared earlier.
So everything will be stored on RAM instead of hard disk as using real MongoDB? And do the writing and reading data to/from MongoDB slow down our app much?
I have a gaming idea too and i really would like to know if what is the better way to store all gaming data, especially when it allows 20+ users in a game
Client-only collections are stored in browser main memory.
In a client-only collection this uses minimongo, which is a Javascript emulation of a subset of MongoDB commands. It is likely to be slower than a well designed custom solution, but is reasonably fast for small collections (there is no indexing).
You should prototype some of the functionality and benchmark performance.