nthacker February 2016

Creating match rooms with firebase

Im building a game where some k number of people can play, live

Im using firebase for sharing user-related data and obtaining updates from a backend nodeJS on heroku. So far so good, but I have one major requirement that I havent yet fully figured out to build using firebase and a NodeJS backend

There could be potentially a large number of users wanting a play a game. I'd like to match k of these users and assign them a unique gameroom id, where they can then 'play' . For the sake of this question we can omit what the actual 'play' is.

So I'd like to create a random set of k users and here is how Im thinking of approaching it, I'd like to know if this is a good approach or a terrible approach. I'd also like more suggestions if there is an easier way to achieve this:

  1. Live players indicate on my Firebase store that they'd like to play using a state variable
  2. A NodeJS backend on Heroku runs every few seconds to ensure that the system has a good 'mix' of players. When it runs, it uses the Firebase REST API to pull up all the waiting Live players (is this a good idea?)
  3. It then sections off these live players to a Firebase Queue. It does this by taking 1000*k live users and creating 1 task. Thus it may create many such tasks with 1000*k users in each task.

I'd like to add that if there was a way for a single queue worker to access multiple tasks then I would much prefer that. In that case Step 2 is pretty much not required, since the live players can add themselves to the queue and a single worker can access k of these users to match them together - is this possible with the current Firebase Queue??

  1. Queue workers pick up a task and make 1000 matches and write these match details in the players node in firebase
  2. Players wa

Answers


Jay February 2016

Let me preface this by saying this is a conceptual answer and doesn't directly involve Firebase queues. Those could be leveraged accordingly.

We don't know what the criteria is to create a good mix of players but let me give it a shot using a typical Warcraft dungeon group. That group will have 5 players; a tank (leader) a healer and three players that deal damage (dps)

In this example, it seems that the solution could be presented by observing the changes in each game_room node, and also watching the waiting_players node for changes as well.

Example structure:

game_room_0   
  current_players
       player_0
         type: tank
       player_1
         type: healer
       player_3
         type: dps
       player_4
         type: dps
       player_5
         type: dps

waiting_players
       player_6
         type: dps
       player_7
         type: healer

There would be x number of game_rooms, each needing 5 players.

The app observes the current_players node (in each game_room) for removed players.

It will also be observing the waiting_players node for added players

When a player leaves from a game_room/current_players node, player_0 for example, the tank (oh no!) your app will be notified of that change and can then query the waiting_players node for type = tank.

At that point it will have a list of the waiting tanks and could randomly select one or further narrow down the criteria for a better mix. Then add it to the game_room that needed a tank.

In this case, there are no tanks waiting, but the app is observing that node so when a new player is added to the waiting_players node (a player indicates that he wants to play), the app is notified of that added player, and if it's a tank, they can be placed into a game_room to replace the one that left.

This approach would avoid having to load in all the waiting players as the app will know which specific ones

Post Status

Asked in February 2016
Viewed 1,172 times
Voted 13
Answered 1 times

Search




Leave an answer