Search Unity

Feedback ChilliConnect vs PlayFab vs Gamesparks vs Firebase vs AWS vs Others

Discussion in 'Multiplayer' started by Kamyker, Jan 13, 2020.

  1. Kamyker

    Kamyker

    Joined:
    May 14, 2013
    Posts:
    1,091
    Limited free tier and monthly pricing throws me off. Pure $X per 1 000 RPD and $X per storage without any DAU limits would make more sense.
     
  2. Jirka-Mayer

    Jirka-Mayer

    Joined:
    Mar 18, 2019
    Posts:
    18
    Hmm, yep now that you point it out, it would make more sense. I originally had only DAU, then added request count to prevent request spamming and didn't realize the duplicity.

    And what about the service as a whole - do you think you would want to use it? You could, in theory, use Unisave to build an online RTS game, which is something that you cannot do with PlayFab. But you can also use it "only" for leaderboards. Do you think this amount of flexibility is useful? Would you use it for a project if you had the choice? Thanks :)
     
  3. Kamyker

    Kamyker

    Joined:
    May 14, 2013
    Posts:
    1,091
    Unity integration is nice but I guess it's not that different than using AWS/Azure etc so:
    Ex. from what I know making proper leaderboards for let's say 100k players is not that easy with raw database. What do you mean exactly by "online RTS game"?
     
  4. Jirka-Mayer

    Jirka-Mayer

    Joined:
    Mar 18, 2019
    Posts:
    18
    I think Unity integration is the main feature and it is the primary thing that differentiates Unisave from AWS. AWS is like Digital Ocean and Unsiave runs on Digital Ocean. If Unisave wasn't much different, then it wouldn't do much. But it provides you with a Unity asset, it solves serialization, solves RPC ("facets"), provides an ODM mapping layer ("entities"), gives your backend logic a structure ("UnisaveFramework"), solves backend deployment, gives you templates for player authentication, etc... Anyways the point I wanted to make is that Unisave is much more than AWS, (like PlayFab), while at the same time retaining the flexibility you have with AWS (which PlayFab does not).

    It's true, that making a leaderboard for 100K players requires some fancy datastructures, but that's something you could build on top of Unisave and I plan to add it to the library of templates (just like player authentication already is) so that you don't have to code it yourself and instead just use it right away. While still having the option to modify the leaderboard logic (which might not be useful with leaderboards, but it is useful with authentication or matchmaking).

    By online RTS game I mean games like: OGame, DarkOrbit, Gladiatus... basically games like these: https://gameforge.com/en-GB/browser-games/

    Either way, thanks for your feedback, it's been quite valuable to me :)
     
  5. Kamyker

    Kamyker

    Joined:
    May 14, 2013
    Posts:
    1,091
    Tbh you shouldn't focus only on Unity but C# in more general sense + REST api to be able to get data in all languages and also from websites. So far every solution I've tried is at least weird. Azure Functions (and PlayFab C# cloud script) or IBM Cloud is a mess. Ended up using AWS but it's the most expensive one.

    I see your product is more focus around data than processing but I wish it could do both. One huge problem with all FaaS is async code (for ex. waiting for other request to complete) - why we have to pay for that the same amount of resources as for running code? One service trying to solve it is Google Cloud Run but I haven't tried it yet.
    https://unisave.cloud/docs/features:
    Not enough for me. Scheduling functions and at least matched time limit to PlayFab one (10 seconds) would be great.
     
  6. Jirka-Mayer

    Jirka-Mayer

    Joined:
    Mar 18, 2019
    Posts:
    18
    I agree that having only Unity to access the cloud is limiting. I plan on adding "web hooks"... or rather... basically a REST endpoint - as you point out. It will be needed for listening to web hooks from Photon and for validation purchases from Steam or Google Play. It's just that I haven't implemented it yet.

    Scheduler is again something a plan on adding. Man, developing this thing takes a long time... :D I see that the 5s limit is too low. I'm thinking of making it dynamic or based on pricing. I don't want to kill your occasional long-running processing operation, so maybe even 60s would do. But I also don't want a random noob on the internet spamming expensive requests because he accidentally made an infinite loop. That's why I chose 5s as a starter and I can make it more dynamic in the future. Maybe paying users get higher limit or you can have an occasional spike over 30s. Something like that.

    Putting all these constraints and limitation into the pricing table would clutter it completely. Would you like it if you had a dedicated "pricing" page, where all these quotas would be explained? (e.g. some kind of analysis like you did in the first post) I want to be transparent about it.

    You know, this is precisely the reason I went out with the service right now. It's not finished, by no means. But it also has enough features to build a decent game. And I want to get all this feedback early so that I know how to continue with the development. And also get early customers so that I don't develop it with hope only - it's far too expensive to develop it blindly and hope I hit the right product by chance.
     
  7. Jirka-Mayer

    Jirka-Mayer

    Joined:
    Mar 18, 2019
    Posts:
    18
    Also Engine Evolution (the game using Unisave) has average request processing time of ~100ms, so 5 000ms (5s) limit here is more than enough. And it uses Unisave to store all player data (unlocked motorbikes) and process it (buying motorbikes / equipment), so the amount of requests is above an average game having only leaderboards or in-app purchase validations.

    But I agree that it does not allow for rare, expensive processing that would take many seconds (e.g. database migrations, computing some summaries, etc.), I need to address that.
     
    Last edited: Jul 24, 2020
  8. Kamyker

    Kamyker

    Joined:
    May 14, 2013
    Posts:
    1,091
    In my case it's more about web requests, for ex. to calculate https://beataim.com/esports every 5 min it has to:
    1. Get correct Steam leaderboards ids from web
    2. Get Steam leaderboards (like 15 leaderboards with up to 100 users)
    3. Combine everything together (sync code)
    4. Update Azure database

    Sometimes it takes more than 5 sec, depends how slow Steam/Azure servers are.

    I know, that's why I didn't want to use AWS/Azure myself for basic stuff already solved in PlayFab/Chilli. Maybe instead of reinventing the wheel (but well, you did a lot already :p) your service could easily work with PlayFab/ChilliConnect/Steam?[/QUOTE]
    AWS has rate limiter, you can set max amount of request per second (or something similar). You should also add processing cost (10sec action should cost a lot more than 100ms). I'm not a fan of how Azure/AWS handles billing - we have to connect credit cards and risk getting overpaid during ddos attacks or "infinite loop" bugs. Digital Ocean balance makes more sense - you store X amount of money to cover predicted cost, when you go over it service stops working.

    So ye imo better pricing would be:
    $X per 100 000 requests (not per day)
    $X per memory/cpu compute time (like https://cloud.google.com/functions/pricing)
    $X per Xgb database storage

    Some free monthly quotas, when it goes beyond user has to pay from their "balance".
     
  9. Jirka-Mayer

    Jirka-Mayer

    Joined:
    Mar 18, 2019
    Posts:
    18
    Aaah, that's why you said that FaaS pisses you off since you have to pay for asynchronous waiting, not actual code execution. That's true. But from the other perspective, even though your code is "only" waiting, it still occupies some sandbox, is loaded into the memory and consumes a lot of other resources ("just by waiting"). And that is costing the provider money, whether they like or not. So you pay for it. The actual "computation" is not that expensive (unless you do some computationally heavy stuff, which you typically don't). It's all the orchestration around it that you pay for.

    Yep, interoperability with Steam and other services is something that's very much needed. That's the REST endpoint, you and I were talking about earlier.

    You agree, that it's better to have quotas, then to fear paying insane amounts of money if your game suddenly gets popular. That's why I have pricing tiers at all - each with different quotas and you have to switch them manually. The reason the quotas are enforced daily (not monthly) is that if you run out of quotas on monday, your game is available again on tuesday, not the next month. If you didn't have quotas at all and instead had some credit, then running out of credit would be even worse - your game is down until you increase the credit, manually. So I think this "monthly pricing & daily quota" scheme balances all the requirements:
    a) you don't want to potencially pay insane money
    b) the downtime is not as drastic for the players when you run out of quotas (or credit).

    Well... daily quotas are basicly the rate limitter you talked about with respect to AWS. It's just done daily, not per minute. The reason is, that short-time limitter is bad at handling short bursts of requests. It might give a false alert. (Short bursts might occur naturally - matchmaker creates a match, now 40 people perform the same requests at the same time, etc..)

    Digital Ocean does the same thing - you pay X$ for a droplet of given size, whether you use it or not. You have to scale it up/down manually. If you use Unisave and have no players, then be in the free tier. If you have no players, but a ton of data in the database - that data is taking up resources I have to pay for, so you have to pay for the data as well. We might argue about the specific numbers or metrics, but I think the tier-based model with quotas works well for both sides. :)
     
  10. Kamyker

    Kamyker

    Joined:
    May 14, 2013
    Posts:
    1,091
    Unity showed some Chilli - Unity integration.
     
    Jirka-Mayer likes this.
  11. Kamyker

    Kamyker

    Joined:
    May 14, 2013
    Posts:
    1,091
  12. panayiotismilios

    panayiotismilios

    Joined:
    Jun 21, 2018
    Posts:
    8
    For anyone caring there are more BaaS than the original post. We have a small discord community where we compare BaaS services. Feel free to join us and find out more

    https://discord.gg/VW3QXk
     
  13. mboyle

    mboyle

    Joined:
    Sep 10, 2015
    Posts:
    6
    Looks like I might be too late for the link? Could you share another invite?
     
  14. Jirka-Mayer

    Jirka-Mayer

    Joined:
    Mar 18, 2019
    Posts:
    18
    https://discord.me/baas
     
    mboyle likes this.
  15. Kamyker

    Kamyker

    Joined:
    May 14, 2013
    Posts:
    1,091
    Bethesda using playfab soon?

     
  16. Kamyker

    Kamyker

    Joined:
    May 14, 2013
    Posts:
    1,091
    Novack and Antony-Blackett like this.