Search Unity

  1. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  2. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

How to deal with volatile resources (strings, skins, configs) in custom editor tools

Discussion in 'Immediate Mode GUI (IMGUI)' started by Xarbrough, Dec 7, 2017.

  1. Xarbrough

    Xarbrough

    Joined:
    Dec 11, 2014
    Posts:
    1,188
    What are your approaches to working with (advanced) editor tools, that require certain resources like:
    • Many strings for window titles, labels, buttons
    • Skins and styles for GUI elements
    • Configuration paths
    • Platform settings
    These are the approaches I can think of:
    • Hardcode everything in C# code, maybe wrap it in static classes with lots of constants
    • Ship the tool with a ScriptableObject that stores everything and can be loaded by finding it in the project
    • My own little resources folder for different files like GUISkin, icons etc, which I load from my tool (but I might not want my project to be cluttered with all those files)
    • Maybe in combination with EditorGUIUtility.Load() or generally using the special Unity folders like "Editor Default Resources" and "Gizmos"
    • Custom resource file format (XML, JSON)
    I'm wondering because so far, I've been only hardcoding my volatile data in Unity editor tools, but coming from the .NET/WinForms world I was used to resource files which could conveniently be packed directly into the assembly file. Does anyone use a similar approach for Unity tools? I think it might make sense but haven't come around testing it.

    Please also tell me, if you think, it's not worth trying to move the mentioned data out of source code.
     
  2. dadude123

    dadude123

    Joined:
    Feb 26, 2014
    Posts:
    789
    Imho it is totally not worth it unless you actually plan to make the tools public (and even then...)

    I'm writing tools mainly for myself and other project members, to save time and even let people without programming skills create more complicated assets. For me editor tools are not meant to be used by the wider public.

    For the game I'm making I have some public editor tools planned that are supposed to be used by the players (for modding purposes). However I'm still in the prototyping stage and will deal with the problem later (if it even becomes one).

    For skins and styles I have my own folder for each tool.

    I think you should first think about what you actually want to accomplish. Do you have a specific scenario that makes you think you should move that data into some separate file/s?
     
  3. CDF

    CDF

    Joined:
    Sep 14, 2013
    Posts:
    1,307
    static classes. I wouldn't rely on file paths if it's a public tool. There's no guarantee your asset is going to live in the root assets directory. I can't speak for everyone but I used to work with some people that would disassemble packages and move them into different directories. i.e Plugins, Scripts, Standard Assets...

    EditorPrefs are good for non volatile settings - cosmetic stuff.
    When loading anything from a Resource, make sure the tool still works if that resource didn't exist.
    But the best thing imo, is designing a tool that doesn't rely heavily on external assets :)
     
  4. Xarbrough

    Xarbrough

    Joined:
    Dec 11, 2014
    Posts:
    1,188
    Thank you both for your answers!

    It seems like most developers go the route of static classes (the official Unity editor code as well), but I still think we should keep localization or content updates in mind (it would be nice to fix spelling errors or change some GUI graphics without having to redeploy my code, but not sure if that's enough of a benefit).

    Just for anyone interested: I tried using the .NET resources system in my custom editor tool library and it worked fine in Unity. Basically, Visual Studio provides a nice editor for simple data types (strings, numbers, etc) and images, which then are generated as type-safe code. The generated resource file can then be embedded into the DLL or put next to it. This seems to be uncommon in Unity, but it might have some benefits. But of course, I'm mainly asking for opinions, because I don't have much experience with the topic in Unity.

    Not specific, but applicable to different tools, I've been developing for my team of student's and might want to polish for release on the store or use at a bigger company:

    • Strings in code don't support localization, which should be an accessibility feature (but probably nice-to-have).
    • Editing strings in code requires a recompile, which gets annoying in big projects (I've been working on tools as in intern for a project with thousands of scripts and scenes with 60k objects).
    • Some data like icons or skins are way easier to create and store as separate files than to serialize them to bytecode or build them entirely in code.
    • It's always nice to store settings where the user can edit/copy/share them.
    • Sometimes, tools require additional data like texture, objects etc, which I need to store somewhere, but then I run into the mentioned problems of either hardcoding paths or searching through the entire project to find them, so maybe there are better alternatives.
    All of my points are more like questions, because I think I have a notion of what I'd prefer, but experience from other developers is probably more valuable. :D
     
  5. dadude123

    dadude123

    Joined:
    Feb 26, 2014
    Posts:
    789
    That's true, but I would never use resource files.
    They are super clunky and the development experience suffers greatly (in my opinion).
    Having to copy over every single string you make? Or if you want to change a string you have to find it in the editor first.. Or even worse a format string!? How can you reliably know what goes where and how each parameter is formatted?
    And stuff like $"{a}" is not supported at all :(

    Imho the vastly superior method is simply using NGettext + an analyzer to suggest (and convert if you want) changes like this
    From: Log("Hello There");
    To: Log(Translate("Hello There"));

    Added benefit: people can actually edit the translation themselves instead of having to compile a resx file/assembly (which lets be honest, a normal user would simply not bother to do)

    See above.
    But I thought this was about editor tools.
    They are in their own assembly.
    And the new AssemblyDefinition files in unity can further segment tools into their own assembly.



    As for the remaining points, I completely agree.
    Merging stuff (whatever it is) into code will always end up being bothersome eventually.
     
    Xarbrough likes this.