Third Party Photon Unity Networking

@tobiass
Do you have a dead line for the version 1 of PUN or you will continue to support it?
2 of my games use it again the version 1, so it will be cool to know
Thank you.

 

PUN Classic is practically at the end of it's lifetime. Don't start projects with it anymore.

 

I know but how much time your server will continue to handle V1 and V2? Do you have planned to stop supporting the V1 at one time or we are safe to stay in V1 for the next year?
(Server side)

 

Yes, the Photon Cloud is not going to become incompatible anytime soon. We make sure existing games stay up.

 

Hello, I am interested in the PUN plus edition version, I have a question and I would like to clarify it.
According to the version it supports 100 simultaneous clients, my game is based on rooms with 10 players (MOBA type), does this mean that there could only be 10 rooms with 10 players? Or does it refer to a maximum of 100 clients per room? thanks

 

It's 100 clients for the game, across all rooms.

 

Thanks, I see it very expensive, for my project that is focused on thousands of users it would be very expensive since it is a free game that only receives benefits for cosmetics ...
In other words, if you have a moba game that connects an average of 5000 users in different rooms, you would pay 185 * 5 = 925$ monthly.
I'll have to think about running my own system ...

 

I have a mobile game that has around 200 daily active users and each month it makes around double the hosting cost you worked out for 5000 CCU.

I doubt I get much more than 10 CCU, so if it had enough players to reach 5000 CCU the income from it would be an amount that I can only dream of and would likely cover the monthly hosting cost of that amount of CCU with less than a single day's income.

Honestly, if you can attain 5000 CCU, you really don't need to worry about the level of hosting costs you mentioned, unless you seriously screw up your monetization strategy.

 

For the Photon Cloud, you pay per max CCU each month. We think it's a fair pricing if you consider we are running machines to host the maximum of your users but it is hard to guesstimate the kind of success you need for any given CCU value. Your daily active users don't play 24h, after all.
As Munchy wrote, even 200 daily active users are mere 20 CCU max, normally.
To reach 5k CCUs, your game needs significant success. When that's the case, you will worry about your community, gameplay and you will be happy if you don't have to think about hosting centers, restarting and adding machines.

 

We just released a new version of PUN 2. This has lots of fixes on all levels but also paves the way for non-alloc sending of operations (like RaiseEvent, which is also used internally). The next release will probably be done from Unity 2018.4.x.

v2.23 (17. November 2020)
Changed: CustomTypes are now split into CustomTypes and CustomTypesUnity. The latter is part of the Realtime API and registers automatically for Unity projects (in LoadBalancingClient constructor). This only changes internals for PUN. The Player class is only a de/serializable type in PUN.
Changed: DebugLog info in case an RPC was not found. Making it clear that RPCs should return null or an IEnumerator (if you enable RunRpcCoroutines).
Changed: Creation of the locally used EventData instance. The Parameters are now readonly and non-null.
Updated: Registration wizard to avoid multiple registration calls.
Fixed: Callback registration updates when the owner changes.
Changed: PhotonServerSettings label for Appid of PUN. Was labelled as "Realtime" but there is a "PUN" type of appids which should be used.
Changed: Various places in PUN to re-use boxed bytes (instead of causing boxing in those places).
Added: Handing for compile defines PUN_DISPATCH_IN_FIXEDUPDATE and PUN_DISPATCH_IN_LATEUPDATE. It locks Dispatch calls to the respective monobehaviour methods (and timing). Use one or the other.
Changed: Depending on PhotonNetwork.MinimalTimeScaleToDispatchInFixedUpdate and the Time.timeScale, PUN will dispatch incoming messages in FixedUpdate or in LateUpdate. Before it potentially was running in both MonoBehaviour callbacks.
Changed: Description of PhotonNetwork.MinimalTimeScaleToDispatchInFixedUpdate to reflect and explain the change above.
Changed: Loading and creation of the PhotonServerSettings file. We got several reports of errors with this but could not properly reproduce them. Several safeguards were added and in worst case, you might end up with two PhotonServerSettings files (if you had an old one).
Added: BestRegion now checks if the operation GetRegions was successful. If it returned an error, it skips pinging (and the client will get disconnected anyways).
Updated: The Realtime API and Photon3Unity3d.dll (v4.1.4.6) with lots of improvements and changes. Check the respective changelogs.

 

