I’m building a component that should be permanently connected to a certain back-end. This is a helper service for game developers. It needs to run both when the game is running AND when the editor is in edit mode (!Application.isPlaying). The service will use a socket connection to the back-end and some inspectors in the editor will rely on this socket for communication.
I’ve been looking at ways to extend the editor and have seen how to build menus and custom editors. But those are usually connected to a Game Object, whereas my service should be connected to the entire game (via interfaces that the game exposes).
Permantently? not with managed code ^^. Keep in mind that Unity is a C++ engine and C# / Mono is “only” used as scripting layer. Whenever a script get changed Unity will recompile all your managed code. For this the whole mono runtime is shutdown and reloaded since you can not “patch” an already loaded assembly. Such an assembly reload can happen at various times. The Unity editor will serialize all instances it can serialize and recreate and deserialize them after the reload. However anything that can not be serialized is usually lost.
Sockets are system resources and you have to be careful with the handling of such resources. So the best solution for such a “service” is probably to implement a native plugin in C++ which you use in Unity.
Of course you can go the managed route, however you have to expect that everytime you enter playmode or when scripts are recompiled that you get an interruption and you have to “reconnect” to your backend.
I’m a bit confused. First you said your game / the unity editor will connect to the backend via a socket connection. Later you said your game should expose an “interface” and your backend should connect to your game. That’s a bit contradictory.
What’s the best approach of course depends on the actual point of that service. If it’s just a “helper” for the developer, do you actually need an actual permanent connection? More information on the goal of your helper is necessary to give actual suggestions.
Thank you for providing the first answer in my quest to crack this :). It’s one of my most important tasks this entire project
Oh, what I meant was that the game and the service interact via interfaces. And that the socket (in the service) connects to the back-end. In other words game → (interface) → service → (socket) → back-end. Of course, the socket also respects “interfaces” as in it communicates using certain standard JSON schemas :).
Yes, I do know it’s C++ and the fact that scripts reload is not an issue. Of course in that case I’ll simply reconnect. However, I do have some objects flagged as “DontDestroyOnLoad” and apparently they do NOT get re-created, or if they do, it is done in a smart way since the object’s hash seems to be restored (I found this via calls to .GetHashCode() for a class onto which I invoked DontDestroyOnLoad).
But in order to facilitate this behavior, I still have to have a GameObject in the game and call DontDestroyOnLoad on it. I don’t want that.
What I want is to have such an object that is NOT connected to the game code itself. It exists by virtue of the game developer importing my code from the Asset Store in his project. That should be the only requirement
First of all, no, all objects gets recreated. Keep in mind that all objects derived from UnityEngine.Object have a custom GetHashCode implementation which just returns the instance ID which is the actual id that is used to identify any UnityEngine.Object on the native side.
I don’t really see any issues with having a gameobject in the background. Unity does this itself. The sceneview lights and cameras are actual gameobjects. However they are not visible in the hierarchy, nor the inspector. They are not saved to the scene either. For more information you may want to have a look at hideFlags as well as HideFlags.
Apart from that you can use the InitializeOnLoad attribute on one of your editor classes. This will cause the static constructor to be invoked automatically when your project loads. If you need other hook points you may want to have a look at the EditorApplication class which has several events you can subscribe to.
Most things in the Unity editor are actually handled through ScriptableObjects. Every EditorWindow is a ScriptableObject (The EditorWindow class is derived from ScriptableObject). That’s because ScriptableObjects are tracked and serialized objects (so they are automatically reloaded / recreated and can be found with FindObjectsOfType like all UnityEngine.Object instances).
