Is my game too complex for PUN?

We're working on an online 3rd person ARPG. The issue we're running into is our msg/s limit with even 2 players in a room due to the amount of NPCs that need their states sync'd, and who are calling RPCs for things like dropping loot or deciding to run away from a fight.

As far as I know we have no RPCs that are being called each frame, with the most frequent RPC being called every 10 frames (NPCSyncState to keep each NPC doing the same task for each player).

I understand how RPCs work I believe, but it feels like PUN is made for games that ONLY include players (PVP only) and not much else. It feels like after syncing the basics of NPCs they might as well just be other players as far as weight vs msg/s goes.

I've read up on Photon Bolt as well, which seems to also include a similar msg/s limitation which I don't really get since it's P2P and not even over a server. Do messages work differently there? Measuring CCUs - that's fine, our success should pay the maker of the products we use proportionally, but why the msg/s limit?

Anyone who can shed some light on some of this is very appreciated!

Comments

  • edited July 10
    From the sounds of it, yes, if every single NPC is sending an RPC to sync up with the player, that's way too many messages being sent for trivial information.

    Perhaps, in terms of game design or engineering, there is a better way for these NPC's to make such decisions before syncing? Like syncing up the loot for each NPC in one RPC before the encounter begins via MasterClient. I'm not very experienced in ARPG but from what I've seen in Diablo, there tends to be a ton of enemies to fight at once, correct? Maybe you should also look into how those games deal with that many instances while syncing over network. (Unsure if Diablo has coop, apologies for ignorance.)

  • Hi @BurgeeGames,

    without using server-side logic you can try to optimize messages which get sent. If you want to give that a try, you can have a look at the Interest Groups documentation page as well as the Culling Demo documentation page. The first one gives a general overview about Interest Groups and what you can do with them. The second one describes an example on how you can use them to optimize messages getting forwarded to other clients.

    I've read up on Photon Bolt as well, which seems to also include a similar msg/s limitation which I don't really get since it's P2P and not even over a server.


    In case a direct connection between two clients fail, Bolt's relay service is used which is part of the Photon Cloud. Means that messages might get forwarded through the cloud servers.
Sign In or Register to comment.