Closed f-montanari closed 7 years ago
A moddable UI I think is highly desirable, if only swapping out the button sprites. But there should be some consideration given to localisation to. Making sure buttons are growable to allow for different word lengths. See issue 25.
I was actually thinking about using icons to describe what that element is, rather than just text over a button (maybe a tooltip over the UI that does have the localization script?)
While using icons means the player have to 'learn' what each icon means. The icons could help fight screen-space clutter - that obviously depends on how it is done.
Personally I support the icon approach with hover tool-tips, but there is a problem with touch-screens where you can't hover a icon to get the tool-tip.
Text is far better that icons in my opinion. But the best is combination of both.
Could you give an example of why "Text is far better"?
It is way more intuitive, and you dont have to spend time hovering over the icon to know what is even does. Or in worst scenario, you will click it thinking it will do something else because you havent understood it propelly.
While I won't ever agree that it is more intuitive.
I agree that text can be more descriptive, but if you play the game more than a couple of times icons will make up for any misconceptions pretty fast if done right.
I still prefer icons with tool-tip than text, that in mind the icons should be distinct and well crafted.
@Tranberry good icons will do but they have to be really good
That's the thing. The class I made just looks for the button sprites outside the Unity's asset bundle and loads them from the streaming assets/UI folder. I made a (pretty awful) example of the way it could be modified, so that other people can make decent graphics (not mines, of course). As soon as I get home, I'll upload a screenshot of how it all looks
ok, sound good (the graphics wont be mine too :smile: )
When the project is in development I see no reason to **not**\ have place-holder icons or "programmer art" icons for that matter.
As a graphic guy myself I believe that UI graphics* is for Release Candidates.
*Optimized
and graphic/ux artist crafted that is.
**oops
I'd commit just the UI icons, before implementing the tooltip feature, that is until localization is implemented...
I think we could use kenney's space pack. Or not. Furniture should have a tooltip for sure though.
Kenney's space pack is great place-holder graphics.
Yes, although my goal was to get rid of the text in the buttons and replace them with icons, so it could be universally recognizable. Also, when translating the project we'll find things that don't fit in those buttons
If there's a icon you need just describe it and I might be able to make it.
@tranberry I will :) although it seems like my pc needs a good format (I can't even install github), so it wont be soon...
OK, I managed to get a backup of the previous episodes and apply the changes I was talking about... However I still can't clone the repo in my computer, it's a weird GitHub for Windows bug, still trying to resolve this. Anyway I made a couple screenshots so you can see it here.
What do you think @quill18 ??
@frankitox16 perhaps switching to sourcetree could help, if you like it? I work on a daily basis with it and its a bit superior (at least in my mind) over the GitHub client but looks not that sleek.
Back to the UI Stuff i did not really work with the new UI but does it support from the scripting side the same Feature which you could archive with IMGUI? I know the new one heas nicer looks and transforms but in a 2d Environment the ability that everything could be handled in Code especially when multiple people work on the same stuff should make the process a lot more easy.
I looked through the Manual but all they show there is Editor stuff not raw code perhaps its to late for me to find it, than i am sorry ;)
@tuefekci as far as I've seen, it seems like they work like normal GameObjects with special UI Scripts... The big problem is the resizing of the buttons because they stretch to the parent panel (the way quill organized it, that is) and in order to make a button resize, you've got to resize the panel (which will also resize the other buttons that are child of the same problem). This way if you want to have a different width or height for a special button, you've got to take it away from that panel and find a way to anchor it correctly. That's the actual difficulty that I had to work around (which involved moving out the "build furniture" buttons out of one panel).
In PP age, this is ancient. Closing in favor of newer issues.
Hello everyone! I guess we're all excited for adding our custom content for this project. Right now almost everything is moddable thanks to quill but... not the UI! It's fine, but we know it could be better. So around episodes 67-68 of the series I took time to make a generic class to load UI sprites and change the actual ones in the UI system.
However, Unity's UI System is a bit funky (because of the way UI elements snap to the screen), so loading sprites and matching element's with their corresponding width and height is a bit a pain in the a**. That's why I wanted to kind of suggest a "convention" or a series of rules that the UI should follow in order to make modding it a bit easier, as well as naming the sprites correctly so everyone can upload their custom mod and add the corresponding UI reference easily.
So, what you think?