[Photon vs UNET] JUST PRICING, lets talk about money

Ok, first things first, I've done my homework, I've worked with both Photon and UNET for the same project and I would LOVE to use UNET (I mean it... I'm a fanboy) since I liked more than Photon in terms of programming and overall functionality and I know that it will get more support as time passes... but WHAT THE HELL these prices... I mean, photon has a 500ccu, 200k MAU for 95 USD/mo (just as an example) and if we calculate this on the UNET "go live" we get a range of 670+ to 2700~ USD/mo for the same... I mean 28+ times more?... really?... am I missing something? what the asdfasda? theres something I haven't noticed? I'm stupid? I'm just... stunned...
BTW, I know that I can tweak the msg/player/sec and the band that I want to use, but... still...
If I, for example, reduce the msgs and the band for a turn based game I still get more than 400 USD/mo for something that I could use for 65 with Photon...

Unity Price (500 CCU, 50k MAU)


Photon Price



2019 Edit: This post is irrelevant since its from 2016 and unet is trash and deprecated

 

Wow!!!
Thank you for sharing metalkat.

 

Holy hell. There must be a reason for this. This isn't just the matchmaking/NAT prices, right? We must be missing something. That pricing is insane - down right obnoxious, even.

 

that's why I'm asking, I'm really concern about this... I know that this is just for the cloud service, so, if you are reading this, you can still use the networking features, but the matchmaking and other services are related to these prices...
Anyway, the price is still plain and simply nonviable... so, what am I missing?

 

I don't think you're missing anything. It's quite ridiculous. Some of the things Unity plans/prices just make very little sense.

 

can any of the unity guys answer this?
if you create a matchmaking lobby/match with X ppl, and they all connect, then the host acts as a server right?
ok, then, those CCU are still used until the whole match its done or I can reuse those CCU for more ppl, since they are already hosting themselves during the match?

 

Addition to what metalkat says, here is how I understand the pricing;

Unity doesn't show any CCU limit above 200, it only calculates according to the gb bandwith used.

So what I understand is, this 200 CCU-Unity Pro License(20 CCU for Personal Edition) limit is for non-published games, so only for testing purposes during the development time.

When we release our game, this CCU limit disappears because what Unity calculates is only the gb bandwith that their servers uses. That's why the pricing page calculates gb bandwith according to ccu and mau. Am I right? Can anyone from Unity confirm whether this understanding is correct or not?

Thanks

 

@hakankaraduman That was my understanding as well. Once you're in release mode it's all about the bandwidth.

If you're looking to reduce your bandwidth usage on the relay servers I recommend using my plugin so your players can connect directly ~90% of the time. Unity's relay servers are a great service to have available, but there's no reason to use them any more than necessary, especially since a direct connection is going to tend to be faster with less latency.

Check it out on the asset store or read more more about it in this unity forum thread.

 

@hakankaraduman

That's why is an estimate, but again, the estimations for 500 CCU are those...

 

It's more ridiculous if you compare with the photon lifetime plan ($95 with 100 CCU), you only pay once.
I love unity but.. this is too expensive for me

 

well with Photon you have a max of 500 messages/s per room so the sendrate of your players would be too low if you have too much players, in our case we'd want to have max 20 players per room, so with photon cloud our max # of messages that a player could send per second it's 1 message, that is ridiculous for an action game so Photon Cloud is not a suitable option if you're planning to have too much players per room in my opinion if you have more than 6 players per room the thing start to struggle because the limit is 14 messages per second (the messages are things like transform updates, shoots, syncrhonize variables everything that in unet would be a command or a client rpc is a message) so in our case we're still with Unet, photon has also photon bolt that is an option but redo all the networking code it could be a lot of work, and it uses NAT punchtrough only, so, not the 100% of players could connect to another players

 

The right approach is to not send every message to every player, e.g. by using Photon's Interest Groups. The 500msg per room with Photon are not a hard limit, but a recommendation. Sending too much messages causes more or less performance problems on the game client, so you should try to minimize your game traffic anyway.
Plus sending many messages causes huge traffic. Photon includes 3GB per CCU and month btw.. This is usually enough for an fast-paced game like an FPS.

 

Is that right? I've never seen that stated on any Photon PUN documentation.

 

Yes, it is right

 

Have you got an official source for that?

 

this post is from 2016... wtf

 

Your original post was, but PhotonEngine's comments were later, and I'm still trying to find out if why he thinks what he said about the 500msg per room is correct, when I've been unable to confirm it myself.

 

This is on the pricing page for the Photon Cloud. It's not directly a limit of PUN or Realtime but yes, both could still list this limit more clearly.

 

Hi @tobiass, so I'm still not clear about this, is it a hard limit or not? And in either case what are the implications of exceeding it by a small margin from time to time?

 

It's a soft limit. Use it as target, please. If you go over it excessively and for prolonged times, we would reach out to you to work on this.
We just need to define some limit, or else we have no leverage to deal with excessive message-usage. This is somewhat important, as the public Photon Cloud is shared among many games. More messages/sec and room are possible but we would like to run such game on separate machines (for performance and network reasons).

 

Thanks for the clarification, we are designing the game around a 500msg/sec target, so it shouldn't be an issue, but it's good to know that we have a little leeway without it causing problems, like suddenly dropping lots of messages etc.