I’m working on a Unity asset for organizing files. For simplicity imagine a database browser that can manipulate the database both with in-editor GUIs, and from a standalone app that doesn’t require Unity Editor. The tool is not exactly this, but for the sake of the problem it’d be equivalent.
Some of its functionality would greatly benefit from having a standalone GUI app where a lot of code can be shared.
There’s a slight problem in that what I need is both:
In-editor GUI
Standalone GUI
(optionally) In-game GUI
where all three of these kinda share the same logic. Now I understand that in .NET one can have library assemblies that can be referenced in a solution, although I’m not entirely sure how to structure this so that Hot Reload would still work, and where I could also use the same assembly from a separate .NET project (say using WPF or Avalonia).
But maybe a broader question is, is there any workflow that lets me do this where I don’t have to re-implement my GUI twice? I’d really like to lean on heavily integrating into unity using ImGUI (and Odin maybe), but this doesn’t really work outside of Unity.
But if I use UI Toolkit/UGUI I’m locked out of this running natively in editor for level designing.
Currently I’ve been just prototyping with AvaloniaUI and considering building a seond GUI and sharing an assembly with most of the code, but this feels like a huge amount of effort wasted.
Any thoughts or tips on how to approach this are very welcome.
What makes you think that? UI Toolkit works at runtime, with some restrictions. You can also build the GUI hierarchically, and load different UI documents for either editor or runtime where necessary.
For a tool of that sort you definitely don’t want to lean into IMGUI.
The only real options you have are:
Write two GUIs
Have either an in-editor GUI or a desktop GUI
You can (and should) move any business logic into its own assembly with neither Unity nor GUI references, and treat the GUIs as separate assemblies that sit on top of the core framework. The GUI itself really only needs to push & pull data, so it should be for the most part just connection/binding code. Same goes for the database connector, which you may eventually want or have to replace with another or support various databases (offline, files, cloud, relational, flat).
But don’t rule out the second option. Don’t just make a tool for both situations because it seems like sort of useful. Put that to the test! Do users (not: you) really need both of these? If not, which one works best?
Also be sure to scan the market. Take time to find existing solutions, such as Unity Asset Manager (in the cloud) and I believe there are also asset management tools in the Asset Store. Just in case you’re possibly doing something that’s already out there that anyone who needs a tool like this is already gravitating towards. On the other hand this gives you ideas for alternative solutions, additional features, and reviews point to what users actually need or love about these tools.
Why would that be a concern? I was thinking you’re going to manage assets in the sense of meshes, textures, music and such. Not scripts. For scripts we have source control.
Are the limitations on sharing UI Toolkit between editor and runtime anything significant? I’ve only done editor tools in ImGui and gameplay UI in UGUI. Looking at https://docs.unity3d.com/Manual/UI-system-compare.html it looks like the limitations are mainly about VFX/shaders an very custom things.
This is how I imagined it would work, thanks.
Unfortunately the tool I’m working on does need both. I say unfortunately because it puts some constraints on how it can/should be developed, but there’s quite a few use cases for it both with specific Unity projects, and outside of Unity.
I may have explained this poorly, but what I meant was hot reloading while I develop the tool. The end users would of course not be impacted by this at all, it’s largely a tool for managing/organizing assets. From what I’ve tried it seems hot reload works fine for in-editor tools as well, though I’ve only tried simple things mainly with Odin.