We experienced an outage of several Photon Cloud services today:
April 30th, 2015, from 01:25 UTC to 08:40 AM UTC.

End users (or players) affected:
– End users in North Europe and West Europe may have experienced failures connecting to services.

Services affected:
– Photon Chat:  not reachable for new connections from 07:21 AM – 8:40 AM UTC.
– Photon Realtime & Turnbased: partially not reachable between 01:25 AM UTC to 07:50 AM UTC.
– License Server (for self-hosted Photon Server SDK): partially not reachable between 01:25 AM UTC to 07:50 AM UTC.

Background information:
All services use our Name Server (ns.exitgames.com) to resolve to the service endpoint (IP address). The availability of this name server is essential so we decided for a HA (high availability) setup.

a) We have Name Servers in 3 Regions: US, Europe and Asia
b) Each region we has multiple server load balanced
c) The regions are load balanced via a geo loadbalancing services (DNS based)

Our license server uses the same HA setup.

Root cause:
The root cause was an outage of Microsoft Azure’s Network Infrastructure:

“From 30 APR, 2015 01:25 UTC to 10:17 UTC customers in North Europe and West Europe may have experienced DNS resolution failures to their services. Engineering teams have identified the root cause and deployed a mitigation, and we have confirmed that normal service availability has been restored. Engineers are continuing to work on a resolution for other impacted regions.”
(by Azure Status page: http://azure.microsoft.com/en-us/status/#history)

As described above we at Exit Games are relying on Azure’s high availability network infrastructure to host some of our Photon Cloud services.

We were able to mitigate the issue (switched to static IPs, use fallback services at other hosters etc.), so that by 8:40 AM UTC, all Photon Cloud services were reachable again.
By 10:17 AM UTC, all Azure services were reachable again, and by 12:30 AM UTC, we had reverted our hotfix configurations and are now using our original, stable configuration again.

Actions:
We are planning the following measures to avoid issues like these in future:
– improve our monitoring to be more “region aware”. Only certain regions or customers from certain regions were affected, and we did not get alerted for all incidents as fast as possible, so we lost some time to react to the problems.
– set up critical services & network infrastructure (like geo-based traffic routing) at a different hoster as a fallback, and make it easy to switch to the fallback services automatically.

We sincerely apologize for the issues.

If you have further questions, please drop us a mail: developer@exitgames.com

This guest post was written by Constantinos Miltiadis, Founder of studioAny.
What if you being here, could be a virtual presence anywhere? project Anywhere, developed by Constantinos Miltiadis, at the Chair for CAAD, ETHz, is an intention to breach the limits of physical human presence, by replacing kinaesthetic, visual and auditory with artificial sensory experiences, in a fully interactive virtual environment.
project Anywhere was featured in The Guardian (Project Anywhere: digital route to an out-of-body experience), The Observer Tech Monthly (Jan 11, 2015), Euronews Sci-tech / Project Anywhere: an out-of-body experience of a new kind [multilingual], Reuters video interview / Project Anywhere takes virtual reality gaming to new level, has been exhibited in a public installation at the TEDxNTUA events (Jan 17, 2015) and made 2nd place in Zeiss VR One Contest for Mobile VR Apps.

Overview

project Anywhere is a wireless, multiplayer, interactive, augmented reality application that uses smartphones as stereoscopic head-mounted displays. It was developed in Unity 3D, and also uses a Java program and Arduino microcontrollers.

project Anywhere from studio any on Vimeo.

Background and overview of the concept development

Studied architecture at NTUA in Athens and at ETH in Zurich, being a self-taught programmer, I was introduced to Unity 3D during a 3 day workshop at the Chair for CAAD at ETHz, by Sebastian Tobler of Ateo. I was initially sceptical as to what kind of projects it would help me realise, until I tried the Oculus Rift; the potentiality of which really amazed me. While wearing it, I lost connection with my physical surroundings in seconds and the first think that came to my mind, was to try and see my own body, and move in the virtual space by moving in the real one. But that wasn’t the case.

Searching to find the state of the art in VR, I couldn’t actually find any content that would allow for a greater degree of immersion into virtual reality. For me, at the time, it was a paradox that the game industry didn’t manage to emancipate from classical ways of interfacing (keyboards and joysticks) and even try to do some steps towards reinventing gaming for this new technology, rather than just appropriating it to older concepts.

It was then when I was first struck by the idea of developing project Anywhere. The goal was to prove that it is feasible to have your whole body controlling a digital avatar in a virtual environment in a 1 to 1 correspondence, in real-time. Therefore, I took it upon my self to try and develop a way to quantise my presence in physical space, and use it to “invent” intuitive ways to interact with a virtual environment.

I had to abandon the idea of using the Oculus Rift because of its cables, and decided to use a smart phone as a head-mounted display instead, for which I eventually prototyped a 3d printed phone-holder mask. For body tracking I implemented common Microsoft Kinect infrared sensors that would provide a vector set of the player’s skeleton joints positions. For the gestures and hand movements in space, I developed a pair of wireless interactive gloves, which would provide the palm orientation in space and the flexing of the fingers. The Kinect sensors and the gloves were brought together by a Java program I developed called “Omnitracker”, that makes sensor readings in a frequency that ranges between 20-40Hz (minimum every 50 milliseconds).

I have to admit, that initially I had no clear idea of how to do it, or even if it was actually feasible. In the 6 months however I spent developing it, I had to go through a lot of different trades; from prototyping, to micro controller programming, to advanced vector math etc. Step by step everything started falling into place, and networking was from the beginning a keystone, and a fearful issue to address. However, at some point I found the Photon PUN Unity plugin, which proved to be a seamless and consistent framework, and furthermore, in my case, one that could be deployed and implemented very easily, while not getting in the way of the rest of the development.

project Anywhere networking overview

From a networking perspective Project Anywhere doesn’t offer anything new. It just uses or “exploits” the real-time functionalities of the Photon Networking to the maximum. The functionalities that I extensively used were the barebones of networking: Photon’s Synchronisation cycles (Serialisation) and Remote Procedure Calls (RPCs).

Bear in mind that I am not experienced neither with game design nor with networking and thus I cannot claim that this is the ideal way to accomplish what I was going for. Nevertheless what I will describe in the following, is what for me got the job done, quite effectively.

Serialisation cycles:

Multi-player synchronisation

In a traditional multiplayer game you have a bunch of players, each one controlled locally. Any changes (eg movements) have to be synchronised as fast as possible, and are therefore sent from the local machine that made these changes, through the network, to the instances of that same player, on the game running on the other players’ computers. So each player is controlling from their local machines, their clones, in all the remote ones (multi-player synchronisation diagram).

External input synchronisation

In the case of project Anywhere though, this cycle get a bit more complicated. You actually have input produced by the local device that is running the game (ie head tracking calculated by the accelerometer and gyroscope sensors of the phone), but the body movements and hand gestures of the player in space, are not inputed by a local keyboard and mouse, but rather provided by sensors connected to another device.

Therefore, project Anywhere has 2 types of players:

• The “subject node” which is the player of the game and joins through a mobile device,
• and the “sensor node”, a computer connected to the Kinect sensors and glove receivers which handles their data.

So the Subject instance has to get the sensor data, use them, and then forward them to its remote instances.

To accomplish that, the flow of information has to perform a larger cycle. The Sensor Node is running in parallel the “Omnitracker” Java program that receives and processes data from the Kinect sensors (player position), and from the interactive gloves (hand movements and gestures). These data are then forwarded to the Unity application, and then pushed to the Photon Cloud via Remote Procedure Calls (RPCs – sensor data synchronisation diagram).

On the other end, the local Subject instance related to a particular data set, receives the data and applies the transformations (body skeleton position, hand orientation, finger flexing). When this is done it, it performs the serialisation cycle, sending the updated information to the cloud, for the other devices to update their instances.

Sensor data synchronization

Further synchronicity issues:

The process described above, gets a bit more tricky, when we add to the equation other parameters that affect synchronicity such as sensor errors and different sensor output frequencies. In order for these update cycles to appear seamless and uniform, the data have to undergo various smoothening iterations. This is also the primary cause of latency, as seen in the video, that has been to some extend optimised since the first demo.

Any feedback is welcome: studioany.zurich@gmail.com

A simple “Bam!” can hardly represent our excitement:
BOLT, the popular networking engine for Unity, is now part of the Photon family.

Fredrik Holmström, the inventor and mastermind behind BOLT, joins the Photon team to help shape the future of multiplayer technology.

Read here why we join forces, what the next steps are  >>

On Monday, 20th July, the Photon Cloud servers in the US Cloud were not available.
Players where affected was from 11:22 UTC – 13:40 UTC. Shortly after period, our servers started to accept connections again.
In that time, the datacenter of our provider suffered from a complete power outage.
The Chat Cloud, our Clouds in EU and none of the other Regions were affected.

At about the same time, also had an issue with our stats service failing. This was unrelated to the power outage and did not affect any players.
The issue was caused by an Out-of-Memory being handled very bad by the docker version we where using to host our service and it affected the primary
and secondary systems.
The stats-service failed from Sunday 19-Jul-2015 09:23 UTC – 20-Jul-2015 10:39 UTC.
Note: You may see data from some time before, where the stats-service was partially restored but not stable starting from 20-Jul-2015 8:20 UTC.

Planned Measures
1) We haven’t finished assessing how to handle a major disruption like the one caused by the power failure for the future.
In all the years since we started we didn’t have such a case.

