If you are creating multiplayer games with Unity, this is for you: We released a new version of the Photon SDK and got several new features into it.
Bigger chunks of data are supported by fragmentation and channels. You can attach properties to games and players now, which makes it easier to store temporary data for players that join a running game. This is available as C# source and can be modified at will.
Also new is the “Photon Control”: a small tray menu for starting and stopping Photon, managing the service and performance counters.
The server is still Windows only but the client SDK is Unity (Win, Mac, Browser) and Unity iPhone compatible.
Anyone who wants to get an impression is invited to get the new Server SDK with new trial license:
Nekharoth: Yes, fragmentation is completely handled for you. Of course, you should still take care how much and how often you send something to avoid congestion and delays. We don’t currently try to solve that.
We are currently working on support for float and double. These types were left out when we first implemented everything on J2ME.
Is anyone here using Photon for a Unity backend? I’m seriously considering getting a license for my project as it seems like a really good option, but I’d like to see more sample code than you get in the trial before actually committing.
I’m thinking of integrating nVIDIA PhysX with a C# wrapper to provide server side heightfield/basic mesh collisions. Has this been done before? And is this even possible?
I’ve totally got my head around Unity’s built-in networking, but this looks a bit more challenging to get up and running…
Yeah, it’s definitley possible, to use Photon together with a Physics engine for tasks like server side collision detection.
One possible approach would be, to run PhysicX on the server and on the clients and just send data like position coordinates, speed, rotation, etc. of a player via Photon, so the clients can update accordingly. Movements between the time of two network updates would be calculated by PhysicX on the client side and remote clients with the help of techniques like convergence for calculating movements of remote players. This way, you have not to send position updates every frame, but only in intervals and in situations, when the movements vectors of a player suddenly change. So, all clients and the server only have as little differences in position informations as possible. The server would be the authority for decisions like if a projectile hit a player or not, while the differences on every clients should be small enough to not see an optical difference.
Actually I know of at least one game, currently in development, using such an approach with a physics engine and photon.
Any chance for a pointer on where to find documentation on the properties feature and channels in the Unity v5.4 package or the 1.6 photon server package?
For client and server usage?
The only thing I found was in the client documentation, Appendix F but that talks of Neutronxxxx class constants and methods, not Photon.
The client does not use it in any way, just a dummy callbacks.
The server would have the opcode handling.
but nothing really about channels and the NPeerEventCodes aren’t documented as well (leave and join are spread all over the place only) and require a check of Operations/Enums.cs to find more out about them.
Generally I would love to see a bit more documentation above the “read the source and try to understand” level for some of the great features present that are used by LiteGame and classes it uses for example.
dreamora: You are right, we could use more documentation. Getting into the server code could be a bit harsh. We still need to find the middle ground with enough documentation that is still completely readable. In the mean time: keep asking here or write to developer@exitgames.com.
About channels:
They are really simple and just organize your sent events into independent sequences. The short description for the client-side is under the “Photon” chapter in 4.1.1.
If something reliable in one channel gets temporarily lost this one channel will wait for the lost event. With more channels, others channels might still be received and dispatched independently.
An example: Lets says you send movement updates and reliable shots in channel 0 and want chat to be reliable too. chat does not rely on where you are or when you shoot, still it’s reliable and when it must be repeated, this means everything in it’s channel is executed later on. You could now place chat in channel 1, which is only having reliable events now and is strictly ordered. If a shot is missing, channel 0 is still having a hicckup.
If this helps, I will put it in the next doc version.
About properties:
At the moment they are very basic and will be extended soon. The short description is in 4.1.2.
An example: A game is available for anyone to join, but the players will somehow vote on the next map. When someone joins, he wants to know the map to load it. You have two options here: either modify the OpJoin server side and send the map ID as return-value. Properties give you the option to have someone set the map ID as Room / Game property. If this is well known for all clients, they can ask for this property (and others) after they joined.
Admittedly, at the moment player properties are not so useful. You would have to fetch them separately for every player.
But: You have the code! Go ahead and modify the result of OpGetProperties and make it return the properties of each player in the room. Maybe make it optional: send actornumber 0 (actornumbers start with 1, so this is never used by a player) and only then return ANY players properties.
It’s all in C# and should be easy
Sorry for the long post. I’ll move it to the doc in one form or another. We try to add more small samples which focus on distinct parts of the featureset. It’s still very much growing.
I have to correct myself: the documentation should have been where I pointed, but it wasn’t. I just uploaded an updated Unity SDK 5.4.1 with (short) additional documentation.
