Strategy for creating non-persistent server variables for game-player positions?

help
1

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.

2

AFAIK, In Meteor, the only built-in feature that allows server-to-client push communication is Collections.

3

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.

1 Like
4

What sort of cunning methods are there to do something like this? If I knew how to roll my own I wouldn’t be asking for help. :blush:

Is there anything in the Meteor docs to manually manage your own data broadcasting, etc?

5

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. :smile:

2 Likes
6

There’s always yuukan:streamy for if you don’t want to save something to the DB

1 Like
7

also worth looking at new Mongo.Collection( 'foo', {connection: null} );

This pattern, might give you some ideas… http://meteorpad.com/pad/FvP8K6MJZcizyo7u9/Shared

1 Like
8

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

9

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.

1 Like