2) The stats service is being upgraded this week – both memory and docker are being upgraded.

This guest post was written by Hayden Lee, Founder & Software Engineer at Convrge.
Convrge is a virtual world to hang out with your friends. Using the Oculus Rift you can get a sense of actually being with people that is unmatched across any other medium.

Activities in Convrge include watching YouTube videos, Twitch.TV, rockin’ out on the dancefloor and playing minigames, all with people from around the world.

Many people have been asking how we network players in Convrge. We’ve gone through a few iterations of different techniques ourselves and I wanted to spill the beans in this post to help other aspiring virtual reality developers be able to network their own games. One of the driving forces of creating Convrge in the beginning was the mismatch between how cool multiplayer VR experiences are and how few were actually available. Hopefully this post will help even out that mismatch, and help you add multiplayer to your virtual realities.

The tools are surprisingly easy to use:

• Unity Game Engine
• Photon Cloud (by Exit Games)
• Oculus Unity Integration

One thing to note here is that many, many multiplayer Oculus experiences already use these same tools. The “oh cool, what are you using for networking?” conversations usually end up pretty boring because the answer is almost universally “Photon.” Photon works very similarly to the standard built-in Unity networking tools which makes it very approachable, while also having a lot of advanced features and flexibility. Currently we use their PUN+ edition which allows up to 100 people on your app concurrently for a once off price of $99. Pretty groovy.

As I’m writing this I’ve realized how much easier this tutorial would be in video form, so I’m going to write out the general bullet points of the process and record the step-by-step in a video.

Here is the video (probably worth full screening it to see the text):

Here are the bullet points:

1. Import the Photon and Oculus Unity integrations.
2. Drag the Oculus Player Controller prefab into your scene.
3. Create a C# script to handle connecting to the network and instantiating the player, attach this to an empty GameObject (script is copied below).
4. Create a C# script to handle the player synchronization (script is copied below).
5. Create an empty GameObject for the player synchronization, add a photon view to this, and add the above script component to this.
6. Turn this GameObject into a prefab by dragging it into the Resources folder (this is also necessary to use this prefab with the Photon instantiate call).
7. Once the player prefab is instantiated we attach our own player to the CenterEyeAnchor of the Oculus Player Controller. Then we use the position/rotation of the Player controller for the global position of your avatar and the position/rotation of the CenterEyeAnchor for the local position.
8. Voila. Start game.

Here are the code snippets:

using UnityEngine;
using System.Collections;

public class NetworkedPlayer : Photon.MonoBehaviour
{
    public GameObject avatar;

    public Transform playerGlobal;
    public Transform playerLocal;

    void Start ()
    {
        Debug.Log("i'm instantiated");

        if (photonView.isMine)
        {
            Debug.Log("player is mine");

            playerGlobal = GameObject.Find("OVRPlayerController").transform;
            playerLocal = playerGlobal.Find("OVRCameraRig/TrackingSpace/CenterEyeAnchor");

            this.transform.SetParent(playerLocal);
            this.transform.localPosition = Vector3.zero;

            // avatar.SetActive(false);
        }
    }
	
    void OnPhotonSerializeView(PhotonStream stream, PhotonMessageInfo info)
    {
        if (stream.isWriting)
        {
            stream.SendNext(playerGlobal.position);
            stream.SendNext(playerGlobal.rotation);
            stream.SendNext(playerLocal.localPosition);
            stream.SendNext(playerLocal.localRotation);
        }
        else
        {
            this.transform.position = (Vector3)stream.ReceiveNext();
            this.transform.rotation = (Quaternion)stream.ReceiveNext();
            avatar.transform.localPosition = (Vector3)stream.ReceiveNext();
            avatar.transform.localRotation = (Quaternion)stream.ReceiveNext();
        }
    }
}

using UnityEngine;
using System.Collections;

public class NetworkController : MonoBehaviour
{
    string _room = "Tutorial_Convrge";

    void Start()
    {
        PhotonNetwork.ConnectUsingSettings("0.1");
    }

    void OnJoinedLobby()
    {
        Debug.Log("joined lobby");

        RoomOptions roomOptions = new RoomOptions() { };
        PhotonNetwork.JoinOrCreateRoom(_room, roomOptions, TypedLobby.Default);
    }

    void OnJoinedRoom()
    {
        PhotonNetwork.Instantiate("NetworkedPlayer", Vector3.zero, Quaternion.identity, 0);
    }
}

Any feedback is welcome at hayden@convrge.co

This guest post was written by Eric Lajeunesse, an indie developer from Montreal, Canada.

Ever wanted to step into a real soldier’s shoes as a crazy warrior with a shotgun, a stealth attacker or an agile sniper? Natural Born Soldier gives you this opportunity from your mobile as it delivers precisely what you expect as a competitive multiplayer shooter. Intuitive and smooth controls coupled with incredible and unique gameplay.

