使用Firebase的Facebook Instant Games 1v1多人游戏(第1部分)

由于Facebook Instant Games是一个相对较新的平台,因此许多部分丢失或根本无法按人们期望的方式工作。

因此,为了启动具有多人游戏(1v1)支持的游戏,我们必须实施自己的解决方案,我们选择Firebase是因为它们具有新的技术Functions ,该Functions允许后端逻辑上载并在其服务器上运行,并且因为其平台和解决方案如果我们需要它们(可以以相对较低的价格)进行扩展,则可以扩展。

请注意,以下后端代码是由前端开发人员编写的,因此事情可能并不是超级理想的,但是嘿,它确实可以工作……

本文还假定您知道如何设置Firebase项目和简单的游戏,并且主要关注多人游戏部分。

因此,让我们开始并初始化我们的Facebook Instant Game SDK

  var facebookStuff = { 
名称: ””,
图片:“”,
contextId:“”,
用户身份: ””
}; FBInstant.initializeAsync()。then(function(){
FBInstant.setLoadingProgress(0);
FBInstant.startGameAsync()。then(function(){

facebookStuff.name = FBInstant.player.getName();
facebookStuff.picture = FBInstant.player.getPhoto();
facebookStuff.userId = FBInstant.player.getID();
facebookStuff.contextId = FBInstant.context.getID();
}

现在我们一切顺利,我们已经从Facebook接收了necesarry userId来标识我们的用户。

因此,让我们创建对服务器进行API调用的函数。

通过使用getSignedPlayerInfoAsync我们请求一个安全令牌,该令牌将发送到我们的服务器,并使用即时游戏平台将用户标识为合法的Facebook用户。

在此处阅读更多信息:https://developers.facebook.com/docs/games/instant-games/sdk/fbinstant6.2

然后,API调用将所需的数据发送到服务器,以便将我们的特定userId存储在实际上是我们的多人队列的专用DB文档中(使用Firebase Firestore DB)。

播放器成功注册后, findMatch函数将被称为回调,该函数将执行以下操作:

再次,我们发送服务器的签名以验证我们的身份,并再次发起API调用以实际开始搜索对手,我们将这两种操作分开,以在负载平衡,分析(为加入队列与实际播放的队列)。 以及给用户更多时间取消他们想要的搜索。 将来,这两个功能可以合并。

因此,一旦findMatch回调成功解析后,服务器就会主动为我们寻找匹配项。 我们如何接收已找到匹配项的信息? 很简单,我们在特定集合FirebaseAPI.db.collection("multiplayerQueue").doc(facebookStuff.userId).onSnapshot()下的特定文档上添加事件侦听器

看起来像这样:

因此,这是在数据库上的特定集合和特定文档上侦听更改。

请参阅:https://firebase.google.com/docs/firestore/query-data/listen

因此,当服务器实际找到匹配项时,它会使用我们的userId在数据库上的文档上写入一些数据,当然,对于我们的对手也是如此,因此每个数据都会在上面的函数中收到一个事件。

接收到事件后,我们现在只需要实际连接到我们的对手,在具有我们的userId的数据库文档上,还有我们的对手userId ,我们将通过Facebook API使用它来连接到他们(Facebook确认窗口会弹出好,这是我们无法控制的)。

注意,一旦接收到事件并触发了回调函数,我们将关闭并断开事件监听器的连接(我们不再需要任何其他事件)。 如果我们再次执行findMatch过程,将建立一个新的事件侦听器。

让我们看一下与玩家部分的连接:

当问题解决并且用户接受弹出窗口时,两个玩家将连接并插入到Messenger线程中,并为其游戏会话接收matchId

另外,我们还可以接收所连接玩家的信息(前提是他们也同意在弹出窗口中与我们一起玩游戏)

上面的函数从该上下文(信使线程)接收所有玩家,这基本上是我们自己和对手,我们通过userId筛选出自己,并加载对手的个人资料图像和数据。 然后,我们可以使用它们,但是我们喜欢在游戏中使用它们。

请继续关注第2部分,这是这些API调用背后的后端逻辑。

请享用!