Multi-Resolution Game Development With GameBuilder Studio Check it out!
NEW Version 0.9.7 has arrived! New Blazing Fast Particle Engine & More Game Actions. Check it out
Positioning UI elements for variable screen sizes.

  • When a game goes to the GAME_OVER state, using the interpolate action to move a button onto the RIGHT-side of the screen I can use this:

    From:  Game.Screen.width + 400
    To:   Game.Screen.width - 200

    This way the button will always be 200 pixels in from the right no matter what device the game is played on right?

    How can this be done for having a button set to move say 200 pixels in from the LEFT-side of the screen also? as Game.Screen.width seems to have us working off the right edge of the game screen.

    Anyone know where one could look these kinds of equations up? 
  • 28 Comments sorted by
  • I'm going to take a shot in the dark on this one. Only way is to test test test, but

    your equation for the left should be 
    From:-400
    To: 200

    This would essentially give you 200 pixels on the left.

    Hope this helps
  • @Carlton Yes that is what I have as well. I haven't a handful of devices to test with for comparison, just one at the moment which is what got me wondering. So maybe Game.Screen.width is better used when centering an entity ( Game.Screen.width / 2) as you mentioned in another post and for working off the left or right side of the screen we only require for example:
    From:-400
    To: 200

    I appreciate you insight, thanks again!
  • I'm in the same boat for device testing I have a Moto G, nexus 7 and an Ipad 1. When it comes to screen sizes with GBS I've usually looked up what resolution I was trying to target and then under publish change my screen sizes to see how it would look. 

    Also when it comes to different screen sizes remember to use power of 2(still not too clear on what it does) but it allows for you image to resize correctly to whatever resolution the screen is....i think.

    good luck
  • @Carlton correct! You may also want to use the conversion helper in the expression that converts inches to pixels when sizing buttons for example for different screen resolutions. It will take resolution into account when returning pixel size.

    @BenFromOregon, yes the left side of the screen always starts at 0 so if you want something to fly in you start with a negative value then move to the positive. Same goes for the vertical coordinate space. If you want something to fly in from the top you would use a negative value in the Y.
  • @Lavon when it comes to power of 2 does the whole image need to be power of 2 or just the x or y axis? i know for scrolling the whole image needs to be power of 2 but i'm not sure about just basic spatials.
  • @Carlton changing the screen size under publish settings is a great tool to test with, I forgot we could do that, Thanks for mention it!

    @Lavon Yeah I understand this Thanks! and the publish settings ability to change screen size really helps realize how tricky it can be to accommodate for so many sized devices, especially the small screens, wow.
  • @Lavon I have built my game with a screen size of 1280 X 720 and have been testing it on a Moto G, every things is coming along nicely so far.

    In the Publish Settings tab I was changing the screen sizes around to see what the game would look like when I click launch.
    I tried something smaller and larger, an old iPhone 4 @ 960X640 and the samsung galaxy S5 @ 2560X1440, and then a few others.

    In the 2560X1440(Samsung Galaxy S5) screen size or other large screen sizes, my game shows up in the top left corner now with tons of grey empty space exposing all the previously off-stage entities to be spawned etc.
    as the backgrounds in the game remain the same size they are with the origional 1280X720 screen size I built the game for.
    My background images are scrolling and a power of 2.

    Is this what will happen when someone with a Galaxy S4 or S5 plays it ? 
    Or will the images scale at all? Thanks, still new at this.
  • @BenFromOregon I've noticed the same thing too.

    What I did to try to tackle this is to create a resolution that was pretty much highest res that was on the market for tablets.

    Maybe its just my games so far, but I find that they can downscale fine but upscaling is an issue. Also when releasing to different platforms. (this however means that everything on the screen needs to be calculated and placed as opposed to just dragged there.)

    I usually release a standard version that is for 7 inch screens or less and then an HD version which is for tablets.

    Also when I release I make sure to publish for any screen size when it comes to android.
  • @Lavon Wow, so my background images which are scrolling sprites( 1280X720) are pretty much worthless then right? because if someone plays my game with a screen that is 2560X1440 (Galaxy S5) the scrolling sprites won't scale automatically and the user will see all the previously off-screen to-be spawned during the game images?

    Then do we have to create all original art for say something big like 2560X1440 (Galaxy S5) and then somehow get it to recognize the device a the game is played on so the art will scale down?

    @Carlton When we release a version off our game on Google Play for example and then anyone can download it with all number of devices how can we publish for any screen size when there is only one game(App) in the store for people to download?
  • @Carlton, @BenFromOregon, What you guys are talking about is Multi-resolution support. Multi-resolution support is not yet implemented. It is on the roadmap for v1.0 which is in the next two releases.

    @BenFromOregon Yes, When the stage is resized all assets will stay in the top left corner and the screen will expand from left to right. In theory the way multi-resolution support will work is by providing your assets at various scales. Then you will be able to set the game to scale mode which will maintain a set coordinate space but use the higher resolution assets for larger screens. 

    The other approach is to use the same resolution assets and dynamically position and size objects based on the current screen size and resolution at runtime. This is a bit more tricky. There are some helper expression methods that can help you to calculate the desired pixel size based on inches. So if you want to have a button that appears the same 1 inch in width on both small screens and larger screens you can feed the calculation through the helper method and it will return the correct pixel width based on screen resolution to maintain a 1 inch size on both screen types.
  • @Carlton, that is also a good approach to start with the largest target screen size and then downscale. 

    To get a good understanding of how the multi-resolution support will work in GameBuilder Studio review the Starling wiki page on the topic: http://wiki.starling-framework.org/manual/multi-resolution_development
  • @Lavon when you say "Yes, When the stage is resized all assets will stay in the top left corner and the screen will expand from left to right" are you saying currently a device with a larger screen size and higer resolution will automatically get filled and that the images would simply just look of a lower quality than it was created?

    So creating a high res image from the start, seems best for the long run of scaling down verse up corecct.

    Thank you for clarifying, this seemed better to srtaighen out now verses after a release:)
  • @BenFromOregon Your images won't be of poor quality on higher resolution devices but they will just appear smaller. If you were to dynamically scale up a smaller size image on a larger resolution device then it would look of low quality. 

    Until multi-resolution support is integrated you can't scale up your game but you can scale down. This whole process will be made easier once we have multi-resolution support in GameBuilder Studio.
  • @BenFromOregon I just finished wrapping up one of my games last night and this is usually the last process I go through. Let me take you through my scale down process

    1. Strategically place all of your resolution points on your spatial (i.e) I had sign in the bottom right corner so I set my resolution point to the spatial.width and spatial.height. Anything that I wanted centered I would just make sure my resolution point was spatial.width/2.

    2.Set your background pieces to be size of the width and height of the screen. Take your scrolling pieces and set the size of them to be the width of the screen.

    3. Positioning This gets a little tricky. Mostly everything is a guess estimation i.e spatial.position=setpoint(screen.width/2+250,screen.height/2). Also remember that you are positioning based on your resolution point.

    4. If you have any boundary or hidden boxes make sure to position those correctly as well.

    To make this easy use a spatial block and call it positioning and onload position and arrange everything that needs to be moved or changed.

    Downsizing is a must for android. For Iphone if you wanted to you could just re-position and set everything up its only 6 different screen sizes.

    try sizing at 2560 x 1600 (12.2 inch screen) if thats overkill then just do 1920 x 1080.

    Also remember to think about pausing and stopping all background noise if you need help with that just ask.



  • @Lavon. Thanks Lavon, I was just concerned if the game stage ended up being smaller on a higher res device, that the player would be able to see characters which would be spawned during the game which are setting right outside the game stage that is all.
  • @Carlton Thanks for the thoroughness, when I get to a point of understanding all of this completely maybe I'll make some video tutorials for keeping workflow simple for those new to all this.

    I get the positioning of everything specifically related to Game.Screen.width and height and centering is great.

    Setting a resolution point sounds interesting,

    When you mention adjusting a game for six different ios screen sizes, all those six variances can be bundled inside our one app that goes on the app store?

    Again I appreciate all the help from you and Lavon as well and hope to feed back into the community more when I have a greater understanding.


  • If I understand this correctly, we can have different profiles for different screen sizes in the same game project and each one of these would be it's own .gbx file.
    And then when someone downloads the game from a store the appropriate  .gbx file for the users device will run.
  • @BenFromOregon, currently the multiple profiles in GBs allows you to specify different deployment settings for different platforms if you want to from one project. You currently need to manually switch to each profile and hit publish or deploy which will build the game and generate the install file for that target platform. Eventually there will be a build all button which will generate an install file for all your platforms at once.
  • @Lavon 
    Hey thanks, 
    I didn't realize that we could make more than one install file(which I assume is the .gbx file)
    so our game will be looking correctly for different target platforms all in one project.
    For example I can have files MyGame_size1.gbx, MyGame_size2.gbx, MyGame_size3.gbx, and so on all in one project for Android and then adjust and do the same for the iOS versions.

    This clears up a lot now thank you.




  • @BenFromOregon, not sure I'm being clear but the install file is not the .gbx file. That is your project file. When you hit publish from the publish window it will generate an install file for the target platform and put it in the output location you specify. So if you have 3 different profiles setup you need to switch to each profile one at a time and hit publish one after the other to generate a different install file for each target platform.
  • Okay, I have never clicked publish yet (only deploy for testing so far)
    Then after I do all that i.e: create 3 different profiles one at a time and publish one at a time, then after it is all done and sent to an app store, will a customers device recognize which install file to use within our app? Or will there be separate apps in the store for different device profiles? This is what I am unclear on.

  • @BenFromOregon, it is up to you. For iOS app store you can create one app for iPhone only and on for iPad only or one "Universal" app for both devices but you have to make sure you handle all the scaling and repositioning correctly based on the current screen size.
  • @BenFromOregon, deploy does the same thing as publish. It creates the install file first then it just takes it one step further and actually installs the file onto the selected device.
  • @Lavon 
    Right, and with Google Play would we have one "universal" app that has multiple install files within it or would we have to have multiple apps of the same game for different profiles on the Google Play store like one for a smaller screen size and then another for a large screen size. as you mentioned  with iPhone only and iPad only.

    I just ask this as Carlton mentioned he would create for six different profiles, so are those all six separate options(apps) for a consumer to choose from to download from the app store or are all six profiles within one "universal" app on the app store?

    Pardon my confusion.
  • @BenFromOregon, that depends on how you have built your game. Do you have logic in your game to scale down assets and reposition them depending on screen size and resolution?
  • @Lavon I have only figured how to reposition assets(working off center or the sides of screen), I couldn't figure out how to scale assets for detecting a device resolution which is why I am guessing i would have to build a handful of profiles. I just didn't know if having multiple profiles as individual install files would end up all in one app or if I can only have one install file per app in a store that's all.


  • @BenFromOregon, ok so in your case if you are publishing to android and you are not automatically down-scaling and repositioning your game objects then you will need to specify/target a specific screen size and create a separate project  with different asset sizes for each target screen size. This is required currently because multi-resolution support is not there yet. This approach does require multiple install files that target the various android size profiles, small-screens (approximately 2 to 3 inch device), normal-screens (approximately 3 to 5 inch device), large-screens (approximately 5 to 7 inch device), and xlarge-screens (approximately 7+ inch device).

    Here is the problem :), currently in GBs all screen sizes are supported by default on Android so what I will have to do is have the configuration settings for the device size filtering exposed in the publish settings for android in the next build. This will allow you to set which target device size you are publishing your game for. Which will be different for each project variation you create.

    The approach that Carlton is taking allows him to use one project and one install file because he is building his game at the largest resolution then scaling down his assets when the game is on smaller devices. This approach works with the current configuration of GBs because the one install file that he generates/publishes can be put on the market and used for all the various android devices. He is making the necessary position adjustments and scaling at runtime.

    The multiple profile support in GBs currently should only be used if you are using the same project and down scaling per device or to target multiple platforms such as building a game for both Android and iOS at the same time and using the same size assets across platforms. Once multi-resolution support is added then you can also create a separate profile within the same project for different screen sizes and resolutions. This is one of the hardest parts of mobile game development for multiple devices which we hope to make a lot easier.

    Hopefully this makes things clearer about when you need multiple install files and when you can use just one?

  • @Lavon Yes thank you it is much more clear. So for the time being the approach Carlton uses is probably best to keep the overall apps final file size down huh? Have you any idea where would one would look to educate oneself to learn this technique for scaling down assets at runtime? , action script or flex? I have no idea . . .obviously :)

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

In this Discussion