It's not been long since the last release but we already have a few updates to share in PUN 2.

Most importantly, there is a fix for WebSocket connections via the .Net Standard 2.0 dll. It failed to read messages larger than the (UDP based) MTU size. The result was some deserialization error, cause the data wasn't complete.
There is also a change that seems to improve the connection handling a lot when joining rooms which are busy or have a lot of properties already.
Also, we added an option to the PhotonTransformView to either send local or word data, when syncing the transform. This was a common issue in upgrades from older PUN versions (which used world data).

Overall, a small update compared to 2.23, so you should get it.

v2.24 (26. November 2020)
Added: PhotonTransformView.UseLocal. It defaults to true for any new PhotonTransformView but allows to get the "old" behaviour with world position and rotation data being synced.
Fixed: Inspector UI for PhotonTransformView and PhotonAnimatorView. Warning box for using triggers broke horizonal bounds, causing horizontal scrollbars on inspector. Switched to standard helpbox.
Changed: Drastically lowered the MaxDatagrams value, to not send too much in one frame.
Changed: Default sendFrequency to 33ms. PUN will send in more frames but less datagrams in each.
Changed: SendRate does not affect the SerializationRate value anymore. Also, SerializationRate can be set independent from the SendRate.
Updated: Documentation about SerializationRate and SendRate. This now explains more details about sending.
Realtime API:
Fixed: It was possible to trigger multiple calls of Authenticate by calling ConnectToRegionMaster(region) multiple times while being connected to the Name Server.
Changed: AuthenticationValues.ToString() to expose less data while showing which values are set.
Photon dll v4.1.4.7:
Fixed: PhotonClientWebSocket handling of messages > MTU. Incoming messages may be incomplete and are now reassembled. Before the fix, common result was that deserialization failed with incorrect / incomplete data.
Added: ExitGames.Client.Photon.Hashtable Add() and Remove() for byte keys. This makes sure ht.Add(0, obj) and ht.Remove(0) match how the access via ht[0] works.

 

I am happy to announce the release of Simple Network Sync for Photon (a.k.a. Simple).

Simple extends PUN2 to operate on a simulation-based tick timing system that uses circular buffers. In other words: With Simple you can get the best synchronization for characters in PUN 2, even when they jump on a moving platform. You can define syncvars in scripts and along with both comes a host of PhotonUtilities, which provide BitPacking for very efficient transfer of variables.

The Simple Docs are up already and pretty much all components should link to these. Have a look at the Simple tutorial to get a taste of what's possible.

Thanks to Davin (Emotitron on the Photon Discord) for wrapping this up.

Get PUN 2.25 with the Simple components in the Asset Store.

 

Hi, thanks for the ByteArraySlice, I really needed that.

However, when you mention: "Events that contain just a byte[] can now be sent and received with almost zero allocations.", well the profiler still reports allocation of 1.1kb everytime I receive an Event, caused by EventData contructor called in Protocol18.DeserializeEventData():



Would there be a way to avoid that allocation as well?

Thanks!

 

There is a separate "reuse event" option. This eliminates the constructor (but once).
Set PhotonPeer.ReuseEventInstance = true.

Aside from that: We can't avoid allocations entirely, to be honest. But we pool the memory that was being used.
In best case, you did all the correct settings and this is just the warm up phase. Does this still happen after a while?

 

Thanks @tobiass , I didn't know about ReuseEventInstance!! After settin it to true, it's now 0 byte!

 

There was one oversight in the 2.25 package, which caused issues on import with numerous compile errors.
A new PUN 2.25.1 package is now in the store and fixes the issue.

 

Hello,

I'm preparing for v2 transition, juste readed about Simple. I'm a bit confused wethere its the future or not. I mean, shall I at least try to make it run instead of the "default" transform views?. Or this is something very specific for certain type of users?

 

Simple is a new, better way to sync positions, movement and other values. It usually achieves really nice quality, so I would give it a try unless you already built your own TransformViews and are happy. Also, it saves some bandwidth for the syncing and keeps SyncVars updated.

 

We worked on a few smaller improvements and fixes for PUN 2 and were eager to get them out, so .. there is v2.26 in the Asset Store now. It's really a small service update from 2.25...

