Selecting appropriate client / server middleware [Photon question]

Community Showcases
1

Hi all,

I’m currently prototyping my client / server game, and have been looking at Photon to take a lot of the drudgery out of the multiplayer development. I’ve yet to start developing multiplayer features, but would like to get a good sense of Photon’s abilities / integration with Unity before I get started.

A bit of background regarding the game:

  1. It’s a MOBA-style match game, up to a maximum of 32 players per match/server.
  2. Server-authoritative physics, collision, movement, and player control.
  3. On the server, in-game grid / spatial awareness would be great to keep remote updates fast (Photon’s interest management feature).
  4. Players are matched based on match size preferences.

My question is: (How does / does) Photon permit me to leverage Unity3Ds physics engine on the server-side codebase to not have differing calculations for physics and player’s movement? This would be so that the client client will still to be able to predict collision using the physics provided by Unity, but receive accurate corrections from an authoritative server to prevent hacking and cheating.

Any comments / past experience / advice are welcome…
Thank you!

2

Cool you’re checking out Photon. Sounds like a good project.

By itself, Photon does not leverage or interact with Unity’s scenes or physics. While we work on integrating Photon and Unity seamlessly, running physics on the server can quickly become one of the more costly parts of hosting multiplayer games. In our experience, requirements are differing per game (per genre and even per title), so there’s always a lot of customization going on.

There are several approaches to make the server authoritative.

You can actually run Unity instances on the server. Your Photon Server logic will be written in C#, so it’s easy to start one Unity process per Room and communicate with it as if it was another client. Locally, it doesn’t add lag. However, you need the CPU, Unity licenses and automated workflow to start, stop and cache Unity instances. One per room and scene and you need to keep scenes on the server in sync with those in clients.

I’m not sure if Unity’s physics will be deterministic across platforms. You might run into some updates due to minor differences between server and clients if the engine gives you different results over time.

Currently, our preferred model to make the server authoritative is to use a simplified “physics” engine while exporting level data. It’s a lot of effort, true, but gives best results while keeping runtime costs low.

Often, games just need collision detection: Hitting another unit doesn’t mean you want the bullet/sword to bounce off. You just need to know about the hit. I think that’s what Triggers are for in Unity: Not actual physical entities but meshes that have a callback when they overlap and your code reacts. If your “physics” can be reduced to triggering events, it will save performance.

Depending on the game, it might make sense to not use Unity’s physics. A simplified 2d collision detection engine might be fine. Any C# based engine can be used in Unity and Photon. With that, you could run the same code on both sides.

Many games use a simplified mesh for navigation. Even on the client side. You don’t need to load every single grass leaf of a scene when you just want to know where a player can go. If you have a simplified level, it makes sense to use only that on the server. Some customers are writing exporters from the Editor, so they can use it to setup levels and use the results in the server.

I’m sorry I can only give you high level feedback.
Also keep in mind that you can cut any number of corners when your project is just hobbyist or for prototyping. Unless you get a lot of players, cost and performance per player are irrelevant and you definitely should go ahead and just work on the game :slight_smile:

3

This seems like it would be slightly more complicated than necessary in my particular case… I was hoping to write a very small match-handling binary that would act modularly for each “game room”. More would be ramped up as load increases.

You raise a good point here that I never even considered - my clients will be on multiple platforms while I was hoping my “game room” server could be written in pure C/C++ and compiled to native code for speed on a Linux target platform. Now that I think about it, what you said makes more sense, since a simplified top-down orthographic perspective of the game will actually suffice for static and dynamic map objects. The only thing I think I’d have issues with here is if I wanted to do any projectiles that have a height component - but the design here is flexible in order to reduce technical workload :wink:

Don’t worry about it, your post was actually fairly helpful to help figure out a direction to take with the server component. I appreciate the insightful input. Now I need to look at Photon again to see how I might leverage it combined with Unity and a pure C/C++ server instance. I plan to have a pool of match servers available (that configure themselves as players set game preferences), and more that will dynamically “spin up” as the number of concurrent users increase.

Thanks Tobiass!

4

If you want to use unity on the server for physics and collision detection then unity’s built in networking or unityPark sutie from www.muchdifferent.com are integrated better with it.
PhysX is not deterministic and even on the same machine produces different results with the same state and force commands so if you have moving rigidbodies and using PhysX then server should tell everyone where each object is, if you are using triggers, normal movement and raycasts which most games do then there would be no problems.

5

What is this match-handling binary’s role exactly? Does it pool Unity instances or …?

6

No - the game is designed to support from 2 up to 32 players, so the model I had devised was having a server that’s responsible for coordinating game data between those 32 clients, in a small binary (rather than having one server handle 10 32-player games, for example). This binary would then be cloud-enabled in some way to manage the game’s scalability as CCU’s increase.

In order to facilitate this, there would need to be some type of load balancer that controls those instances, which to the best of my knowledge, already exists with Photon.

7

Just to be clear, I didn’t necessarily mean 1 server per 32 player match. That configuration would be very wasteful of resources. What I meant, rather, was some number of smaller 32-player servers would exist on a server, and a load balancer would manage those on individual servers, and across multiple servers.

8

Take a look at this example for managing multiple game sessions on a server
http://developer.muchdifferent.com/unitypark/Tutorials/uLinkNetworkGroups

The game session manager used in one real commercial game at least and i’ve used it for multiple tests myself.

9

So your matchmaking binary should distribute (binary) messages in (arbitrarily sized) matches. Those matches should be distributed across several servers to balance load if needed?

This sounds like a description of Photon :wink:

All of that is available in the default implementation of Photon’s “Load Balancing Application”. It’s pre-built in our Server SDKs, runs out of the box but you also get the source to add features. Matches are called “Rooms” in Photon and a lot of them can run on one machine and there’s a built-in logic to distribute them across machines.
You probably don’t need to reinvent this part of your solution.

It’s the physics where Photon needs to be customized, if it should run on the server.
At a high level, I think you could modify our Room class to load some exported level representation and run a collision detection “physics” to get hits, etc.