Natural Born Soldier is bringing you something pretty awesome: the game allows you to make your soldier authentically you by transposing your own image onto your 3D soldier’s face using a photo or an avatar.

Natural Born Soldier offers classic game modes like Free-For-All, Team DeathMatch, but also high-adrenaline game modes like «Search & Protect», a co-op survival mode, plus numerous new weapons to unlock as you progress through the ranks.

Natural Born Soldier comes deep from my passion for the FPS (first person shooter) games genre. I like the adrenaline that is generated when shooting at someone, making a nice kill, or being shot and running for your life Of course all those in the context of a game.

I used to play more FPS when I was younger and the one I played the most was Rainbow 6 on PC more than a decade ago. At some point in 2012 Unity was giving a free license for one day only so I did apply for it  and started playing with it. In parallel I was playing some FPS games on my iPad. I found Unity pretty cool and at the same time was kind of frustrated with the FPS games I was playing on mobile. So I figured out that it would be a really good challenge to create my own FPS game on mobile and that was when this crazy project was kicked off.

Natural Born Soldier is a cross platform FPS for mobile devices (iOS and Android mainly). Since day one I had clearly in my mind that I wanted to put the emphasis on the multiplayer aspect which is the part I like the most personally. I wanted to innovate on many fronts: the controls, the multiplayer game modes and also on the customization of the player itself.

Multiplayer FPS: feasible on mobile?

As I was playing some FPS on mobile I knew it was possible to create such game on mobile, but I was not sure it was possible with Unity. Furthermore, I had planned at the beginning to support 16-32 players, but I was not sure if that would be working at all on mobile devices.
I started investigating which network framework I could use for that as after little investigation I figured out it was totally useless to create my own from scratch and it would be too time consuming. I also had clear in my mind that going with a Peer-to-Peer (P2P) network framework would probably be my best shot in order to support such a big number of players and also scalability wise instead of going as a classic client-server (C/S) architecture.

I did read about Photon at first, but had some concerns as it is a C/S architecture and regards its data transfer  limit (500 msg/room/sec.). Then, I did look at Badumna (from Scalify – R.I.P.), this was a new well-crafted P2P network framework that I considered the only good one that seemed to have a bright future. So I decided to jump into that one as it was looking good with the requirements I had in mind.

After about 6 month implementing my game and after having integrated the core part of Badumna into my game, I figured out after testing on a couple of devices that connectivity was not working so well and it was also requiring a lot of CPU resources in order to maintain all the TCP/IP peer’s connections. Having ~4 connected client was ok, but once going above that, the game’s frame-rate on my iPhone4 was dropping considerably which was not acceptable.

On top of that, there was another major problem: before allowing to connect with other clients, you needed to connect to a master server first in the cloud, but establishing this connection was a problem as sometimes it was taking as long as 1-2 minutes, which was really unacceptable and not consistent over time.

Client/Server VS. Peer to Peer networking framework: moving to Photon Unity Networking (PUN)

So after loosing some hair and being frustrated about Badumna, I had the feeling that this was not going to work out at all and I needed to change direction. Not an easy decision, but a good one at the end :).

So I decided to step back and read more deeply about Photon and other networking frameworks. I ended-up concluding that Photon was my best option now as I did found that P2P was not giving good result at the end performance wise, so I wanted the classic C/S architecture framework.
After some calculation I did figure out that the data limitation and the price was not really a problem at the end and fair enough :), so I jumped in. Nevertheless, because of the data limitation (500 msg/room/s) I did limit my maximum number of players to 8.

I had estimated about 1 month of work in order to replace my Badumna integration with Photon (PUN), but I end up really surprised that I was able to-do the migration within two weeks :). This was mainly because PUN was straight forward and also because I properly separated my network integration from the other layers (e.g.: GUI). Once it was implemented I’ve continued the development for more than a year and I can say that I never faced a connectivity issue using Photon Cloud. That was pretty amazing.

Photon Cloud and PUN: tweak the engine

While Photon was pretty straight forward to integrate, this doesn’t ensure your game’s multiplayer experience will be good. You need to use PUN and the tools provided properly in the context of your game to make that happen.

The first challenge I faced was the smoothness of the players that was not good enough; it was choppy and didn’t look good. I was using interpolation in order to smooth the movement at that time as shown in the demos coming with PUN, but somehow sometimes it was not working.

I figured out that sometimes old packets were coming in and this was generating glitches or message rate was not coming as often as planned. My message rate was initially at 15Hz (15*8*8 = 960 msg/room/s) which I figured out would not be working in production (> 500 msg/room/s).  Finally, I end-up using 10Hz (10*8*8 = 640msg/s/room, but since I used “Unreliable On Change” on my player’s transform this averages down to ~500) frequency for player’s position, rotation and body angle, and interpolating this locally with some interest management to minimize CPU resources on the receiver part. For example, on the receiver part I only do the full smoothing calculation if the local player is actually seeing the remote player being processed, otherwise I only update the remote player information without doing any smoothest computation.

In addition to the information mentioned earlier, I also added a “short” to be sent in player’s OnPhotonSerializeView to be sure I would never process an old packet and get some glitches as mentioned earlier, as somehow PhotonMessageInfo.timestamp couldn’t be trusted at 100%, at least according to what I have experimented.

Furthermore, in order to minimize cheating and send sensitive data to other players in a secure way (eg: player’s photo, critical RPCs like when a player is receive damage, etc.) I needed to add a public API into PUN in order to be able to send encrypted RPC calls. This functionality has been added officially into PUN by Exit Games, the Photon creators.

Another area which required me more effort than anticipated (and which is not complete yet, as my Android version is coming) is how to handle properly the player’s state when the game goes into background, or when some native UI just popup on top of the game, like when a SMS notification come in, low battery popup, or if the player slides down/up the quick settings panel in order to change the luminosity of his screen etc.

At the end, I had to-do the following modifications for iOS (Android TBD):

• When a player goes into background, since I do not know when he might comes back, I disconnect him right away from the room, and in case it’s the master client, he will call PhotonNetwork.SetMasterClient to delegate his master role to another player, so that the game can continue working properly right away.
• When a native UI show up, OnApplicationPause is called (Unity related, not Photon), but in such case since this may be temporary, I don’t disconnect the player right away. I allow the player 10 seconds to-do his thing, and if he doesn’t come back by that time, I disconnect him as if would have gone into background. In order to achieve that, I needed to modify a bit the file UnityAppController.mm in Xcode among other things.

What’s next?

Natural Born Soldier for iOS has been released on October 21, 2015 on the App Store. I’m now working on the next update which will include a new map and couples of fixes, and in parallel I’m also pushing for the Android version, which will require some tweaks to manage properly the player’s state too among others things.

I hope to see all of you reading this on the battlefield so I can kick your ass lol.

PS: in case of any questions please get in touch via elajeunesse@naturalbornsoldier.com

Best,
Eric

This guest post was written by Sebastian Erben, co-founder of indie studio Bit2Good.

Bit2Good produces handcrafted games independently since 2011. Their most current project is ‘Goggles – World of Vaporia’, a vehicle combat shooter set in a Steampunk styled world called Vaporia.