v2.26 (09. December)
Fixed: Possible IndexOutOfRangeException causing import issues when cached best region summary is not in expected format.
Changed: Wizard will load Realtime AppId from settings, if present. This should avoid surplus registrations.
Changed: PhotonEditor will not call RegisterByEmail, if a request is pending some result. For that, the serviceClient is now a class variable and not a local one.
Added: Extra check to avoid sending useless (empty array payload) OwnershipUpdate event.
Updated: The Realtime API and Photon3Unity3d.dll (v4.1.4.8) with smaller improvements and changes. Check the respective changelogs.

Two notable changes are part of the library update:
Fixed: Issue with DisconnectTimeout, which could be set to int.MaxValue and force a timeout.
Internal: PeerBase.PepareWebSocketUrl to skip the appid when RemoveAppIdFromWebSocketPath is true. Changed order of parameters.

Some changes are included for the Simple networking components. We will add a changelog in the next releases.

 

Hello, I'm trying to check if photon is offline or online to path code properly.

I used to rely on "PhotonNetwork.OfflineMode" but on game launch without connecting and directly going to offline gameplay modes I get OfflineMode as False, where in PhotonV1 I used to have no issues at all with this.

I don´t mind to change this to whatever is better but I could not found a way to check if its connected or not since checking connection state like "PhotonNetwork.NetworkClientState" can return a lot of stuff and by default I'm not getting Disconnected but "PeerCreated".

EDIT:
!PhotonNetwork.IsConnected
Seems to do the job, but the //summary of this method is extremelly confusing to me

 

PUN 2 is neither in OfflineMode nor connected, when you just run your code but did not call Connect*() yet.
This is to be expected, actually.
If the client is not in offline mode and IsConnected is false, nothing happened yet.

 

Hello.

I don´t know how to handle hte following situation:

I've a tank game, there is a harbour map, there are a number of non static containers that tanks can push. As it is now theese are not synced anyhow, resulting in mismatched container positions that would cause issues in gameplay, as you can see in the shot.


As said most of the time theese are static and only when a tank hits them or an strong projectile hits them theese move, so would it be a good idea to have a sync on rotation and position with unreliable on change? I understand this would transfer data only if container moves, right?. Also if rate is lower than for instance a tank, should not be an issue, right?.

My fear is that this could take enough bandwith to affect tanks, is there any way to give priority to the data stream?

Alternative I was thinking of would be to have sort of position manager with a photon view and if container moves send rpc with position vector or vectorized rotation if variation of previous position/rot is bigger than a threshold. Certainly less comfy than previous soolution to setup but this may work but this could also generate a burst of RPC.

WHat do you think would be best approach?

 

Photon is very outdated and has many limitations regarding msg per room I recommend Mirror

 

@xavicarosilvente, thanks for your well founded input. Glad to read you're happy with something else.

@TokyoWarfareProject, the solution depends.
How maybe are "a number of non static containers"? Sync option unreliable on change might be a good solution. Your OnPhotonSerializeView should not send updates, when the object is static. Simply don't write anything and it's good. You can also lower their rate by writing an update every second update or so.
There are ways to put updates in another (enet) channel but PUN does not expose that well.
Simple networking could be a fit for the barrels, too, as it compresses the position updates really well. It's new in PUN 2.25 and we're now at v2.26.
I have to think more about this but time is running out now.


We're going to be on Christmas vacation. Stay safe and happy coding everyone. Cya next year!

 

Allright,

I'll brute force approach by syncing with unreliable on change and low hz rate when submitting info (I hope due to physics update, small oscillation of physics object do not trigger data flow, is there a threshold?) . And when I've the many stuff I've pending ironed try consider Simple for all the moving things. I also just recalled time ago I bouth an asset tutorial from Kurtav where he was thinking a S***ton of AI using photon classic, I may give it a look.

I'll say they're like about 70, highlighted ones



Happy holidayz

 

I got the email about the upcoming photon fusion, I'm eagerly awaiting details.

 

I'd love to hear more details about fusion if there are any to share.

 

They sent an email to people subscribed on their site. It is the lovechild of PUN and Bolt and what they've learned/fixed/improved over the past 6 years. So the new iteration is more robust and better performance.

 

Hi, how do I control the x position from my bullet after shooting with PUN2, my code is similar to asteroid demo, but my player/bullet are kinematic

 

Is the chat already included inside 100ccu on this package?
https://assetstore.unity.com/packages/tools/network/photon-pun-2-120838

