Firebase makes a persistent websocket between the client and server. This decreases latency and lower the number of bytes transferred compared to HTTP. One concurrent user = one websocket. A connection is made when the API is loaded, which is before authentication (you don't need your users to login to use Firebase, its an optional service which is useful for securing your data, but its not necessary). There is a goOffline()/goOnline() for pulling the connection down before the application closes. So the CCU limit is how many people can have your application open *at exactly the same time* generally (each user can make many subscriptions, CCU != subscriptions).

pricing for Firebase just got reduced https://www.firebase.com/blog/2015-08-19-announcing-lower-simpler-pricing.html

A self hosted Mongo is not really the same as Firebase, even with Meteor attached.

Firebase has:

• inbuilt lag compensation so local writes look fresh.
• concurrency synchronization so that writes at the same time get sorted out properly, without db corruption.
• offline support so the app keeps working even when you are playing in a tunnel
• a rich rule language so you can enforce your game constraints.
• authentication with 3rd party providers like Facebook
• static secure *SSL* file hosting
• support for native and server platforms as well as web
• fallback from websockets in case the device is old or the firewall is fussy
• backups
• support
• + a team of people keeping the service running 24/7 and keeping the system up-to date

You can use the SSL and auth for free. The real time database is free for under 50 simultaneous users. That's a lot of users per month as people are not usually online at the same time. If you value your time, you will realize you would spend many, many full time months of labour developing a similar feature set. And it would still take yet more time (in production) to tune it and patch it, to make it reliable for all the internet's random configurations. And all these things are not important, *its the game that is important*, the networking and storage is a distraction, an unwanted time sink.

Bit late to the party but I wrote a basic game to test whether using firebase for twitch games was possible

https://construct2example.firebaseapp.c ... part1.html

Set the remote time with clock adjust, and a forgetting factor k = 0.5 to get the best results IMHO. Judge for yourself! mouse and cursor keys and left click

Each window is a different connection to firebase servers, so you can use this to get a feel for the performance on different devices. In the US and on a browser I think the bullets are well synced, but on a mobile it gets more bursty (that's a dropped packet causing a backlog in the TCP ordering guarantees). Though very few games on mobiles have solved the real-time multiplayer problem, the best real-time games for multiplayer insist on a peer-to-peer arrangement on a common wifi access point. Doing real-time multiplayer on mobile devices is hard because of the crappyness of the underlying cell data delivery mechanism, its not all about WebRTC vs TCP vs UDP vs Websockets

Awesome stuff.

I wrote the original Firebase plugin. I am pleased Rex is developing something with all the newer firebase technology, as I don't have time to upgrade the one I stated.

Hi, sorry about delay. I don't have a windows computer anymore

armaldio

One of the motivations of me putting everything on github is that someone can add missing features fairly easily via a pull request. I don't have a developer setup at the moment to add the feature myself, sorry.

rexrainbow

Dunno. I don't know what cocoonJS does under the hood. Maybe its a websocket issue, although Firebase should fall back to long polling if that were the case. You can "Firebase.enableLogging(true);" in JS which might explain what the issue is.

I am writing a series of posts on multiplayer latency compensation. I have a draft of the article here, https://construct2example.firebaseapp.com/pages/blog/latency_part1.html. I'd appreciate any feedback so I can polish it up better, let me know if it's unclear or whether on not it simply doesn't work in your region. Can you can actually notice the different compensation strategies? or tell me if you think you have a better way of doing real time multiplayer (over webRTC, I can definitely now tell how TCP ordering actually affect gameplay).

Tom

I got asked about how you maintain live data connections to many opponents at the same time. What is the looping stratergy to iterate over multiple records and setup everything in construct 2? Here is the best solution I came up with:

place each JSON player record as a child of "/users/" in your Firebase e.g.

/users/fred/

/users/john/

Create a container object in construct two that associates all the separate graphical elements together (like the label that displays the name). Mine is ui_card, and ui_name, ui_status etc. This example was for a lobby, hence the construct 2 GUI elements were fairly boring sounding objects.

We will use RexRainbow's HashTable (https://www.scirra.com/forum/viewtopic.php?t=65765&start=0) to parse JSON objects coming back from Firebase.

Now to keep all players game objects synced we maintain a list of player data by:

1. register a *child_added* callback to Firebase ref("/users"). This will get called every time a new record is available (including for initialization)

2. create the child_added callback.

2a Create the construct 2 container and register its UID into a player_list dictionary (handy for name lookups later).

2b register a *value* callback on the specific player's record

3. create the callback for when the value of a specific player's record changes. When a networked player's data changes you can load the new data into your graphical representation so it affects the game world immediately.

So in the wrapper, I have not exposed the auth token of the facebook user, but its in there. There is a login object that has all the details like id, as well as the authentication specific stuff. You would have to add a function to the plugin to retrieve the facebook auth token.

I am not an expert on how Facebook works. The link above seems to suggest this token has some limitations but I don't understand what those are.

I love Firebase, its considerably faster than any self hosted solution, and does clever client side caching. You only have to pay once your app becomes popular, so I think its a really good deal that you get to play with it first. I have developed with Google App Engine too and it is SLOW!!! (and also you have to pay once usage increases). So if you know of any other solution I would love to hear.

sorry to miss this. I am busy developing the server side technology extensively to build anti-cheating transactions (here)

I think your question is answered here

and kinda here

I think you need to work out a client solution of generating a key for the device and putting that in the user credentials. But that will be up to the technology platform you serve the game from to work out. Firebase will be no help at all, as it does not even collect meta-data like IP.

Tom

Glad you had it working for a while!

Looks like you are trying to get a value before a callback has fired.

You can't use the expressions ValJSON, ValString etc. until inside a "Firebase callback" or "Firebase once callback"

If that doesn't help send me your capx to tom dot larkworthy at gmail dot com.

Instead of just

"on touched object"

do

"on touched object

Has touch 0"

(or any other Touch trigger for that matter)