Third Party Access Unity Classes in Photon Server

I'm looking for the correct unity DLL to include in my server references so that I have access to things like Lerp and Vector3. I'm fairly certain these are withing the UnityEngine namespace?

Also, can I use UnityEngine outside of the engine runtime? I read somewhere this was possible and now I'm having a hard time finding the article again to confirm. I can't test because I'm, as of now, not seeing what I should reference.

 

You most likely can't use UnityEngine outside the runtime. Several features are bound to the main thread that the engine runs and become useless when outside of Unity.
Aside from that, there should be a UnityEngine.dll somewhere in Unity. The file explorer should find it.
It's likely faster to try this out yourself than waiting for someone to answer here, as this is quite uncommon.

Are you trying to read PUN's messages on the server or are you using the Photon Unity SDK on the client side? I am asking because PUN defines/uses some messages which you would first have to "reverse-engineer" to make use of them in a server.

 

I'm specifically looking to utilize some of the static functions/classes such as Mathf and Vector2 and Vector3. I also tried referencing a few different .dll already before asking on the forums. I usually give it an honest effort and then some before turning to the community. At that point I work on other things until I receive a response so I can still be productive without beating my head against a wall. And no, I'm not trying to do anything with the messages.

When you say it's ucommon, what's the standard practice for handling physics and vectors and movement in an authoritative server? Unity has all these methods built-in. So authoritative servers have to write all this from scratch? Seems like just including UnityEngine.dll (or whatever it may be) would make a lot more sense. It is also possible it's the correct dll and I am just using it incorrectly. Thank you for your response.

 

It is of course not uncommon to do use the math and vector classes in authoritative servers but especially for PUN, it is uncommon to have authoritative servers at all.

Unlike the built-in networking, the server for PUN does not know the scene and meshes, does not run physics and does not track Instantiates or positions of GameObjects. The server is transparent for the PUN clients and just forwards messages and caches some of them on demand (for players arriving late).
Updates of observed PhotonViews contain additional data (like the ViewID), for example. Those updates go from client to client and the server is not built to expose the content of those updates.
So, aside from making use of Vector3 from the Unity dll, you would also have to analyze what PUN is sending and how to make use of that.
If you want to make the server authoritative, then it might be easier to use PhotonNetwork.RaiseEvent() and send your own messages. It is independent of PhotonViews and viewIDs and such. This has a negative as you need to implement how events are mapped to actions related to game objects. But on the positive side you don't have to analyze the content of PUN messages (which is easier to implement on the server, too).

As far as I can tell, you only need the UnityEngine.dll referenced in your project. Then you should be able to setup "using" for the classes. If they work in your context is another thing.

 

Is this a stated fact of how often PUN authoritative servers are written, or the default ability of a server to be authoritative at all? I ask because the exit games website has "Your own authoritative logic" written all over it. Why isn't there more transparency in the server logic if PUN is claiming one of its intended uses being authoritative?

Currently I've written an additional operation system that piggybacks the existing operation system. If it's a gamelogic operation code it passes it along to a separate switch block within a custom directory for handling. Within the game I then just run a PhotonNetwork.networkingPeer.OpCustom(MyCustomCode, message). So I can call this whenever I want in any of my client code separate from a specific photonView, if need be. Is this not a good method? I'm entirely unaware of RaiseEvent, though I'll go look into it. I imagine using RPC, RaiseEvent and OpCustom together might be a good workflow? Maybe not, haha.

Ok, I just read up on RaiseEvent. It's essentially the same logic as how operations are handled, but I'm guessing intended for the purpose I was just describing. Hmm. So should I reserve using OpCustom for connection/server specific logic and use RaiseEvent for game logic events?

 

> the exit games website has "Your own authoritative logic" written all over it​

You might have a point there.
The page is maybe a bit much geared towards "sales-material" and shallow. On the other hand, we have a hard time explaining "everything" on pages that are short enough to read within a few minutes.
We are usually quite frank about the amount of work and time that goes into authoritative logic. Doing some calculations is easy but when you start with physics, you will have to load models, scenes, etc. You might need the navmesh and AI, too. When things change, you also run into the trouble of versioning and updating the server along with clients.
It's complicated.

My fear was that you attempt to read RPC, Instantiate and other PUN specific messages. We implemented them as pure "client to client" messages and ignored the server for those. The initial goal for PUN was to mimic what Unity's networking does but on the Photon Cloud. The Photon Cloud does not run game-logic, so we didn't need that and here we are discussing why and how

Using OpCustom is absolutely fine and the high level workflow sounds good.
RaiseEvent is an operation we implemented to tell the server which events to send and to which selection of players. Maybe it is not very useful for your case. If you just want to pass some events around, it could be of interest.

RPCs are using RaiseEvent. They are just defining some event code and content and we make sure they get read and used as method call.
I assume you can ignore RPCs mostly in your framework as you are building your own communication flow already.

 

Whew. Ok. I was getting scared I was doing it horribly wrong there for a minute, haha. However I sadly had not realized that we're effectively ignoring the current MasterClient setup, and AI (navigation, updates) all has to be on the server. it is a ton of work. This is off topic, but while I've got your attention... I read on the the site (maybe this was another sales tactic ) that you could run a Unity instance on the server to act as a masterClient. In regards to performance, is this a viable solution for handling AI, physics, navmeshing, etc? It would GREATLY decrease development times, that's for sure. But if that's the only positive I'd probably go with something else. Thoughts?

Also, thanks for the quick replies and the honesty on the shallowness of the website. It did come across as rather sales pitchy and not so helpful. I wrote it off as not beneficial pretty early on when most of the site was just explaining what can be done, and not HOW it can be done. Further reading I can see there's loads of useful stuff. The first impression of the website wasn't all that great though. My 2 cents.

 

Thanks for the feedback on the website. How it comes across depends a lot on who is reading it and for what purpose. The development side of things is probably not obvious enough. We keep working on it

As far as I know, it's never really simple to run authoritative servers.
If you run headless Unity, it will "understand" the scene, physics and such but you need to do versioning, start enough but not too many instances and your server cost might be higher (due to CPU load).
Alternatively, some developers run a physics engine in Unity and in Photon Server. They export the scene as low-detail map for the server. In many games you don't really need full physics but only a good collision detection (like triggers, instead of Rigidbodys).
Neither is solved by Photon out of the box but both has been done before.

Actually, I have a hard time telling you "do this" or "do that". Depending on your ambitions and requirements, this is a lot of effort and unless we look at your team and the specific game you plan, it's just not a good idea to tell you what to do, aside from one tip:
Experiment. It might sound like luxury but if you can spend the time, try out some things in small scale.

 

Ya no worries. You're not telling me what to do, just giving suggestions and I appreciate all the insight I can get. And you're absolutely right. What we're doing right now is implementing about a 15% authoritative server and planning on moving more and more over as it's needed. We're trying to code things in a way that keeps things very modular so moving stuff around is easy. Small scale to start.

Thanks for all the help and suggestions. I'll let this thread die... I think it's about that time.