Or I need to pay extra $45 for 100ccu chat?
https://www.photonengine.com/en-US/Chat/pricing

 

Happy New Year, everyone!

@TokyoWarfareProject, let us know how you do (either here or via mail).

@septN, the 100 CCU subscription only applies to PUN / Realtime service. If you need Chat or Voice, you have to get the respective subscription on top.
Important: The Chat API is included in the PUN package! No need to import anything else into your project, unless you want to use Photon Voice. Then get that package, which includes PUN and Chat (which means Voice should be the only package you'd then import into your project).

@niltonpmc, if your bullets move with a fixed speed and direction, don't sync their positions. Sync when, where and in which direction you shot and leave it to each client to spawn bullets which move accordingly. Sync hits (who got hit where and with how much damage). That can get rid of the bullet.

 

i'm facing some issues, sometimes when I create a room It simply stalls and ends up with a "time out" error msg.

Code (CSharp):

1.         PhotonNetwork.CreateRoom (roomName,roomOpt,TypedLobby.Default);
2.  

If while seems stalled I click again on create room I get this:
CreateRoom failed. Client is on GameServer (must be Master Server for matchmaking)but not ready for operations (State: Authenticating). Wait for callback: OnJoinedLobby or OnConnectedToMaster.


__________

in a simlar fachion, sometimes I'm failing to connect,
Is there a callback for connection state changed? I've been lookin in the api and found not.

somethining that would print PhotonNetwork.NetworkClientState on state change would be great to see at what point the connection is not stablished.

Code (CSharp):

1.  
2.     public    void Connect_EU(){
3.        // statusTxt.text = "CONNECTING - EU";
4.         statusTxt.text = PhotonNetwork.NetworkClientState.ToString();
5.  
6. #if UNITY_XBOXONE
7.         XBRegion = CloudRegionCode.eu;
8.         InvokeRepeating("XB1Connect", 0.15f, 3f);
9. #else
10.         //PhotonNetwork.UseAlternativeUdpPorts = true;      
11.         PhotonNetwork.ConnectToRegion(Regions.eu.ToString());
12.         PhotonNetwork.GameVersion = gameVersion;
13.         setID();
14. #endif
15.     }
16.  
17.     void setID()
18.     {
19.         PhotonNetwork.NetworkingClient.AppId = "my app id goes here";
20.     }

edit: and yes, I'm connectee to master and in lobby:

 

@tobiass

Hi, I've just got around to looking at using IOnPhotonViewPreNetDestroy interface, which I assumed would enable me to fire off a network event from the object that was being destroyed, but it looks like the callback occurs after the object being destroyed has already left the room, meaning I can't send any network events in the callback, which renders it far less useful than it otherwise could be.

Is there any major technical reason why the callback can't occur before the networked object has left the room, and if not, is there any chance it could be changed, or have another callback introduced in addition, that is called when a networked object is about to be destroyed but is still in a room?

Many thanks.

 

If this happens frequently, I wonder where / how exactly this happens. So, is the client still on the master server or on the game server already? The latter would be in-game and could depend on the amount of data you push into properties and event caches.
Did you update to the latest PUN versions?

Not all Operations (which are sent to the server) can be called on all servers. CreateRoom (and matchmaking in general) happens on the master server. The callbacks should help you know in which state the client is. Here, you call CreareRoom in the wrong situation.

You can enable the SupportLogger. It should log some more state changes and help identify the issues.

Yes, the problem is that we can't force any client to stay in the room until everyone else decided if they want to execute some action on any object this user controls.
You can use RaiseEvent or some other networked object to send messages, caused by someone leaving and or objects being destroyed.

 

Thanks for explaining that, it's a pity because there are instances where it would have been handy, but as you say there are usually workarounds.

 

Let us know your usecase and we can try to keep that in mind when we work on solutions.

 

Hello,

Good news.

Looks like my connection issuew where coming from running two clients on the same machine. I was doing so to test MP. After setting up the Xbox version I can now connect without issues in both targets

 

We updated the PUN 2 packages to v2.27 today.
There are good news and bad. The bad news is: we decided Simple networking should not be part of the PUN 2 package anymore because of the good news: Our upcoming package (codename Fusion) is making good progress. We will support the Simple components as external package for anyone who wants to keep using it (download link will follow).
Even when Fusion is out (no ETA yet), PUN 2 will stay supported for quite a while longer, so no worries about starting projects with it now.

So, here is what's new:

v2.27 (12. January 2021)
Removed: "Simple" networking. Due to the progress on an upcoming networkin solution (Fusion), we will keep this set of components an external addon in maintenance mode (supported but not improved/extended). Please remove the folders Photon\PhotonUtilities and Photon\Simple.
Updated: The Realtime API and Photon3Unity3d.dll to v4.1.4.9. This has a fix for unsequenced commands and improved ToString() support for the classes we added for the non-alloc workflow.

 

OK , yet, could the status of Simple be detailed to know wether its worth or not trying? I would say simple was still like in sort of beta so freezing it into "maintenance" mode its not super appealing .

The Fusion is a substitute of Photon or like an addon like simple to photon?

 

Fusion will be a standalone solution, which supports the "MonoBehaviour world" properly.
When we and everyone is happy with it, this will be the go-to solution for new (Photon) projects but PUN 2 (and Photon Bolt) will stay around (at least until we feel nobody is really using them anymore).

If Simple (as addon for PUN 2) is worth trying, depends on your case, really. Yes, it was still labeled beta and there may be quirks but as far as we got feedback on it, it was working nicely.
I don't know how far your project is to completion and how complex things are. There is no way for me to estimate if it will safe you time or not.

 

Regarding Fusion, will the feature set be similar to the current PUN2 feature set and will upgrading an existing game from PUN2 to Fusion be as straightforward as it was from PUN1 to PUN2?

Also, will the cost and CCU/bandwidth limits be the same and will existing PUN2 subscriptions be valid for for Fusion?

 

The feature set will be on par or better. Don't expect an automatic/easy upgrade path though.
Pricing is not defined yet. It's too early.

 

Thanks @tobiass , wasn't expecting an automatic/easy upgrade path, just as long as it's reasonably feasible, in much the same way that upgrading from PUN1 to PUN2 was.

Not relishing the prospect of shipping the release version of the game I'm working on with a version of the networking system that's sunsetting, which looks like it could be quite likely as things stand.

 

As usual, the feasibility of changing the tech for a project depends on the project itself. It's too early to make assumptions about it.
As said: We plan to support PUN 2 for quite a while. Consider it in LTS, which is a nice and stable place to be for a released game or one to be released in the near future. There will be no disruptive shutdown of PUN.

 

Any chance you could quantify 'for quite a while'? Sorry to harp on about this, but I've invested a lot of time and money into my current project, and the expected release date for the finished product is at least 18 months away, so I want to ensure that I don't need make any major changes to the networking code any time soon after release (by which I'm talking a few years).

I'm not expecting you to give an exact time frame obviously, but are we talking 2-3 years for example or do you expect PUN2 to still work for considerably longer than that?

 

No worries about asking. It makes as lot of sense that you are looking for clarify for your project.

If we talk about running your game for several years to come: Yes, we plan to support running games until the developer wants them shut down.

If we talk about updates for the latest features in upcoming Unity versions: It depends, really. We are not very dependent on a lot of features of Unity. But let's assume Unity 2024 would no longer support MonoBehaviours (just to have an example), then we probably won't port PUN 2 to that.
Of course you could still run Unity 2019/2020 to change, fix and build your game! There is no reason to cut this off.

 

Will there be some more information about Fusion coming soon? I understand that it should combine best of features from pun and bolt. Will you be able to share tentative scope? What will the workflow look like? Will it be closer to bolt or pun? Im not a fan of the bolt approach.

 

This was the bit that was causing me the most concern, and you've put my mind at rest about it. I completely understand that updates to the product would stop at some point, but as you say this shouldn't cause a problem in the foreseeable future.

Thanks for taking the time to answer my concerns.

 

Thank you for not giving up getting the answers you were looking for!
Anyone doing multiplayer games invests a lot of time and effort into this and the least we can do is keep the games up as long as you're happy with it.

@rasto61, it will take a while before we release more info about Fusion.
Would you care to describe what you don't like about Bolt's approach?

 

I dont like that I need to define things using the editor. I have a personal framework that I use for multiple projects and it shares some structure that is common between them. Any change is more time consuming than it has to be as dealing with the project.json is annoying if I need to share parts between projects, but not all.
A pure code approach is much better. Also better for vcs.

Is the direction of Fusion going to be similar to bolt?