Goggles was initially developed as a single player experience and was then transformed into a 4 player co-op online game with the help of Photon Unity Networking.

Sebastian shares some bits of what worked for them and what didn’t during that transformation process.

Get Goggles – World of Vaporia on Steam.

Out of the comfort zone

When we began development of Goggles in 2012 it was neither a 4 player coop game, nor was it called Goggles (you can read more on the general development of Goggles here).

Online multiplayer wasn’t a topic that we had gathered any experience before either so for us there was no natural approach to the multiplayer side of game development. Thus, we made some mistakes and learned some lessons the hard way and I’d like to share some of that knowledge with you, hoping that at least some of them will be helpful ;).

Lesson No. 1: Multiplayer as a feature

Since our schedule and budget was tight, we had to work on multiple things at the same time and that’s the reason Goggles’ multiplayer was treated more like a tacked-on feature than an integral part of the gameplay experience. This gave us many headaches later on, since all the levels were first developed to work in singleplayer. The problem with this is that not every member of the team became acquainted with multiplayer and many parts of the game had to be rewritten at a certain point of development in order to work in multiplayer.

So if you want to create a multiplayer game, make sure you set up a multiplayer centric structure first and then handle the singleplayer as a one player multiplayer match, possibly with special rules. If you already have a singleplayer game and want to add multiplayer to it, be prepared to change huge parts of the codebase. It’s pretty much inevitable.

Lesson No. 2: If everything else fails – RPC

When using Photon Unity Network (or PUN), the first tutorials will do a pretty decent job teaching you the basics of network multiplayer. They are easy to understand because mostly the OnPhotonSerializeView callback which you can use to keep values synchronized.

However, if your game is not from the ground up build as a multiplayer game, OnPhotonSerializeView can actually cause some trouble. Imagine your enemies as state machines (which they probably are) that will act differently depending on a bunch of values. It’s now tempting to just keep all values in sync all the time but this will likely yield bad results. The best thing would probably be to conditionally sync via OnPhotonSerializeView and PhotonNetwork.RaiseEvent.

But if your development process is similar to ours, that might lead to a complete rewrite of the enemy logic which, if on a tight budget, is problematic. What we do instead is to just sync position values every once in a while and apart from that use RPCs to only sync what needs to be synced. RPCs are reliable which can be drawback if used excessively but in our case enemies only change their behaviour once in a while. The great thing about RPCs is the amount of control about what to synchronize and what to do with those values.

Lesson No. 3: Know your RPCs & cull

When starting out with RPCs, you’ll first get to know them as some sort of “networked functions” and you’ll probably start out by using PhotonTargets.All. Don’t stop there!

RPCs can be made with either a PhotonTargets value or a PhotonPlayer value and both are super useful because they allow us to implement some very easy network culling (if you want to know more about network culling, take a look at this tutorial)!

PhotonTargets is best used when you want to leverage PhotonNetwork’s buffer or make sure everyone (sender as well as receivers) gets a RPC from the Photon server.

PhotonPlayer is used best when you only want certain clients to receive RPCs. A real world example from our Goggles is the synchronization of enemies. As I wrote before, many elements of Goggles came into being as a singleplayer function and some of them weren’t rewritten because of the time it would have taken to do so. The administration of enemies is one of those elements so the master client always knows every enemy and is responsible for spawning and despawning them. Enemies synchronize themselves with all clients and it is here where we were able to gain some drastic improvements in network performance by using PhotonPlayer:

// We iterate through our players which are represented in a custom class that holds
// references to transform and photon player.
// attacking is a private boolean variable telling us if the enemy is currently attacking.
// myself is a private variable referencing the enemies own transform.
// SyncThreshold is a public float variable.
if (Vector3.Distance(_player.Trans.position, myself.position) < SyncThreshold){
    if (!_player.PhotonPlayer.isLocal){
        myPhoton.RPC("UpdateAttackState", _player.PhotonPlayer, attacking);
    }
}

This piece of code essentially looks which client is near enough and then synchronizes the enemy’s attack state via UpdateAttackState which is a custom RPC. It doesn’t seem like much, but when 4 players are spreading out (which is the worst case since each player will trigger enemies per portal that they’re approaching) this bit of code saves us up to 66% of bandwith compared to a simple PhotonTargets.All approach.

Lesson No. 4: Know your callbacks

PUN gives you a whole bunch of useful callbacks that are rarely explored in tutorials because it’s hard to tailor a meaningful example for each one of them. I suggest you take a look at the Photon.PunBehaviour class reference and tinker with the callbacks that seem useful to you.

This is actually an advice that you can expand to Unity itself: being aware of the existance of a specific callback can you save hours, maybe even days of work. It could also lead to ideas for new features that you otherwise would never have considered to implement.

Takeaway

Most of this will be an old hat if you’re a developer that’s seasoned in the art of network. But if you’re just starting out or in the middle of development of your first network game I have a feeling this could provide some help for you; I certainly would have liked some of this advice ;).

If you have any questions or feedback or you just want to get in touch you can find me on Twitter @thebossti or send me an email at erben.sebastian@bit2good.com.

Photon Server enabled real-time battles in “Famista Dream Match” – A remake of the pioneer battle game.

Ever since “Professional Baseball Family Stadium” was released in 1986, the Famista series has been loved by a range of generations. “Famista Dream Match” is the latest game in the series.

The online real-time battles in the game are powered by Photon Server. The online battle functions could be implemented soon after its adoption with a minimum amount of lag occurring during games. We interviewed the producer of the game, Mr. Oikawa and system directors, Mr. Kawahara and Mr. Ikeda, all of BANDAI NAMCO Entertainment, to hear why they chose Photon Server and about their future business plan.

Thank you for your time today. First of all, please tell me how you decided to remake Famista, which is close to 30-years-old, as an online game with real-time battle functions.

Oikawa: We already had a Famista game app, but instead of users playing battles online, the game allowed users to select AI opponents only. However, we were very keen to implement battle functions as producers because we thought “battles are a key component of Famista,” and users wanted to hit balls pitched by real opponent pitchers and strike out batters.

Being able to battle has been one of the attractions of Famista ever since the NES era, wasn’t it?

Oikawa: Yes. Since we were launching games with the Famista brand name, we wanted to implement real-time battle functions. Yet we had not been able to realize it due to limited connection speeds and the insufficient power of game cl
ients. However, as LTE networks started replacing 3G networks and smartphones became more powerful, we started exploring the possibility of realizing online real-time battles. That was the start of the “Famista Dream Match” project.

On an unrelated topic, the music which plays when launching the application sounds like chip tune music. Did you have the Famicon generation in mind when you decided to use this music?

Oikawa: Yes. We kept the idea of using “music typical of Famista!” in mind. We designed the characters using pixel graphics rather than polygons because we wanted to attract the attention of users from the Famicon generation. However, aside from this we focused on the real-time nature of battles.

Please tell me how you got to know of Photon Server.

Ikeda: The transfer of information to-and-from between users is necessary to make real-time online battles possible. When we were looking for server systems to realize this, we came to know Photon Server as a possible candidate and tentatively adopted it.

What made you select Photon Server among the other candidates?

Ikeda: We particularly liked the fact that it was the most versatile. In addition, its high failure resistance is one of its advantages. Even if one server is down, another server can immediately replace it – such a structure is a great advantage.

