This is my current Inventory in studio
And this is what the explorer looks like
I’m not quite sure how fix this, and then my friends said I should just make it all offset. I’m not sure if this is a good idea though as I have no idea if my monitor size is a normal size, so it could look okay on my screen but huge or small on someone else’s monitor.
Should I use offset or scale? I don’t mind having to re-upload the images for tablets, phones and xbox.
I’m already using it. Sorry that I didn’t mention it, I do have it in my explorer image though.
Personally I always use scale for everything, but a combo might work better for this. I don’t think doing all offset is a good idea. It just means you will have to do more scripting to scale it…
How would I use scale and offset together in the Inventory? That doesn’t make any sense to me tbh.
And if I use offset, I wouldn’t use code to scale it. I’d have a different Inventory for mobile, tablets, xbox and pc users.
In the second outcome image it seems like the sides are stretching. Are you using individual constraints per UI element? I personally have a base frame that holds all the UI elements:
Use scale to size and position the rest of the elements since the parent frame’s size ratio stays consistent.
I have a base frame (it’s invisible) with all the other elements inside. The UIAspectRatioConstraint is in the invisible frame.
You want to use… Both. There are many examples of how you can use both at the same time.
As a basic one, you can make something fit the whole screen but have 20 pixels space on each side so it looks nice.
{1, -40, 1, -40}
{0, 20, 0, 20}
This will scale so that there will always be 20 pixels space between the edge of the screen and the element, and the element will scale with the screen size. This is called padding.
Another scenario is that you may want buttons to be a fixed size, and the container frame that actually displays items to scale over the unused screen space. The buttons’ sizes would need to be exclusively in offset, and the container would be a combination of scale and offset.
{0, 200, 40, 0}
{1, -200, 0, 0}
{1, -200, 1, 0}
{0, 0, 0, 0}
This is where AnchorPoints get really useful, as you can easily lock the button’s position to be at the edge of the screen without calculating the exact amount of pixels (200) to position it within view. However, they just complicate things so I recommend you get to grips with everything else before you try learning how it works.
If you haven’t seen it already, it covers a little bit about this:
I’ll be writing 2.0 soon, but until then it should be helpful 
Also: A UIAspectRatio constraint may not be the best option here. If you want something that looks good on different screen sizes, then you want your UI to adapt to those screen sizes, and doing so often means a change in aspect ratio. For example, if it’s on mobile, the UI should cover the entire screen and not just a square in the middle (if you were forcing an aspect ratio of 1:1, for example). So keep that in mind.
Just had a read through this comment and the tutorial you linked and couldn’t really find anything that helped.
Might just be because i’m a total noob to UI.
Might just re-design the ui so i don’t have this problem haha
Hmm, I must have missed that bit when I read it a while ago where you say that we should make different UI for different screen sizes. Is that the best way to make UI? I assumed that most games just use scale so that it works on all screen sizes…
Experiment with scale and offset.
When do you know the exact pixel count on something?
When do you want to place something in relation to the screen?
You need to work on building your intuition for these properties otherwise you’ll struggle indefinitely.
If you’re looking to design a one-size-fits-all interface (i.e. one that will be usable on 4th gen iPhones through to 4k monitors) then you’ll want to mostly use a careful combination of Scale and UI Constraints. Offset is likely to cause you issues when you’re working at the extremes of the range of resolutions.
Try to move away from seeing things like this. You should never base your UI on the platform, and rather on the devices which are active/last used.
For example, if you could detect someone is on a mobile device, it’s important to not assume they will be using touch controls. Use the last inputted device, which could realistically be a gamepad.
Yes, that is still something you want to do. I was just meaning in terms of scaling elements you have that would work cross-platform.
Usually your UI needs to be changed slightly for each of the three main platforms: PC, Xbox and mobile. Often you’ll need to completely redesign frames and stuff you use in situations where the main version wouldn’t be appropriate on a certain platform (i.e. making a custom shop screen for mobile).