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:
Live players indicate on my Firebase store that they'd like to play
using a state variable
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?)
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??
Queue workers pick up a task and make 1000 matches and write these
match details in the players node in firebase
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.
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
Asked in February 2016Viewed 1,172 timesVoted 13Answered 1 times