I have been working on a project for a while and I’m currently separating it into a practically separate DLL - the only classes from Unity I’m using are the vectors and color structures, as well as Mathf and Time.
It would be perfect for me to separate the threads and implementation from Unity altogether so that the server could run the same DLL the game is using for local play, but without running unity headless.
Not using any physics or anything like that (got a separate simple, kinda-physics implementation that is sufficient, and I anyway needed different physics than what PhysX offers)
Can I somehow:
a) Extract those classes or put the Unity DLL on the server and use it from my application (my app would be the main thing, unity DLL would just be included during compile) ?
b) Reimplement the functionality into my own classes that I’d then use on the server and a different set to use on the client(from Unity) ? Don’t like this as there would be differences, probably…
c) Something else I didn’t think about yet?
And the second thing - is it ok to do legally?
Can I include a Unity .DLL into a separate application, which would run on the server and talk to a Unity application on the client? Couldn’t find that use case anywhere; technically it’s the same product so I don’t see it as bad, but would like some input there, if possible.
Most of the stuff in the UnityEngine.dll relies on the Unity Engine being around. Anything that touches a UnityEngine.Object needs to go through the underlying c++ engine. So just copying over the .dll is probably not a good idea.
Mathf is essentially the same as the built-in Math stuff. The Time class is a utility class built on top of the system time. Vector2/3 and Color should be pretty simple to re-write. I’d suggest going with b)
Outright decompiling and ganking their code is probably not a good idea.
Since writing your own version of Vector2/3 is pretty trivial, System.Math already exists, The ‘Time’ class is really the only hang up… and the decompiled version of it from UnityEngine.dll is just pass throughs to unity internal, so you’d have to implement that manually yourself anyways.
Though not sure how Time would work on a server anyways… deltaTime and other engine specific times would be meaningless since you’re not running the engine locally. So all you’d have is the Time.time, and Time.realTimeSinceStartup… which if you’re writing a threaded server, there’s far better time keeping you could use in the .net framework alone.