A while back, Marty, our studio’s senior developer, ran a Photon Fusion workshop on our community discord server. The recap video is available on Youtube, but we thought a blog post might make the content more accessible and easily referable! (And no, we’re not affiliated with Photon, it’s just a tool we’ve found extremely useful in our projects and felt would be valuable to the game development community!)
Without further ado, here’s an abridged transcript of our Photon Fusion 101 workshop, sharing what Fusion is, the pros and cons to it as a networking tool, and an overview of the different network topologies it supports. We also have a public Photon Sample Project you can check out! Read on to learn more!
What is Photon Fusion?
Photon Fusion is a networking framework, which is a fancy way of saying it’s a tool that allows you to make a game where lots of different people on different devices can play the game together in some way, shape or form. Fusion is a brand new stack that is currently still in beta, but is still stable enough to use in a production workflow.
Fusion is an evolution of some of the older Photon products such as PUN and BOLT. PUN is older and likely one of the most well-known networking solutions used by Unity, and was very much client authoritative in design. BOLT on the other hand, is a more server authoritative networking solution. Fusion brings both of those concepts together in a much more modern framework.
In particular, it has some really nice support for rigid body or physics-based networking including things such as physics rollback and interpolation of physics objects. With its competitive pricing, amazing support, and suitability for a wide variety of games, ranging from competitive esports to MMO style experiences, Fusion is overall, pretty cool.
Pros and Cons
As a summary, here are some pros and cons you might want to consider when deciding on Fusion as a networking tool.
|1. Flexible, supports a varieties of Network Topologies and Architectures|
2. Out of the box components to suit a variety of games:
With Fusion, you have quite a few components that are similar to what most other networking frameworks would give you. This gives you the ability to very rapidly prototype and get different things up and running to iterate on and sort of test different things out.
3. Next level performance compared to other networking frameworks:
Fusion’s overall performance is very solid compared to most other networking frameworks on the market. It is easily one of the most performant, both in terms of bandwidth usage and in general, the actual amount of cpu usage. Fusion has really nice delta compression across the board or with their eventual consistency mode, where you can specify a level of bandwidth to not exceed.
4. Competitive Pricing (Free to 20 CCU, $95USD for 100 CCU/year)
5. Supports all traditional platforms and webGL
|1. It’s not free*|
You get what you pay for! With Fusion you are paying for a very solid, very mature stack. Having that level of support is valuable, but also highly dependent on your particular needs and business case.
2. All connections must use Photon Cloud, and Fusion doesn’t support direct IP connections
Fusion needs some workarounds for dedicated server hosting. Every connection has to go through Photon Cloud which does give you some nice features (Eg. Network Address Translation punch through and guaranteed connectivity.)
However, if you are working with a back-end matchmaking service that just wants you to connect by direct IP and direct port, you may run into some complications. (There are workarounds, of course!)
3. Some unique design patterns, could be difficult to refactor to a different stack if required
When we discuss network topologies, we’re talking about how different clients will connect to each other and which computer is in charge of what’s actually happening within the networked session.
Server is the most traditional model, and means that you have a dedicated server hosted somewhere (Eg. AWS, Playfab and Google) and it is your authority for a game session.
Generally, you would spin up a dedicated server instance on this back end. Your client would connect directly to that system, and it would have full state authority over the simulation (Eg. all of your gameplay logic.) Because of this, the opportunities players would have for malicious activity (Eg. hacking or cheating) becomes significantly fewer.
Unfortunately, this wouldn’t prevent things such as wall hacks, depending on what information you are synchronising through to each of your potential clients.
Host is similar to Server, in that you still have a single authority as far as the session is concerned, but one of the clients themselves will be one that creates the session. Fusion does support host migrations, so you can move who the host is to different clients if needed. Check out Fusion’s documentation and examples on Host migration here.
One of the main positives to the Host model is, of course, the cost-savings! As sessions are being hosted by clients running the game, you can save on back-end servers.
Unfortunately, there are also the downsides to do with sacrificing player experiences. Because the authoritative instance is running on one of your client’s computers, if that instance or that client is hacked or manipulated in any way, player experiences in-game might be affected. Connection quality is also dependent on your client/host’s connection. For example, a host with a 3G connection from a bus might result in poor gameplay experiences for everyone within the session.
Shared authority is where each client has state authority over objects assigned to them.
For example, if you think of a game like Rocket League, it would mean that each client would have agency or authority over each of their cars. This is great if you have a game which is very responsive and needs very precise input controls because, from the local player’s perspective, it will feel very much as if they were just playing a single player game.
The downside to that is that you may still be relying on the client’s own connection quality, affecting the other player’s experiences. Besides this, it may not be as suitable depending on the type of game. Shared authority works when it makes more sense for each client to have authority over particular objects, but it might not be the right fit if you had a lot of shared objects or heavy physics driven scenes.
The Shared model is a nice middle ground between the first two models. Generally speaking, running Photon servers will be significantly more cost efficient than running a full dedicated headless Unity instance. This model is often used for games that have large numbers of players and games which are “less competitive”. You wouldn’t want to do this for games like Battle Royale, which are more server heavy, but this would be appropriate for PVE MMO style games.
Quantum is another solution offered by Photon that is a full deterministic simulation. It has its own application layer, while Unity sits on top as more of a visualisation layer. So— although it is technically using Unity, it is very much like learning a new engine.
They have their own physics frameworks for 2D/3D, update loops and other elements, hence a steeper learning curve. Besides this, Quantum does still require a back-end server similar to Shared mode. This means there is still the ongoing server cost in addition to whatever costs associated with using it. Having said that, it is the appropriate mode for games where you’re expecting players connecting globally with very different latencies, packet loss or situations.
Photon Fusion Sample Project
Marty and Grant came together to make this sample project using Photon Fusion, called Fusion Pong! You can check out the public repo here. Enjoy!
To conclude, we hope this has been helpful in helping you understand the different type of networking solutions Fusion offers that would be appropriate for the game you’re making! Feel free to send us your questions (email@example.com), follow us on Twitter or join our discord for future similar events and/or discussions.