Hey there!
As the development of Makinom 2 (which will be the basis for ORK 3) is progressing, I've been putting a lot of thought into the future of the UI system. Currently, ORK and Makinom support both UI systems of Unity (IMGUI and Unity UI aka legacy GUI and new UI). Naturally, this means the UI system needs to be compatible with 2 completely different systems, leading to a lot of overhead and not so ideal optimization.
There are 2 options on how this will be handled in the future:
- sticking to supporting both systems with the current drawbacks
- dropping the legacy GUI (IMGUI) and going full new UI
Patrons already know about this and voted/commented 100 % in favor of dropping the legacy GUI and going full new UI. I'm also mostly set on dropping the legacy GUI.
How this would work isn't yet set in stone, as I've not really looked into it - most likely it'd remove the need for a lot of the GUI box settings, as this'd be defined by the UI prefabs you set up. HUDs would probably also no longer be set up in Makinom/ORK (or at least not as they're now), rather being built in Unity's UI designer, using components to put Makinom/ORK content in them.
So, what's your thought on this?
Which UI system are you using?
Would you be ok with having to use the new UI in Makinom 2 and ORK 3, and how would your ideal workflow look like?
Please consider rating/reviewing my products on the Asset Store (hopefully positively), as that helps tremendously with getting found.
If you're enjoying my products, updates and support, please consider supporting me on
patreon.com!
One more + for Textmesh Pro from me too. :D
As a general approach, I think it is best to disconnect the UI settings and references from the project file as much as possible -- don't have ORK take away the developer's control of the UI. In any situation, IMO. That's the current struggle with using UGUI with ORK or Makinom.
Ideally, ORK/Makinom would support both using UI displays that were created at design time as well as instantiating a complete UI display prefab. In the latter case, nothing is created programmatically -- it just allows the developer to not be required to have the UI already in the scene.
Instead of having UI settings in the ORK Editor and saved in the project file, just provide a solid demo UI that has examples of the common types of displays. Even better, include 2-3 different versions of displaying the same info using different layouts or visualizations, such as a grid-based inventory display (with full drag-and-drop), a list-based inventory display, and a radial-menu inventory display.
Canvas
Based on my understanding, it is actually not optimal to use a single Canvas for your UI, as anything that triggers a redraw of one UI element causes the entire Canvas to be redrawn. So a HUD or UI Window that is updated every frame might be better with its own dedicated Canvas. But this is probably something best left up to individual developers. Or ORK could have (by default) Background, Default, and HUD Canvases. When ORK needs to create a UI element, it will create it as a child of the specified Canvas.
The Canvas Scaler component handles UI scaling quite well, and I've never had any problems with UI elements getting stretched or leaving gaps where I don't want them. :-) If using multiple Canvases, then you'll need a scaler on each one, of course.
Databinding
Given how many properties/fields many ORK data objects have, it might work best to look into an MVVM-style databinding system that sends notifications when a property is updated.
Without that, you typically end up having a component that contains public fields used to reference the UI elements that need to be updated. This works fine when you have a handful of values to display (or if you're building a UI for one specific game), but an Item or Weapon (for example) has a lot of properties that a developer might want to display in the UI.
Existing databinding solutions for Unity typically have a component that you add to a UI control, specify the data context, and type the name of the property that you're binding to (or the path to it). The better ones also have components that allow you to set up conditional checks such as to hide the player's health bar when his health is full.
In terms of flexibility and scalability, I think this is probably the best approach.
Collections
For collection-based UIs, we would want to be able to build the item UI templates visually, create prefabs of them, and assign that prefab as the template on the parent UI.
Once a prefab has been assigned, it would be very helpful if the main collection display component had a debug/test section (under a foldout, perhaps) with a button to populate the container element (Grid Layout Group, Vertical/Horizontal Layout Group, etc) with X number of item templates and a button to clear the container element. It's very useful for testing how everything fits without having to run the game.
TextMesh Pro
TMP is so much better than stock Unity text it's not funny. It's really hard to go back once you've used it. It's available for free through the Package Manager in Unity 2018, but it's not installed by default.
One gotcha when using TMP is that it comes with its own Assembly Definition File (.asmdef), so while it used to be easy to just build a "smart" component that used a #if TMP_PRESENT directive to skip over compiling the reference to TMP if it was not present, it will fail when using .asmdefs. So one might need different components for binding to a TMP Text element as opposed to a Unity UI Text element.
I suspect that I didn't touch on everything that I wanted to say, but that's all I can think of at the moment. :-)
Also, forgot to mention this in the initial post - using TextMesh Pro is already planned.
If you're enjoying my products, updates and support, please consider supporting me on patreon.com!
Olive Branches ~ in development ~ now with a WEBSITE!!!
ORK currently is just 2.26 so I think it not gonna happen anytime soon.
Maybe 1-3 year from now :) That my guess.
Or maybe sooner if he just decides to just drop ORK 3 out of nowhere :)
Also, there are some other major features coming in ORK in the next 3-6 months, so ORK 3 is postponed for some time :)
If you're enjoying my products, updates and support, please consider supporting me on patreon.com!