If I implement photon into my project, would I still use replication based on UE4’s networking system? Or am I going to have to hard-code everything network related in C++? So essentially what I’m asking is, does photon’s server replace the dedicated server that is built into UE4?
Theoretically you could use both in parallel, but that doesn’t make much sense in practice. So normally you would use Photon instead of UE4s built-in networking system. You can do everything network related in C++, but you could also write your networking in blueprints that call C++ functions which would expose everything you need from the Photon API to blueprints. Photons UE4 demo that you can find at http://doc.photonengine.com/en/realtime/current/sdks-and-api/sdk-unreal-engine does it this way.
Thank you - I’ve already looked at this demo previously but there isn’t much documentation out there that expands the limitations of which C++ functions that can be called via blueprints. I’m trying to do research on Photon’s API but it’s not well documented.
Basically you can call of them via blueprints. You will just have to add wrapper functions - like the demo has them for every Photon function that is called by the demo - for every function that you want to use. As you can see in the demo this is pretty straightforward and simple.
There is a Photon Client C++ API reference at http://doc-api.exitgames.com/en/realtime/current/cpp/doc/. Some classes are not documented yet, but feel free to ask for help in the Exit Games forum. Our devs normally answer within 24 hours.
Using the Demo Particle and inclusion of my AppID - I continuously receive errors. I’m finding it difficult to decipher what is causing this issue. Seems that the demo isn’t straight out of the box as it’s not working accordingly.
Warn: OpCreateRoom() Failed: Unknown operation code.
I’m looking in the Import script(s) and inclusions all seem fine. Any idea why this is happening in an ‘out of the box’ demo solution?
I can look deeper into the scripts, if I have to.
Seems as if though the server is just simply sitting at ‘connecting…’ which may be the issue primarily?
Using serveraddress ns.exitgames.com:5058
AppID … well that’s for me to know
Help with this issue would be greatful.
This sounds like a firewall issue.
Please make sure that you allow outgoing UDP traffic to use port 5055-5058 (and outgoing TCP traffic should be allowed on ports 4530-4533, if you want to switch the protocol to TCP) for UE and also for standalone runs of the app.
Also it’s ns.exitgamescloud.com, not ns.exitgames.com, but that is probably just a mistake in your post, I guess.
Moreover please make sure that you replace your app id in the properties of the PhotonLBClient actor and not ust inside the cpp-code file, because changing it in the C++ code only changes the default value for the appID for further actors to which the blueprint gets attached, but does not change the value for existing actors! Also please verify that you don’t replace “<no-app-id>” by “<yourActualAppId>”, but by “yourActualAppId” without the “<>”
I also using the Demo Particle and inclusion of my AppID , but i dont know how to set it , and what the photon server i must to set…
hope some one had do it. can call me what i will do…
Third item down in Photons Documentation:
Only UE4 'C++' projects are supported.
What are the benefits of using Photon over built-in networking from UE? Feels like putting another complex layer between one system and another.
Please be aware that when connecting to a Photon Server instance instead of Photon Cloud you also need to make sure to pass ExitGames::LoadBalancing::ServerType::MASTER_SERVER for the ‘serverType’ parameter of connect().
In the demo app you can find the connect() call in the file PhotonLBClient.cpp.
This depends a lot on your use case.
With UE4s built-in networking you need to run UE4 server instances to which client instances can connect. Such a server instance could be one of the players, but that would mean that that instance has more work to do than the others and also that it is authoritative (which makes cheating a lot easier for that client) and that it has latency free gameplay, while the others experience a latency that is as high as their ping to this player. So even without cheating that player has an unfair advantage over the other player that ironically gets bigger the worse his latency is.
Having a player host a game also is rather problematic if you want to support mobile platforms (as this means more unstable connections, less powerful devices, higher latencies and NAT issues for these players, so that it is not a good idea to let mobile devices host games (which would mean having at least one desktop client in every game to act as a host - this also means you need to allow desktop and mobile players to play against each other, which makes balancing a lot harder due to the fact that they use different input methods)).
For these reasons many developers prefer dedicated servers over having the players host the games.
Dedicated servers cause a lot of hosting costs and require maintenance. Also there is a lot of overhead for small teams to run nearby servers in several regions of the world. Especially for smaller teams it can proof to be too expensive to have a dedicated server operations engineer around 24/7 to get servers back online ASAP when problems pop up, which would mean to disgruntle players with long down times.
Photon Cloud comes in very handy in this situation as it provides hosting. Due to the amount of Photon customers and an aggressive pricing this is usually cheaper than hosting servers yourself.
UE4s built-in networking doesn’t really offer anything in terms of matchmaking and scalability. To achieve this you can either switch to Photon networking completely or use Photon Swarm, which is a solution that uses UE networking for ingame networking, but Photon to provide matchmaking and scalability on top of UE networking.
Also Photon is fully cross-platform, which makes it possible to mix clients that use UE4 with clients that do not do so and to still allow them to play against each other.
I suppose I’d have to try it out myself to find out really. I’m building an RTS / FPS Hybrid, and networking is one of the biggest challenges of something that has such a huge scale and density of objects. Paragon feels like it can barely handle a handful of pawns at times, and Unreal Tournament only needs to handle a handful of players. That said, UT has good netcode, and even player-hosted matches are pretty responsive and fair.
With this in mind however it would be nice to see some example content, to see how difficult it is to move to Photon. Having Photon as a plugin rather than having to do a source build of the engine would also be a huge bonus.
Could you elaborate on what you mean with “Photon Swarm”? Is there documentation for it? I can’t seem to find any mention about it neither on photon engine’s website, nor the general web.
Photon Swarm is another flavor of Photon just like the ones from our website. It uses standard Photon under the hood (on both sides, Client and Server) + a server side interface through which it facilitates other networking solutions (currently the built-in networking functionalities of Unreal and Unity are supported). Each client establishes a connection to Photon and can there create rooms for games. Those rooms are listed in Photons lobby for other players to either join them by room name or by random matchmaking (join any room that fulfills the specified criteria). When a client enters a room, it switches from being connected to a Photon master server to being connected to a Photon game server and enters the room on that game server. That room is a fully function normal Photon room and all in-game communication between clients that you want to can run through Photon. Furthermore Photon provides the address and port of an Unreal Engine server instance to clients inside that room and the clients can connect to that instance through normal Unreal networking instead of through Photon. Clients that are connected to this instance can do all of or parts of their in-game communication through Unreal networking. Photon spawns a separate Unreal instance process for each room and multiple instances can run on the same hardware. Photon monitors the load of the game server instances which host the Unreal instances and ramps up further hardware instances when more players get online (when the amount of players goes lower, then the addresses of certain game servers no longer get returned for new rooms and those instances get shut down after all running games that are hosted there have been finished).
We currently only offer Photon Swarm upon request (please contact us through Contact Adresses and List of Events | Photon Engine if you are interested).
Photon Swarm has been discontinued and is no longer available.
Thanks for the info - that does indeed sound very interesting! Sent you an email with a request!
Thanks. We got your email and will respond shortly.