So from the perspective of users, this means an environment that allows them to keep playing?

Ikeda: Yes. It was very important to us because we want to be sure to avoid situations in which users cannot continue playing games due to server failures.

Did you check the track record of Photon Server inside and outside of Japan?

Ikeda: I do not believe that Photon Server had been adopted by any applications domestically when we were considering adopting it. It seemed that there were some cases of adoption overseas, but we did not find it very relevant to us as we wanted to test the server first ourselves in any case.

How long did it take to introduce the real-time battle functions after adopting Photon Server?

Ikeda: It took us no longer than a month to introduce the battle functions at the pre-production stage.

Oikawa: We completed a basic battle system within a month. It was surprising to us back then that the system was made so fast.

You mean it was easier than expected, right?

Kawahara: Yes. I think it was fast until we completed the alpha version… Yet it took us almost a year to make adjustments to the system (laughs).

Oikawa: It requires a lot of checks, even in the case of just simply increasing the types of field…We are still making adjustments now.

Among all the data used in Famista Dream Match, could you tell us of the types of data communicated through Photon Server?

Ikeda: In the case of pitchers, the standing position of the pitcher on the plate, type of pitch, speed of the pitched ball, and course are communicated. As for batters, the standing position of the batter in the box and timing of the swing is communicated. Additionally, the course of a batted ball is also communicated. Photon Server takes care of all the exchanges between objects except for matching.

Are all those types of information communicated real-time?

Ikeda: The information is communicated in almost real-time during a battle. However, some lag is unavoidable due to the connection status. This is particularly true when the game is played on a moving train. There are also minor problems when the device is connected to the Wi-Fi of a train station. But as long as the connection status is good, battles can be played in almost real-time.

I was surprised to see that tactical moves such as a batter’s movements in the box can be made on a real-time basis when I was battling with another user. Are you satisfied with issues such as lag?

Ikeda: Yes. The server is being operated without problem. The performance is satisfactory, I’d say 80 out of 100.

Do you have any concerns about the operation of Photon Server or any other issues?

Kawahara: As I previously mentioned, while one of the characteristics of Photon Server is high failure resistance, the mass server t
hat is in charge of redundancy only
has a single port. Should this server go down, all services will be disabled. Therefore, some redundancy measures are desired. Moreover, I have a concern that Photon Server is only applicable to Windows servers…

Ikeda: I would appreciate it if Photon Server is made applicable to Unix servers. It is because we had to start by launching a Windows server, which was not very familiar to us…

Finally, what are your views on the future of online games?

Oikawa: Given the trends of smartphones and connection speeds, I am certain that online battles and real-time battles will be more common. We have not yet talked about how our company will develop games responding to such an overall trend (laughs).

As for Famista, please tell me what the upcoming version up will be like.

Kawahara: Photon Server is currently used for object management in battles only. We are considering whether it is possible to implement “watching mode,” which consists of watching how strong players are battling. In addition, Photon Server may be used to see the timing of substituting a pitcher and if pinch hitters are used.

Thank you very much for  your time for us today.

Customer Profiles

Mr. Tsukasa Oikawa, Producer Second Production Third Unit, Production Division, NE Business Department BANDAI NAMCO Entertainment Inc.

Mr. Keigo Ikeda, System Director Second Production First Unit, Production Division, NE Business Department BANDAI NAMCO Entertainment Inc.

Mr. Shintaro Kawahara, System Director Assistant Manager, First System Unit, Marketing DV System Division, NE Business Department BANDAI NAMCO Entertainment Inc.

About “Famista Dream Match”

The latest edition of the pioneer baseball game “Famista.” The characters of BANDAI NAMCO Entertainment join the game as “NAMCO Stars.” Enjoy playing baseball battles against online opponents in real-time.

Version 4.0.5.0 of the Photon C++ Client SDKs has just gone live.

Here is a short list of the most important changes since 4.0.4.0 (for the full list please have a look at the release history files, like always):

• we now offer a Client SDK for Apple tvOS
• the Windows Client SDK now supports Visual Studio 2015 (also this will be the last major update that still supports VS2010)
• the Marmalade Client SDK now support AndroidNativeDebug builds
• we now support IPv6

Get the new SDKs here.

We are looking forward to meet you in San Francisco at GDC, Game Connection or for a Photon Workshop.

Please see our availability and book a slot.

Here’s where you can find us during the week:

GDC Expo:

Issue Summary

On 03/01/2016 from 3:39 PM to 4:04 PM CET Photon’s name servers were denying service. Users were not able to connect to Photon public and enterprise cloud services. All services (Realtime, Turnbased, Chat) in all regions were affected. Users who were already connected to Photon services did not experience a disruption. The root cause of the outage was the deployment of a wrong package to the name servers.

Timeline (CET)

3:39 PM Deployment of wrong package starts
3:40 PM Service outage on first regions
3:44 PM Deployment to all name servers finished
3:44 PM Name server outage on all regions
3:47 PM Alerts from monitoring tools
3:48 PM Start of investigation
4:00 PM Deployment of correct package
4:04 PM All name servers on all regions running correctly again
4:20 PM CCU numbers for all services back to normal

Root Cause

At 3:39 PM a configuration update was meant to be been released to the Photon production name servers. During a manual step the wrong configuration has accidentally been pushed to the name servers.  This caused the name servers to deny incoming requests and to return error messages to clients. Therefore clients have not been routed to Photon cloud services and were not able to join lobbies.

Resolution and Recovery

At 3:47 PM our monitoring systems started alerting. Also first customers reported issues. After a quick investigation our engineers identified the wrong configuration of the name servers. By 4:00 PM we started rolling out the correct package. At 4:04 PM name servers for all regions were running correctly and all Photon cloud services started to recover. By 4:20 PM CCU numbers of Photon services were back to normal.

Corrective and Preventative Measures

This guest post was written by Raúl Pérez Bernabé, Lead Unity developer at From The Bench.
From The Bench is one of the biggest sports games development companies in the world, with the biggest official franchise of football clubs including Real Madrid, Chelsea, AC Milan, Borussia Dortmund  and with an official license of the NBA.
So if you feel like playing with your favourite soccer stars: From the Bench’s games are available on iOS & Android with ‘Flip Football’ being their first game with synchronous turn-based multiplayer. Flip Football is a strategy card game where you can build your card deck with the world’s most famous players such as Ronaldo or Ibrahimovic and compete against real opponents from all over the world.
In this post, Raúl shares some bits of how they set up their Photon multiplayer environment including friends matches via Facebook friends.

About the game

In Flip Football we have a 3×4 board where two players place their cards turn-by-turn. Each card represents licensed real life football stars that each have four power values. When you place a card with greater power than its adjacent card, it gets flipped and you score a point. The game ends once the board is filled with cards and the player with the highest score at the end of the game wins.

Real time PvP. Are you sure?

That is what we asked ourselves when we first came up with the game concept. We’ve been developing manager games for several years now, but Flip Football is our first game with synchronous real-time matches. In our games we have in-house managing of the full stack, but since we are not very experienced with this kind of technology we decided that an external cloud should be the best way to get started.

