Creating an online game with queuing mechanism

Hello fellow experts,

I am new to meteor and would like to create an online game with “queuing mechanism”, how it should work is as following:

  • Player 1 joins the game and click the ‘Play’ button
  • Server detects that the game has no one playing so instructs Player 1 to start the game (game play last for 100 seconds)
  • Player 2 joins the game and click the ‘Play’ button while Player 1 is playing the game
  • Server detects that the Player 1 is still playing and then put Player 2 in queue
  • When Player 1 finish his game, Server will instruct Player 2 to start the game, so on and so forth…

Appreciate if someone can shed some light as i am totally lost… Thank you…

Can’t speak for everyone here, but you are outlining a semi-complex flow that would be pretty difficult to write out in a forum post. You could have something as simple as a currentGame collection, with a single document:

{
  currentlyPlaying: true,
  timeStarted: unixTimestamp
}

And also a playerQueue collection, with a document that is added whenever a player queues up:

{
  playerId: someId,
  playerQueueTime: unixTimestamp
}

When someone joins, look at this doc, and if currentlyPlaying is false, start the game, and set currentlyPlaying to true, along with the timestamp. If ‘currentlyPlaying’ is true, add the player to the playerQueue collection. When the game is over, set currentlyPlaying to false, and look at the next doc in the playerQueue collection, sorted by the playerQueueTime field.

Or something similar, ha! This is just a two minute high-level take on this. I’d suggest http://guide.meteor.com to get started!

You might want to use cursor.observe on the server to help you with this:
http://docs.meteor.com/#/full/observe

Having written a game in Meteor that also uses timers this seems to be the key Meteor feature to make use of here. What you do is observe games that are being played, and when a document then changes from PLAYING to FINISHED, you start the second game.

An added benefit of this approach is that you can run this entire observing process on a separate server in the future if you have to scale up to multiple servers. (Other approaches to this problem might make it harder to scale to multiple servers. But I wouldn’t worry too much about scaling right now.)