PhotonServer within Unity3D Instance

Xerosigma

I'm working on a project that requires a server with physics and collision detection logic.

Can PhotonServer somehow be run within a Unity3D instance?

Thanks.

Tobias

No, Photon can't run as server inside of Unity, sorry.

While this makes some things easier, it also has various drawbacks. Some of those are listed in "Differences to Unity Networking" here:
http://doc.exitgames.com/photon-cloud/PUNvsUN

Do you need real physics or just hit/collision detection?

Xerosigma

The goal is to make the server as authoritative as possible to avoid discrepancies.

Game states, player positions, world object positions, and the world mesh itself should all be controlled and persisted by the server.

Physics we could do without I suppose. I'd have to use something like the TAO Framework to render the world mesh in if I go with Photon.

What solutions or considerations would you propose?

Thank you Tobias.

chvetsov

Hi, Xerosigma!
you could export your mesh from Unity and use it on server.

Tobias

Xerosigma:

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.

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.


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


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