20
Dec 11

Over 2,500 apps and counting are running on the Photon Cloud by today. For free. We think it is about time to tell you all what we would like to charge once the free beta phase is over and what you will get for it.

We already announced the $9/month subscription fee for the Photon Cloud 100 indie account and we decided to offer two more flavours namely Photon Cloud 500 and Photon Cloud 1,000 which we priced really, really tight as well. You guessed it: the numbers 100, 500, 1k are according to the concurrent user limit. You need more than 1,000 concurrent users? No problem, just upgrade your account with additional Photon Cloud subscriptions.

All Photon Cloud accounts include support, plenty of message traffic and both Photon Cloud 500 & 1,000 come with a flexible concurrent user limit, which we call ‘CCU Burst’. It means that we will not block any user from your app even in case your concurrent user limit is exceeded. Instead you are notified and you can decide within 24h if you like to upgrade your Photon Cloud account.

You can upgrade, downgrade or cancel your Photon Cloud account at any time.

The pricing becomes effective in February 2012, so if you have a free Photon Cloud account it will remain free until 31st of January, 2012.

No free Photon Cloud account yet? Create one at www.exitgamescloud.com

Have a look at over pricing overview on: cloud.exitgames.com/Pricing

Tags: , , ,

11 comments

  1. Not only is this a great price, thank you guys for extending the trial version until the 31st of January. This is by far one of the best services I’ve ever used.

    Thank you Exit Games!!!!!

  2. You are welcome! Happy you are happy :)

  3. Is there an easy way to see how many messages per second a game is currently running at?

  4. Excellent question, Chris! Yes, there will be a counter in Photon Control showing you the messages per second.

  5. Robert, what constitutes a “message” in Photon? A request to the cloud? A reply to the client? Both?

  6. @Max: A message in Photon are operation calls, responses and generated events. Assuming your have a room with 4 players and you call raiseEvent(…):
    a) The raiseEvent() call is 1 message
    b) #a leads to 3 events sent to the other players: 3 messages

    So a simplified formula is:
    rate: 10 messages/s
    ppr (player per room): 4
    messages/s = ppr * ppr * rate = 4 * 4 * 10 = 160

    We will detail this more in January.

  7. That might only be me but it sounds like an extremely low / insufficient limit, as it means that no ‘realtime networking’ using OnSerialize of PhotonViews in is possible as already with 5 players and a reasonable rate (20 messages a second) the limit would be exceeded. And if you have more than 100 CCUs you can’t event fit 5 players in anymore in the same situation.
    That the scope handling isn’t present on the server side but ‘client side filtering’ is a rather extreme set back in this case too as it is definitely be required in this case to even work with this limits.

    The only game type where this limit would not be a problem is one where its used for an ‘single player MMO’ (FB style MMO) style game and thats impossible as the server logic can’t be bound to a DB to facilitate it. That and naturaly the 10 thousand and first page with 2 – 4 player ‘board games on the web’ and alike, games that are simple enough networking wise and not realtime.

    I personally would favor a more scaling price model in relation to the messages that takes into account the need of realtime serialization, as the prices currently are great but unlikely leave much space to raise the limits (yet they might fit some titles very well but would instantly kill others).
    That being said unless you have specific reasons and think that people doing realtime games should host their server themself, potentially not in a cloud

  8. Thanks for your intense comments Marc :) .

    Do not worry too much about the limits for now
    1) we do not cap anything as of yet.
    2) based on user feedback we will make everything possible (that makes sense)

    One thing is clear: We need to cap the usage somehow. We are already pushing out up to 4MB/s, which leads to several TB (Terra!) a month.

  9. There I agree, either a cap or reflecting heavy usage on the costs is required.
    Thats where my thoughts were when I wrote the last block above with ‘scaling prices for more messages’ as I fully understand that it will otherwise ‘blow up’, bandwidth wise and traffic cost wise

  10. What are concurrent users? Is it a limit of users per application, per room, or per aacount? What do I need, if its 10000 users online, but only 10-20 users per room?

  11. @Pavel, Concurrent User (CCU) means users online at the same time. CCU are per Application.
    If you want 10,000 CCU you need 10 times the 1,000 CCU license.

    10,000 CCU is HUGE and translates to:
    Daily Active User: DAU = 20 * CCU = 20 * 10,000 = 200,000
    Monthly Active User: MAU = 10 * DAU = 2,000,000

    You will probably make a lot of money with your game.