It’s a turn based game, it can’t be that hard, right?

A quick look at Photon’s turn based tutorial [https://doc.photonengine.com/en/turnbased/current/getting-started/turnbased-intro] will give you almost everything you need. Let’s get to how we are doing things.

Flip Football is a 1vs1 game, so we set up a room for each match.

public void CreateTurnbasedRoom(){
        string newRoomName = this.NickName + "-" +Random.Range(0,1000).ToString("D4");  
        ExitGames.Client.Photon.LoadBalancing.RoomOptions newRoomOptions = new ExitGames.Client.Photon.LoadBalancing.RoomOptions();

        newRoomOptions.IsOpen = true;
        newRoomOptions.IsVisible = true;
        newRoomOptions.MaxPlayers = NetworkManager.MaxPlayers;
        newRoomOptions.CleanupCacheOnLeave = true;
        newRoomOptions.EmptyRoomTtl = 1;
        newRoomOptions.PlayerTtl = 15000;

        // C0 holds the user league, this is for matchmaking
        newRoomOptions.CustomRoomProperties = new ExitGames.Client.Photon.Hashtable() { { "C0", User.league } };
        newRoomOptions.CustomRoomPropertiesForLobby = new string[] { "C0" };
        // this makes "C0" available in the lobby

        // let's create this room in SqlLobby "myLobby" explicitly
        ExitGames.Client.Photon.LoadBalancing.TypedLobby sqlLobby = new ExitGames.Client.Photon.LoadBalancing.TypedLobby("myLobby",
        ExitGames.Client.Photon.LoadBalancing.LobbyType.SqlLobby);
        OpCreateRoom(newRoomName, newRoomOptions, sqlLobby);

    }

Once the room is set up we just need to wait for another player to join it. We have a “Looking for an opponent” screen that just waits for someone to join the room we have created.

Matchmaking

Our game is based on playing matches vs other players and we wanted it to be as simple for the user as pressing the “Play” button. When pressing the button the system will look for an opponent that is similar to him.

Our matchmaking will try and pair two players on the same division, and if it can’t find a good match, it will try again with more permissive constraints.

For example, if a user is on division 5, we want him to play against another user on division 5, if this fails to happen, we want to match him with players on divisions 6 to 4.

This is how we are doing it:

public void JoinRandomRoom(bool secondTry = false){
      string sqlLobbyFilter = "C0 = " + User.league;
      if(secondTry){
            sqlLobbyFilter = "C0 = " + User.league  + " OR (" + "C0 <= " + (User.league + Config.matchMakingDivision).ToString() +
            " AND " + "C0 >= " + (User.league - Config.matchMakingDivision).ToString() + " )";
      }

      ExitGames.Client.Photon.LoadBalancing.TypedLobby sqlLobby = new ExitGames.Client.Photon.LoadBalancing.TypedLobby("myLobby",
      ExitGames.Client.Photon.LoadBalancing.LobbyType.SqlLobby);
      this.OpJoinRandomRoom(null, 2, ExitGames.Client.Photon.LoadBalancing.MatchmakingMode.FillRoom, sqlLobby, sqlLobbyFilter);
 
}

Now that rooms are set up and players have joined them we can actually start playing the game.

Event Handling

When a card is played we just need to tell the other client which card and where it was played. We do this with OpRaiseEvent() and the other player listens with OnEvent(). Note that we don’t have any random elements in Flip Football so both clients will end up with the same state after the event is sent and received.

public void SendCardPlayedEv(Card card, Cell cell){
   	 Hashtable content = new Hashtable();
   	 content[(byte)1] = card.getCardData().Id;
   	 content[(byte)2] = cell.i;
   	 content[(byte)3] = cell.j;
   	 this.loadBalancingPeer.OpRaiseEvent(EvCardPlayed, content, true, null);
    }

You may have noticed we didn’t do anything fancy, we simply didn’t feel the need to. I would like to mention that we did implement a Facade pattern around Photon so that it is a lot simpler to do Photon related operations and change its behaviour without other classes noticing.

Friend vs Friend matches.

This kind of logic is not built into Photon, but you can come up with several solutions easily. We do this with Facebook and native iOS/Android push notifications. Let’s explain how.

We use the official Facebook Plugin from the asset store to get our friends and their info:

public static void GetFriends (){
   	 if(FB.IsLoggedIn){
   		 string queryString = "/me/friends?fields=id,name,picture.width(128).height(128)&limit=100";
   		 FB.API(queryString, HttpMethod.GET, GetFriendsCallback);
   	 }
}

Now we need to find out if our friends are online, we use Photon for that:

public bool GetFriendsFacebook(string[] friendArray){
   	 return this.OpFindFriends(friendArray);
    }

When we receive the OperationCode.FindFriends event we populate our FriendList and call GetFriendsInfo to update each friend’s in-game status.

public void GetFriendsInfo(){
   	 if(this.FriendList != null){
   		 List<ExitGames.Client.Photon.LoadBalancing.FriendInfo> friendInfoList = this.FriendList;
   		 int status = 0;
   		 foreach(ExitGames.Client.Photon.LoadBalancing.FriendInfo friend in friendInfoList){
   	       	if(friend.IsOnline){
   				 status = 1;
   				 if(friend.IsInRoom && friend.Room != "" && friend.Room != null){
   					 status = 2;
   				 }else{
   					 if(friend.IsInRoom){
   						 status = 2;
   					 }
   				 }
   			 }else{
   				 status = 0;
   			 }
   			 FacebookFacade.SetFriendStatus(friend.Name,status);
   		 }
   	 }
    }

Now we have all our friends and their info, clients can now challenge their friends.

When a client wants to challenge a friend to a match, we create a room named [my_facebook_id]-[friend_facebook_id] and send a push notification to my friend. When my friend gets the alert and accepts, he knows that the room should be created (and also knows which friend sent him the request, so he knows how the room should be named) and tries to join it. When both players are in the room we load the game scene and the game starts.

That’s it.

All of this might seem obvious to experienced developers but if you are starting out full of doubts I hope it can help you, it certainly would have helped me.

If you have any questions or feedback feel free to contact me on twitter: @ruloii or by e-mail raul.perez@fromthebenchgames.com

Photon Unity Networking PLUS (PUN+) is 47% off during Unity’s Asset Store Madness Sale.

PUN+ includes:
> No Unity Pro needed: Export to all platforms, including iOS & Android with the free Unity personal edition.
> Pay once, use for 60 months: 100 concurrent user Photon Cloud plan. Stackable to all Photon Realtime plans, once per application.
> Global Cloud: Choose from hosting centers in US, Europe, Japan, Singapore & Australia.

Get it now for US$ 95 (regular) US$ 50 during Unity’s Madness Sale.

You already own PUN+? In case you want to buy another PUN+ package please create a new Unity Asset Store account for the purchase.

Take me to PUN+ Madness Sale >>

Lots of discussions with customers about the difference between Photon Realtime and Turnbased combined with different market definitions about synchronous and asynchronous games led to the decision to merge Photon Turnbased into Photon Realtime.

Therefore we discontinue Photon Turnbased on May 25th, 2016, as a standalone product and move all existing Turnbased apps to Photon Realtime. So do not worry if you cannot find your Photon Turnbased dashboard anymore: all your Turnbased apps have found their safe harbour in Photon Realtime and you can find them in the Realtime dashboard from now on.

Of course Photon Realtime will inherit the specific Turnbased features like Webhooks and WebRPC.

All running subscriptions for Photon Turnbased apps are seamlessly continued and there is no action required from your side. If you cancel your subscription and want to re-subscribe later or if you want to upgrade your monthly CCU, you can do so by choosing a Photon Realtime plan.

We are often being asked why our subscription plans for Photon Cloud products (Realtime, PUN, Chat, Voice) are based on concurrent users (=CCU) and our answer is always the same:
because we strongly believe that it is the most transparent and fairest model for our customers.

Read the following why we think so and see a comparison with some competitors.

The Logic Behind Photon’s Pricing

Click to Enlarge

The most important thing when we planned Photon’s pricing was to make it as affordable as possible for everyone. We always loved how Unity democratized game development and we wanted to do the same by empowering everyone to create and launch stunning multiplayer experiences on a global scale.
Therefore we also needed a predictable and worry free pricing. We knew that CCU and data traffic are mainly driving our costs, so we used that as a start. We quickly found, that calculating data traffic for a game is pretty hard. Even in case you have launched a similar game before, your new game can vary a lot in terms of data traffic. On the other hand data traffic is a huge cost driver. Our solution was to include a 500 message limit per room in our price model. We knew that this limit is not compromising creating great games, but it simply prevents that some developers are over-exploiting our service by sending too much unnecessary data which would harm everyone in the end as we would need to raise our pricing then. In order to make that as transparent as possible we introduced a calculating tool on our website which shows how many messages are sent around (see pictured to the right).

We also knew that no one really knows how many CCU he can expect before a game is launched. Therefore we decided against charging purely on a per CCU basis and went with

Photon Plans – Click to Enlarge.

4 subscription plans: free, 100 CCU, 500 CCU & 1,000 CCU. This serves two purposes: a) you know exactly what your monthly bill is going to be and b) we can better plan our server capacities.

