Authoritative Server

Photon and Physics

Out of the box, Photon does not leverage or interact with any scenes or physics.
While we work on integrating Photon seamlessly into several 3D engines, running physics on the server is tricky.
In our experience, requirements are differing per game (per genre and even per title), so there's no simple and common way to get this right.
Also it can quickly become one of the more costly parts of hosting multiplayer games.

With the Photon Server SDK, you got all the tools to make the server authoritative for your game, using physics or any other model you like.

Physics Options

There are several approaches to make the server authoritative.
The following ideas use Unity3d as example but essentially any 3D game engine can do the same.

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.

Run Unity Instances

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, engine 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.

Unity's physics are not deterministic across platforms.
You might run into some updates due to differences between server and clients as the engine gives you differing results over time.

Use a Collision Detection library

Currently, our preferred "authoritative server" model is to use a simplified "physics" engine while exporting level data.
It's a extra 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.
Triggers in Unity are similar to this: Not actual physical entities but boxes or meshed 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.

Physics Communication

If the server is running the actual logic to move things, it just needs the player's input and will update everyone with the resulting movement and events.

You can implement Operations on the server to let clients "submit" their input.
Like an operation "Move".
Unlike operation RaiseEvent, these operations won't send the client's data to everyone but update the server state of a particular item.
Parameters are input and maybe mixed with position and movement data as seen by the client.

In the server, you can run the logic in intervals (using RequestFiber.Schedule() or RequestFiber.ScheduleOnInterval()).
Anything that changed movement needs to send an update to the clients, which can be done via Photon events.
Per event you can send a list of item movements: Each must have some ID, position and velocity maybe. Add info as needed.

If you allow the clients to to interpolate a few frames between updates, you can save some traffic.
This gets more important with higher player counts: Send 20 updates/sec to just 32 players and every 2 bytes in the event resemble 1kB of traffic.

If one Photon event can be sent to multiple clients, that saves serialization work.
If there are too many items moving, you will have to filter out less interesting ones per player, per region or by some other way.