Universal Builds Why so complicated?

CaptFinnCaptFinn Member Posts: 1,828
edited November 2017 in Working with GS (Mac)

I have watched 100 videos and looked over 50 template/demos
that explain a different way or view on making Universal Builds.

Why is this so difficult? Why does it cause so many people to come
up with 1000 ways to do it.

The first thing I want my app to do when it is activated on any device is first to ask itself.

What device am I running on? I like the idea of 1 actor doing this.. Someones
method was calling it the "DEVICE CHECKER" Actor.

Device Checker:

Ok Im running on a Ipad.
So that means i need to tell Actors 1 and 2 to go to these X/Y coordinates.
So that means I need Actors 3 and 4 to change these attributes to this and that.

Ok this person is running me on a legacy iphone.
So that means i need to tell Actors 1 and 2 to go to THESE X/Y coordinates.
So that means I need Actors 3 and 4 to change these attributes to this and that.

Ok this person is running me on a Iphone 5
So that means I need to tell Actors 1 and 2 to go to those X/Y coordinates.
So that means I need Actors 3 and 4 to change these attributes to this and that.

What data is being checked that informs the Device Checker Actor that it is being ran on a
ipad or a iphone 4 or a iphone 5 or a iphone 6 or a iphone6+ or a iphone7 or a iphone7+
or a iphone or a iphone 8+ or a IphoneX.

I know most of these have the same aspect ratio and that is why 1 piece of info works for most of them.

But what is this info and where does my Device Checker go to find it?

And why hasnt GS hard coded this into the GSC? ( But that question is for another time. I need to learn how to make a Device Checker work.)