If you have a Photon 500 CCU plan,  you want us to deliver 500 CCU. Therefore we need to make sure we have enough servers to handle your peak CCUs. We can’t simply switch servers on/off as we host on top-notch IBM SoftLayer bare-metal servers that include an excellent pricing for data traffic. Please note that data traffic pricing in clouds like Amazon AWS or MS Azure is so much more expensive and we would need to charge our customers a multiple of our current fees just because of traffic costs. Not an option.

However, we are giving most of those free resources back to our customers with Photon’s CCU burst feature. CCU burst is activated by default for all plans with 500 CCU or more and allows your game to exceed your CCU limit without being charged anything. That means you do not have to worry a) that you have to pay more than you have calculated and b) that your game is getting blocked and users are cut out of service. Of course you can always upgrade your Photon CCU plan or downgrade it.

Some indies do worry about reaching high CCU numbers as they are afraid that they cannot pay us then and would need to stick to a lower CCU plan. Please note, that if you are >500 CCU it means that your game is a success with about 200k MAU. You will earn enough to pay us. If not – please be assured this has happened not a single time until today – get in touch with us and we’ll find a way. We have zero interest in cutting our customers success.  So in case you want to launch your game with Photon for the first time we recommend to go with the Photon 500 CCU plan with the CCU burst. It costs you US$95 only and provides you game hosting spread all over the world in Photon Cloud.

MAU, DAU and Bandwidth – Intransparent & Hard to Calculate

Pricing plans based on MAU, DAU or messages sent/received by games are tricky. MAU simply means how many unique users played your game in a 30 days period (see Wikipedia). It does not count how often the user has played your game. MAU (or DAU)  as a pricing basis would mean you need to pay the same amount for a user whether the user has played dozens times a day or if he quit playing your game after a few seconds. This is nearly impossible to predict and more important, it does not really relate to the actual costs that are generated by a user. The actual costs are related to the CCU, means when users are actually online, and the generated traffic.

A look at competition: Amazon GameLift & Unity Multiplayer

Amazon GameLift pricing example. Click to enlarge.

Looking at Amazon GameLift’s pricing is pretty challenging. There are a lot of (unknown before game launch) factors you need to take into calculation in order to find out what you’ll pay in the end. Their pricing is calculated based on DAU, bandwidth usage, CCU and the kind of Amazon EC2 instance you need … only 28 different to choose from

On their website is a pricing example for a first person shooter (click on the picture to the right to see it in detail). There is quite a complex example calculation that results in total monthly costs of US$5,853.43 for 10,000 DAU and 1,000 CCU without and US$3,396.44 with GameLift’s Auto-Scale function.

We doubt that anyone can calculate a proper price without having such an example, but even with that example I think it is extremely hard to find out what you really have to pay in the end. So how far these numbers are applicable to your game is very hard to guess.

Calculating the costs with Unity Multiplayer looks much easier than with Amazon: US$0,49 per GB and an easy to use calculator on their website that shows how the GB price relates to more

Unity Multiplayer Pricing – Click to enlarge.

predictable terms like CCU and MAU. So, how much is it then for 1,000 CCU? Unity’s advanced calculator says something between US$599.64 (in case you know your game’s expected average utilization and message size correctly) and US$2,398.57.

First thing that strikes me is Unity’s US$0.49 per GB compared to Amazon’s US$0.09 per GB. That is a lot more. Second thing is the size per message. Default value in Unity’s calculator is 160 bytes per message (appr. 1,6kb/s assuming 10 messages per second) compared to 75kb/s at Amazon’s example. A huge difference. Filling in the 75kb/s in Unity’s website would result in minimum costs of US$23,026.23 for Unity’s Relay service for 1,000 CCU with 10 msg/s at an utilization of 25%.

We do not want to comment if the one or other value is correct. All we can say is that these numbers are pretty game specific and there is e.g. not the one single FPS example that works for all FPS games. You need to intensively test to find out the right values for your game, but the real numbers can only be found after game launch. As there is no build in limit as with Photon’s plans you can end up with an amount you have absolutely not expected, e.g. because the actually used bandwidth is much higher than calculated before launch.

In comparision to that, calculation with Photon multiplayer products goes like this: 1,000 CCU = US$ 185. Done. There is nothing to worry: there are no traffic costs and no average utilization or DAU or game server instances or anything which potentially lets your monthly bill explode.

That’s why we think we have the fairest and most transparent pricing on the market.

Dear Photon Developer,

On our mission to make multiplayer simple, we added additional regions to our
Photon Cloud, invite you to apply for Photon TrueSync early access and explain
why we think that our CCU based pricing is part of that mission.

Read on, be aware of Exploding Kittens or meet and discuss with us at Casual
Connect USA next week…

New Photon Cloud Regions for Everyone

Ping! We once decided to offer all Photon Cloud regions for the same price and
as a result it took us way longer than expected to find a hosting partner for South
America that fits to our requirements. Gladly we worked out a solution together
with our preferred partner IBM Softlayer and ramped up servers in São Paulo,
Brasil, to setup a new Photon Cloud region ‘South America’.
Travelling the US coast to coast and up north to Canada is not only a huge
distance for sight-seeing tourists, but also for data packets sent around by
Photon powered games. So we setup a second US region therefore, US West,
served via our new hosting center in San José, California and region ‘Canada
East’ which is hosted in Montreal.
Find all three regions now available in all Photon plans at no additional costs.

