I am trying to develop my first Android app with the Google Realtime Multiplayer Gaming API. This will involve sending update messages to the peers as the game progresses. I would expect that down the line, as I make updates to my game in subsequent versions, some of the data may change and I would like to keep the messaging compatible between app versions. This is a common problem in other fields like networking and usually solved using solutions like TLVs or Google Protobufs. What is the recommended way to handle this in Android apps? Also, when a peer-to-peer connection is formed (when player joins room), do we have any way of knowing that app version the peer is using?
Thanks!
I also dont have a satisfing answer for this. Currently i wouldnt match versions that differ in that regard. To prevent that, it should be possible to use the variant bitmask in the autoMatchCriteria and reserve some bits to identify the version.
Related
I want to start developing a unity mobile game that will use Google Firestore as its database and ideally cloud functions for its "server architecture." I have experience with Firebase and Unity but what I am confused about is two things:
What exactly is Google's "Full Stack", like what should I be using on top of Firestore and maybe cloud functions (is this all I need to worry about, or is there more, working with AWS at work there seems to be a ton of things that need to be in place for a well working project)
What is the best way to integrate Firestore with a Unity Mobile game that spans across iOS and Android? Is there a tutorial to get started with a project like this?
Thanks a lot guys, and I would also appreciate any other tips on how I should approach making a unity mobile game that spans across iOS/Android. For instance what other technologies should I be looking to integrate?
I am guessing that "Full Stack" includes all of Firebase's other services: Authentication, Cloud Functions, ML Kit, Hosting, Cloud Storage, Realtime Database, and Firestore (https://firebase.google.com/products/).
Firestore is currently not available for Unity (https://groups.google.com/forum/#!topic/firebase-talk/dc8CuW7LDM4). You could write a bridge for it but that would be a lot of work and hard to test.
The Realtime Database may meet most of your needs though. It is the current version of what the Firestore is.
Update to this question:
Firestore SDK for Unity is currently in alpha (since 5th of march).
Link to the Github discussion.
In case it is changed here is the announcement:
As some of you have noticed, yesterday we released Firebase Unity SDK
6.12.0 which includes an alpha release of Firestore. This release is experimental:
We expect there will be breaking changes to the API Some features are
missing (for example: IN queries) You may uncover issues for which we
can't supply an immediate resolution Please try it out and let us know
how it goes. Read more about how to get this release in Add Firebase
to your Unity project.
We're very excited to (finally) get this in your hands and hear how it
works for you!
I love Firebase (/Firestore) and we use it all the time for major projects for clients.
But Firebase is "totally useless" for certain things...
Just forget about it for "multiplayer games with Unity."
Suggest you
Familiarize yourself with Playfab, do some small demos.
Don't forget that Unity itself offers multiplayer inherently built-in to Unity. (Indeed, it is of course a major part of Unity, it is a mammoth achievement.) Unity multiplayer is not perfect but you should certainly familiarize yourself with it totally, including the sundry cloud features, before exploring other paths.
Firebase is useless for Unity mp games, set it aside.
how I should approach making a unity mobile game that spans across iOS/Android
There are 100,000 ? such games which are done, naturally, just with Unity's own MP systems.
How else? As I say, once you are very familiar with that, also explore Playfab.
My question is literally a duplication of
Mobile strategy: How to handle this server-client version permutation?
but this question is fairly old and rather ignored. Maybe back in 2017 there are new results?
This is a problem with the different deployment behaviors of mobile apps and business applications: You don't typically have multiple versions of a mobile app in an appstore. Rather you have one app version. But .. what to do if you have to support multiple server version?
I'm also highly interested in research papers / hints.
I am planning to build a web application and android app, which will manage huge numbers of notification (push notification), and can work in slow internet connection too. I need to send and get instant notifications. Number of users can be thousands or millions, application will have multiple servers (web farm), multiple database. Now I need to decide that which database will be best for this kind of application and which language should I use for programming. Please help me out. Any suggestions will be appreciated
Well, first you need to decide what your immediate needs are. Are you going to use this on a platforms that could potentially have hundreds of people accessing information at the same time? Then you need to estimate your future needs.
This will help you to decide your database system.
As per my experience i am suggesting you to use MYSQL database.
I Blindly Suggest you to Use Parse Cloud Database,as it provides SDK for All mobile Environments like Android and IOS for easy implementation and also it recently Launched a Javascript SDK to use.Its free for Trial.MultiPlatform Support and Secure
Check it out Here: https://www.parse.com/
Are you sure you going to get to thousands and millions users ? Everyone starts from scratch (read: zero users, except some friends). By this I mean, that you have to concentrate on what's the real issue within your development (growing app user base is different story):
Creation of Android app and it's lifecycle (updates, support of previous versions & etc).
Back-end. Will I also work on Back-end. Working on 2 'projects' (Android app and it's back-end) isn't easy. Not everyone is experienced enough to work on multiple assignments at the same time.
Valuate an option of using SaaS/Paas backend. Most of the have trial or free version for developer.
Third option is great. Get cheap/free web host. Store there configuration, that your Android app will download when it starts. In configuration you should declare what's the back-end and how to communicate with it. You can use any of known services like https://www.firebase.com or https://parse.com/plans or even use Google App engine free tier / AWS free tier.
About developing app for Android - if your app doesn't need any complex calculation or libraries - just write it with JavaScript. It's fast enough. Though, Java apps are always faster and easier to debug.
Good luck !
Writing my first Android app here...
A part of the app is syncing messages across all devices with the app. A stream of sorts.
I was thinking of adding each message to an SQLite database and then syncing that over Google App Engine. Would that work? Is there a better way? I've heard of XMPP as well, but I'd prefer avoiding paying for a server until necessary.
take a look at Google iosched app for some android best practices on data sync via cloud.
you probably need to consider offline scenario too, as this is common in mobile devices.
another option is to consider third party services like https://parse.com/, or https://www.firebase.com/
I'm intending using Localytics (http://www.localytics.com) for an app which will be released on both iPhone and Android. My question is: Should I aim to use a separate app ID for the two platforms? I'd really like to just use one (so that all my analytics apply to both apps) but I notice that some things like "operating system version" just appear as a bit of a mess if I use the same ID for both.
There's nothing in their integration guide mentioning this - anyone have experience of this one way or the other?
I work on the Localytics SDK team and I'm happy to help.
While there is no technical reason you can't share a single key, we recommend keeping them separate. In addition to having a combined list of devices, operating systems, app versions, etc, your users likely behave differently on each platform. Using a single key will make it more difficult to see platform specific trends in your app usage.