Comments

  • BBEnkBBEnk Member Posts: 1,764

    it's not complicated, quite easy if you ask me.

  • pHghostpHghost London, UKMember Posts: 2,342

    @FINNBOGG said:
    Why does it cause so many people to come

    The reason is that each game is different. In some games you can move the UI buttons only and you're set. But in other games, that might not be an ideal solution, for various reasons.

    Basically, think about what results you are looking for in your app and then you just do the math, which, as @BBEnk says, is not that complicated.

  • CaptFinnCaptFinn Member Posts: 1,828
    edited November 2017

    Right now Im just trying to learn Actor placement. I want the actors to be placed on the real estate properly based on the size and dimension of the real estate. Right now Im focused on X/Y and Size attributes based on real estate. I have been playing around and I "THINK" Ive got it. But Ive hit a weird snag in regards to finding some key info.

    I created a Integer Attribute called "DC" and set it to 0 This is my Device Checker.

    I created a actor that checks a certain attribute and that attribute changes DC to 1 or 2 or 3 or 4 or 5 etc etc. And that info is found by using the game.screen.size.height attribute. I can only get the answer to that attribute if i have it displayed on the device.

    Display: game.screen.size.height.

    On the ipad pro it displays 1366
    On the Iphone7+ it displays 667
    on the iphone6+ it displays 736

    ( this info is only displayed as text when actually testing on the device. Where can i find it in the GSC project inspector?)

    I opened up 3 seperate New project files for ipad,and 6+. And I cant find the info relating to 1366 for ipad or 736 for iphone6+.

    If i could find that info. I would know what to add to the rules for the legacy and the 5. But i cant find the attributes listing the 1366 height for the ipad or the 736 for the 6+ project files.

  • pHghostpHghost London, UKMember Posts: 2,342
    edited November 2017

    I recommend using the aspect ratio (AR) instead of a fixed screen size.

    For example, an iPhone 7 and 7+ have the same AR, so everything will automatically display correctly if its set based on only one of these.

    I would recommend using the regular iPhone as a default setup, what you actually build in your app. That is a 1.777 AR (16:9).

    iPhone X is 2.165 AR.

    iPad is 1.333 AR.

    Those numbers are rough, but they can be.

    So, start your project with game.DC = 1 (i.e. regular iPhone)

    Then two rules.

    IF Numeric Expression: game.Screen.Size.Height / game.Screen.Size.Width < 1.35 THEN Change Attribute: game.DC = 2 (i.e. iPad)
    
    IF Numeric Expression: game.Screen.Size.Height / game.Screen.Size.Width > 2.16 THEN Change Attribute: game.DC = 3 (i.e. iPhone X)
    

    The beauty of using AR is that if you publish on Android as well, it is going to work. With set height dimensions, it won't work on Android and also if Apple changes the size of the screens in the future, it will break the logic. With AR, it will always keep working as long as the screen shape stay the same.

  • CaptFinnCaptFinn Member Posts: 1,828

    Could you create a example file?

  • pHghostpHghost London, UKMember Posts: 2,342

    Is there something specifically that you don't understand?

    I'm attaching a project, but don't know how that will tell you more. The only two rules you need I spelled out already.

    https://www.dropbox.com/s/108pc0j683ezcog/AR Switcher.zip

  • CaptFinnCaptFinn Member Posts: 1,828

    so 1.77 works for 5 all the way up to 8plus? and what would 4 legacy be?

  • CaptFinnCaptFinn Member Posts: 1,828
    edited November 2017

    Is this what you are refering to? and if i wanted to be precise, could i use the 4 digits for each phone.1.775, 1.778 etc etc. And would I use the same number wether its build in portrait or landscape?

  • pHghostpHghost London, UKMember Posts: 2,342

    Yes, the same for iPhone 5-8+, the minuscule variation there is ignored.

    4 would be thrown in the bin. :D

    I suggest ditching Legacy iPhone support, not worth it. But if you want to support it, you'll need another rule for that (that one will need to be a range between iPad and iPhone 5-8+).

    You can use the same number for portrait and landscape, but the rule for landscape will be flipped. Not height/width, but width/height.

  • ToqueToque Member Posts: 1,187

    @pHghost said:

    @FINNBOGG said:
    Why does it cause so many people to come

    The reason is that each game is different. In some games you can move the UI buttons only and you're set. But in other games, that might not be an ideal solution, for various reasons.

    Basically, think about what results you are looking for in your app and then you just do the math, which, as @BBEnk says, is not that complicated.

    Moving ui buttons is one thing. But what about things that are moving in game play?Restricting the game play into the visible area.

    Before the iPhone X i could design iPad size and overscan to please all models.

    Will have to play with what you posted.   
    

    Seems I have to make characters smaller and smaller to fit In that narrow iPhone X window.
    Then a ton more fluff filler around the edges to please the iPad.

    How refreshing to make game jam game and not worry about that size.

    No previewing twice to check iPhone viewing for everything.

  • The_Gamesalad_GuruThe_Gamesalad_Guru Member Posts: 9,922

    Aspect ratios are always difficult to deal with no matter the media. The same issues present themselves in film, video, web et... most of those formats use letterboxing to address those issues. The complications come in that Apple and others do not allow letterboxing as a solution. Letterboxing is the easy fix but since device stores want the apps to correctly cover the whole screen and the devices screen sizes vary, it makes for some complex sorting to achieve a universal fill. This is a device maker issue and not a game software issue. The same problems exist no matter the code engine one uses to produce and app.

  • CaptFinnCaptFinn Member Posts: 1,828
    edited December 2017

    Yes but there has to a simpler way for checking device. And if this device. Actors do this. If that device ,actors do that. It may not bbe that simple. But it must be simpler than current. And since GS is the only ones who have access the the hard code. Then it's up to them figure out how to make that simpler. Granted there are some good work arounds. But I think it's the workarounds that make GameSalad say " ehhh their good with their workarounds. " let's focus on ads instead"

  • pHghostpHghost London, UKMember Posts: 2,342

    @The_Gamesalad_Guru said:
    The complications come in that Apple and others do not allow letterboxing

    I've never had a problem with this, actually. Especially when it comes to designing a game for iPhone first, with the iPad version being letterboxed, no rejections by Apple or Google so far.

  • CaptFinnCaptFinn Member Posts: 1,828

    Yeah I'm liking the iPad to be canvas for all the other devices.

  • pHghostpHghost London, UKMember Posts: 2,342

    @FINNBOGG said:
    And since GS is the only ones who have access the the hard code

    But that's not really true. What you really need to know is the aspect ratio, not what device it actually is. You can easily get the aspect ratio by one simple mathematical calculation (as demonstrated by my project demo).

  • CaptFinnCaptFinn Member Posts: 1,828

    I found a chart. But didn't see the math. But I do like you demo. Checking based on aspect ratio is awesome. Does that mean iPhone X is not longer a concern?

  • pHghostpHghost London, UKMember Posts: 2,342

    @FINNBOGG said:
    Does that mean iPhone X is not longer a concern?

    Not sure (don't have one to test). Now that GS is using the latest SDK to build, it should theoretically work full screen. Before the apps ran letterboxed with a regular iPhone aspect ratio.

    Anyone with access to an iPhone X know more?

  • dapiondapion Member, PRO Posts: 353

    Hi there,

    Yesterday I also tried to change my iphone App into a Universal Build.

    I first created a ratio attribute.
    This asks in my Loading Scene the ratio and sets accordingly the value between 1-3.

    1 - iPhone
    2 - iPhone X
    3 - iPad

    Now I have created separate scenes for each iOS device (iPhone 5-8 / iPhone x / iPad).
    The Ratio Attribute changes automatically after the Loading Scene to the corresponding Scene where I only had to adjust the Screen Size and the Camera.

    I tested it on all devices and it works great.
    In addition, I have created for each device own Actors, so I do not need to make any further adjustments here.

    Now I'm wondering if I've thought it through the end.
    I would be interested to know if any of you have tried this approach before ... with the different scenes.

  • pHghostpHghost London, UKMember Posts: 2,342

    That's a valid way to do it -- though there will be caveats, depending on project.

    The main reason you would build just one scene and then adapt everything mathematically is so that you don't have to manually adjust everything for each device. Especially if you bring out updates in the future, having one scene per device might in some instances mean you need to update all of them one by one (depends on the nature of the update, of course).

    Your way works great for smaller games or those with just a couple scenes in total. I was helping out on a project with over 100 scenes. If you actually had to duplicate all of them twice and adjust the visuals manually in each of them, it'd be a LOT of time spent on it.

    Lastly, I've had some problems in the past with changing the camera size, where graphics are rendered OK, but for example for touch interactions, the device still thinks the actor is in the original -- before camera size change -- position. It was recommended to me to actually change the camera size in the loading scene, just before you switch to the game scene itself.

  • dapiondapion Member, PRO Posts: 353

    I fully agree with you. In larger projects it makes no sense for each device to create its own scene. Add to that your argument with the updates ... understandable.

    In my project, I have a maximum of 5-6 levels, which I have to duplicate.

    What I liked about this approach was the clarity.

    thanks for your feedback

Sign In or Register to comment.