Ожидающие запросы / задачи - отличная функция, особенно для многопользовательских игр, однако Facebook SDK не дает нам много инструментов для продолжения работы, в настоящее время единственный способ увидеть любые ожидающие задачи - через собственное меню Facebook при вызове chooseAsync

И здесь в игру вступает эта статья. Для этого мы используем простую функциональность, которая включает контекст match-id и противниковuser-facebook-id

Мы создадим две механики: одну для получения Any вызовов в любом контексте от кого угодно, а другую - для получения ожидающих вызовов для текущего контекста (это особенно полезно для игр, которые требуют выполнения последующих действий, и фактически наличие этой механики позволяет им чтобы игры были возможны)

Принесите все проблемы!

Итак, основная механика следующая:

  • Игрок совершает действие и звонит в серверную часть
  • Сервер (функции firebase) хранит объект в определенной коллекции (firebase firestore-db), а внутри документа, названного в честь текущего контекста (match-id), объект содержит match-id и ожидающую сторону (оппонента), которую игрок ждет.
  • Когда другой игрок этого контекста входит в игру, он получает ожидающие запросы и проверяет, содержит ли какой-либо из них их facebook-id в качестве ожидающей стороны. (Эту часть можно защитить еще больше, сделав API-вызов серверной части, предоставив facebook-signature для проверки вместе с их match-id и facebook-id)
  • Если какие-либо результаты найдены и возвращены, возможно, индикатор в игровом пользовательском интерфейсе (UI) обновляется с количеством найденных результатов (игрок может быть частью нескольких контекстов-потоков)

Покажи нам код!

Для начала нам нужно получить данные об игроках, которым бросили вызов (нашем оппоненте).

Итак, после того, как мы успешно запускаем функцию chooseAsync SDK и выбираем нашего противника, мы делаем следующее:

Приведенный выше код будет извлекать и сохранять подключенных игроков, но мы исключаем себя из результатов, поэтому в переменной challengedPlayer у нас есть только данные нашего оппонента (ов).

Чтобы продолжить, нам нужно отправить эту информацию на сервер (функции Firebase), чтобы сохранить ее (я подозреваю, что это можно сделать после или одновременно с отправкой нашего игрового действия на сервер, но реализация может отличаться от игры к игре)

Это функция на серверной части, которая сохраняет ожидающий запрос в Firestore-DB.

Теперь все, что нам нужно сделать, это проверить на стороне клиента, есть ли у нас ожидающий запрос, а затем выполнить некоторую работу с пользовательским интерфейсом и отобразить индикатор или что-то подобное.

Здесь мы делаем запрос к коллекции в базе данных (со стороны клиента, но может быть легко перемещен в бэкэнд). И мы просим получить все записи, которые содержат наш facebook-id в качестве ожидающей стороны (это означает, что другие люди ждут, когда мы сыграем). А затем просто верните эти записи в функцию обратного вызова.

Но я хочу получать обновления в реальном времени!

Да, да, я тебя тоже прикрыл.

Для тех из вас, кому требуются обновления ожидающих вызовов в реальном времени, все, что нам нужно сделать, это настроить прослушиватель событий, который отслеживает изменения в этой конкретной коллекции в базе данных, на конкретном match-id (идентификатор контекста для каждого потока). Это делается на стороне клиента.

Поэтому каждый раз, когда с этим match-id происходит изменение, мы извлекаем данные и проверяем, включен ли наш facebook-id в pending-party объект.

Если мы хотим отказаться от этого прослушивателя событий, все, что нам нужно сделать, это вызвать callbackFn(); (имя возвращаемой переменной вызова onSnapshot)

Мы добавили, а удалили?

Одним из очень важных аспектов этого механизма является возможность удалить незавершенное испытание, когда оба игрока сыграли свой ход. Это очень специфично для каждой игры, но я покажу вам код того, как удалить конкретную запись, когда ваша механика сочтет это целесообразным (когда оба игрока сыграли или когда произошло какое-то другое действие).

Поэтому, когда мы сочтем целесообразным удалить запись ожидающего запроса, все, что нам нужно сделать, это вызвать deletePendingChallenge и предоставить ему match-id, который мы хотим удалить.

Если обратный вызов завершается успешно, можно безопасно добавить еще одну запись с тем же match-id и перезапустить механизм.

Если вам случится использовать вышеупомянутую механику, напишите мне строку ниже, чтобы узнать, какую пользу она вам принесла. Или если у вас есть какие-то идеи / сообщения об ошибках / идеи.

Как всегда Наслаждайтесь!