Learn more about Photon Cloud regions  >>

Photon Cloud Hosting Center in China Mainland for
Selected Customers

We have many customers who want to publish their games in China, but so far
they needed to use Photon Server and find a Chinese company for hosting. Not
really the easiest way to enter the Chinese market, but at least an option.
Now we are taking the next step with the support of a Chinese partner who helps
us ramping up servers in the Guang Dong area to host Photon Cloud apps for our
Enterprise clients and selected customers.
If you have a bigger Photon Cloud project you want to launch in China and expect
3,000+ concurrent users, please click the link below and email us.

I need hosting in China Mainland  >> 

Why We are Convinced that Our Pricing is the Fairest

We are often being asked why our subscription plans for Photon Cloud products
(Realtime, PUN, Chat, Voice) are based on concurrent users (=CCU) and our
answer is always the same: because we strongly believe that it is the most
transparent and fairest model for our customers.
Read in our blog, why we think so and how Amazon’s GameLift or Unity
Multiplayer compare.

Read about Photon’s pricing >>

Exploding Kittens –
The Most-backed Kickstarter Project ofAll Times

Exploding Kittens became famous as the most-backed game in Kickstarter
history and the campaign with the highest number of backers. It is a highly-
strategic, kitty-powered version of Russian Roulette presented as a card game.
Players draw cards and when someone draws an Exploding Kitten, well, they
explode and are dead – unless that player can defuse the kitten using a defuse
card featuring things like laser pointers, belly rubs, and catnip sandwiches.
The game app was developed by Substantial for iOS and Android and instantly
climbed the #1 in the iOS paid apps charts. It features local and Photon powered
online multiplayer for up-to 5 players.

Check out Exploding Kittens >>

Early Access Photon TrueSync –
Keeps All Your Players in Sync

Photon TrueSync is aiming to become the easiest solution to deliver an out-of-
the-box synchronization across Unity game clients. TrueSync is based on a
synchronous lockstep architecture with its own physics engine to keep a
deterministic game state for Photon Unity Networking (PUN) multiplayer
games. It features user input prediction and a rollback engine to easily hide
latency or for automatic replay support. Sure, all PUN features are supported
plus some nice debugging features.
Out-of-the-box synchronization for multiplayer games is, well, a little like
squaring a circle, but we think we are on the right track. What we need now is
your feedback when using TrueSync for your project. Interested in getting early
access to TrueSync?

Apply for TrueSync early access  >> 

Let’s meet: Casual Connect USA –
18-20 July 2016 in San Francisco

Tom is attending the Casual Connect show next week and he invites you to drop
by the SoftLayer booth #103 to meet for a chat.

Send a “Let’s meet” email to Tom >>

What started slowly has become a true success story for us: Photon Chat. It took a while, but now we have several apps with 10,000 CCUs and beyond. Not too bad.
Photon Chat runs on a completely different architecture compared to Photon’s multiplayer products Realtime, PUN and Thunder. So our first goal was to make it super-reliable and then to add an affordable chat filter. Doublecheck. However, we knew that one feature was missing and that it was on many customers wish-list: Webhooks. Well, the feature is rather to create e.g. chat persistency, but this and more is exactly what you can do by using webhooks: persist channel history, filter messages, cancel channel creation and even prohibit certain players from subscribing to chat rooms.

Gimme Early Access to Chat Webhooks >>

Photon is well known for its multiplayer features, but Thunder is a little different. Based on the proven and battle-tested Photon Cloud, Thunder is the perfect punch-through, relay and matchmaking service for games developed with the new Unity Multiplayer (HLAPI).
Unity Multiplayer, but with Photon? Yes, exactly. While Unity Multiplayer’s peer-2-peer networking is included in all their plans, it offers no punch-trough service and their Matchmaker and Relay servers cost a hefty $0.49 per GB.
This is where Photon Thunder steps in:
it offers the missing punch-through feature, all the great matchmaking features of PUN and, being fully based on the Photon Cloud, a proven scalable and reliable global cloud relay.
All offered at a fraction of the costs of competition: Photon Thunder plans will include 3GB per CCU (roughly $0.062 per GB only) and as always you’ll get 20 CCU completly FREE.
So if you like Unity’s peer-2-peer engine, but do not want to pay the high costs for their Relay and Matchmaker: Photon Thunder is the right product for you.
We are aiming to release Thunder before November and invite everyone to apply for Early Access now.

I want Photon Thunder Early Access >>

Notable changes since 4.1.3.3:

• added Client::reconnectAndRejoin() to the LoadBalancing-cpp library,
  which you can call when your client loses its connection while it is
  inside an active game to make it reconnect and rejoin that game. This
  allows for a quick rejoin of the active game even when the server has not
  yet detected the disconnect
• switched the used C++ standard library of the Photon Client SDK for
  Android NDK from c++_static (Clang/LLVM libc++), to which it recently has
  been changed, back to gnustl_static (GNU STL) to re-establish
  compatibility with Cocos2d-x and Unreal Engine 4, which got broken in
  4.1.3.1

REPLACED: 4.1.3.2 SDKs for Emscripten, Linux, Windows and WindowsStore and
4.1.3.3 SDKs for Android NDK, iOS, OS X, tvOS with 4.1.3.4 ones

Download the SDKs from https://www.photonengine.com/en-US/Realtime/Download.

Notable changes since 4.1.3.4:

general changes:

• added: XBox 1 as new supported platform
• added: overloads of PhotonPeer::connect() with new optional parameters to supply custom init data to the server
• added: PhotonPeer::initUserDataEncryption()
• added: PhotonPeer::initUDPEncryption() (available on XBox 1, Windows
  Store 10 UWP and Windows Desktop)
• added: support for changing the connection protocol without recreating
  the Peer instance
• added: support for Websocket connections on Xbox 1 and Windows Store

changes to the LoadBalancing Client (Photon Realtime and Photon Server):

• added: support for Webflags, https://doc.photonengine.com/en-us/realtime/current/reference/webhooks-v1-2
• added: support for a XBox 1 encryption and authentication flow that conforms to Microsofts requirements for that platform
• fixed: MutableRoom::getPlayers() did not work correctly for joining
  players, if remote players have not had any player properties set (the
  player name is a player property, so this did not affect most games)
• added: support for expected room properties (check and swap): when using
  this, changing properties fails if any property value prior to the changes
  is not equal to its expected value. This is useful to prevent one client
  from overriding the changes that have been done by another client when
  multiple clients attempt to change the value of the same property at the
  same time.

Download the SDKs from https://www.photonengine.com/en-US/Realtime/Download.

changes to the Chat Client:

• fixed: Client::opSetOnlineStatus() now can actually be used with just
  the ‘status’ parameter without providing a status message
• removed: the skipMessage parameter from Client::opSetOnlineStatus()
  (just don’t provide a message parameter to skip the message)

Download the SDKs from https://www.photonengine.com/en-US/Chat/Download.