scaling group objects - and moving from country to country on a world map

[sizeoverload]

Hello, I have a group of images that represent a world map in my game. In my game, the player is focused in on a particular country at a time with the country positioned in the center of the screen. After a short period of time, another country is chosen. I’ve created coordinates (in cf_game_settings.lua) for each country and some math code in game.lua that use these coords to determine how much to move the map group in the x and y directions.

The next code that I’m working on creates the illusion that the player is getting further from and then closer to earth as the country changes. I’m running into some issues here… In the code you’ll see my attempt to manipulate two properties simultaneously:

1. change that map group’s x and y values.

2. scale the map group’s size (up and down)

To help me do this, I have chained two transition.to() functions together, thus creating a two-part movement. 

In the first transition.to() I set the x and y values, moving the map group so that the halfway point between the two countries is centered on the screen. To increase the size of the map group I use a multiplier.

In the second transition.to() I set the x and y values, moving the map group so that the next country is centered on the screen. With the multiplier, I return to the map group’s original size.

I’ve made a video to show you what I currently have! I’m proud of myself for getting this far on my own, but I’m aware that there are some issues - mainly that the scaling of the map group throws off the accuracy of the math used to determine the values that x and y will be set to. Because of this, the map group seems to move way out of its way, especially when moving between two countries that are close to one another. Even more so, if the randomly selected country happens to be the current country, the map group is moved so that the country moves away from the center of the screen before coming back to the center.

https://imgur.com/a/jDN5VdB

Here’s the code:

cameraevent.lua

local cameraEvent = {} function cameraEvent.focus(transitionToCountryDuration, country, countryFill, previousCountry, previousCountryFill, mapGroup) local transitionToCountryDuration = transitionToCountryDuration local country = country local countryFill = countryFill local previousCountry = previousCountry local previousCountryFill = previousCountryFill local mapGroup = mapGroup local zoomMultiplier = .3 local xCoord=(\_W/2)-(country.coords.x\*zoomMultiplier)-((countryFill.width\*zoomMultiplier)/2) local yCoord=(\_H/2)-(country.coords.y\*zoomMultiplier)-((countryFill.height\*zoomMultiplier)/2) local previousXCoord=(\_W/2)-(previousCountry.coords.x\*zoomMultiplier)-((previousCountryFill.width\*zoomMultiplier)/2) local previousYCoord=(\_H/2)-(previousCountry.coords.y\*zoomMultiplier)-((previousCountryFill.height\*zoomMultiplier)/2) local distanceX = xCoord - previousXCoord local distanceY = yCoord - previousYCoord print(distanceX) print(distanceY) zoomMultiplier = .24 local mapTimer = transition.to( mapGroup, { transition=easing.inCirc, time=transitionToCountryDuration/2, x=mapGroup.x + distanceX/2, y=mapGroup.y + distanceY/2, xScale=1\*zoomMultiplier, yScale=1\*zoomMultiplier, onComplete=function(event) zoomMultiplier = .3 mapTimer = transition.to(mapGroup, { transition=easing.inCirc, time=transitionToCountryDuration/2, x=xCoord, y=yCoord, xScale=1\*zoomMultiplier, yScale=1\*zoomMultiplier }) end }) end return cameraEvent

I’d be super thankful to anyone willing to take a shot at this as I know that it is a huge chunk of my game hahaha and probably not such an easy feat either.

[XeduR]

That’s looking quite cool. Also, this is the perfect place to drop this video.

Well, maybe we don’t need to use that much math. Just throwing this idea here without taking a deep dive into your code itself. I am quite certain that you are seeing this behaviour because your display group’s centre doesn’t share its centre with the actual map.

Here’s a code example of what I mean:

local rect = display.newRect( 200, 200, 100, 100 ) local group = display.newGroup() group:insert( rect ) local function finish() transition.to(group, {time=1000,xScale=1,yScale=1,x=group.x+100}) end transition.to(group, {time=1000,xScale=0.5,yScale=0.5,x=group.x+100,onComplete=finish}

The first transition should move the rect to the right and scale the rect down. What you actually see is the rect moving up on the y-axis and being scaled down. The second transition then returns it to scale and moves it right (and “back down” on the y-axis).

This is all occurring because the display group’s origin is at the 0,0 point (see documentation), which means that as the display group is scaling down, the rect, which is to the right and below of the 0,0 point, is moving left and up to accompany that change. Once the display group scales back up, this distortion is fixed.

Now, you could fix this issue by doing the calculations to offset the distortion. You’d need to calculate how much the distortion is going to move the map and to which directions and do your transitions accordingly.

Or, alternatively, you could take a peak at roaming gamer’s github folder or search these forums. There was a question regarding zooming to some object on the forums some time ago and I think that Ed created a sample project for it and that addresses this very issue.

[anon63346430]

Nah it’s easy, you just need to approach it differently…

Always move the objects in the group (relative to the centre) rather than moving the group.  Then your zooming will always work against the origin.  So 0,0 (relative to the group) is always centre of the screen.  So instead of moving the group by x = -100 you move all the children by -100.

You can abstract this further by rendering to a snapshot and then zooming the snapshot.  You can then also add filter effects like a blur for some extra polishing.

[sizeoverload]

@XeduR

That’s looking quite cool. Also, this is the perfect place to drop this video.

Well, maybe we don’t need to use that much math. Just throwing this idea here without taking a deep dive into your code itself. I am quite certain that you are seeing this behaviour because your display group’s centre doesn’t share its centre with the actual map.

Here’s a code example of what I mean:

local rect = display.newRect( 200, 200, 100, 100 ) local group = display.newGroup() group:insert( rect ) local function finish() transition.to(group, {time=1000,xScale=1,yScale=1,x=group.x+100}) end transition.to(group, {time=1000,xScale=0.5,yScale=0.5,x=group.x+100,onComplete=finish}

The first transition should move the rect to the right and scale the rect down. What you actually see is the rect moving up on the y-axis and being scaled down. The second transition then returns it to scale and moves it right (and “back down” on the y-axis).

This is all occurring because the display group’s origin is at the 0,0 point (see documentation), which means that as the display group is scaling down, the rect, which is to the right and below of the 0,0 point, is moving left and up to accompany that change. Once the display group scales back up, this distortion is fixed.

Now, you could fix this issue by doing the calculations to offset the distortion. You’d need to calculate how much the distortion is going to move the map and to which directions and do your transitions accordingly.

Or, alternatively, you could take a peak at roaming gamer’s github folder or search these forums. There was a question regarding zooming to some object on the forums some time ago and I think that Ed created a sample project for it and that addresses this very issue.

Wow, I tried this snippet out, great way to illustrate what’s going on. Thank you.

Still pretty confusing how manipulating the x= in the first transition.to() is able to push the square up. Also, can you explain why you use group.x? Isn’t this just 0.

[sizeoverload]

Thanks SGS, your solution worked for me.

By restricting all object translations to the child objs of my group while keeping the group scaling (xScale and yScale on the group), I was able to get the results I was hoping for…

Now, when traveling between two countries in close proximity or even traveling to the same country, the camera does not stray away from that country!

[XeduR]

That’s looking quite cool. Also, this is the perfect place to drop this video.

Well, maybe we don’t need to use that much math. Just throwing this idea here without taking a deep dive into your code itself. I am quite certain that you are seeing this behaviour because your display group’s centre doesn’t share its centre with the actual map.

Here’s a code example of what I mean:

local rect = display.newRect( 200, 200, 100, 100 ) local group = display.newGroup() group:insert( rect ) local function finish() transition.to(group, {time=1000,xScale=1,yScale=1,x=group.x+100}) end transition.to(group, {time=1000,xScale=0.5,yScale=0.5,x=group.x+100,onComplete=finish}

The first transition should move the rect to the right and scale the rect down. What you actually see is the rect moving up on the y-axis and being scaled down. The second transition then returns it to scale and moves it right (and “back down” on the y-axis).

This is all occurring because the display group’s origin is at the 0,0 point (see documentation), which means that as the display group is scaling down, the rect, which is to the right and below of the 0,0 point, is moving left and up to accompany that change. Once the display group scales back up, this distortion is fixed.

Now, you could fix this issue by doing the calculations to offset the distortion. You’d need to calculate how much the distortion is going to move the map and to which directions and do your transitions accordingly.

Or, alternatively, you could take a peak at roaming gamer’s github folder or search these forums. There was a question regarding zooming to some object on the forums some time ago and I think that Ed created a sample project for it and that addresses this very issue.

[anon63346430]

Nah it’s easy, you just need to approach it differently…

Always move the objects in the group (relative to the centre) rather than moving the group.  Then your zooming will always work against the origin.  So 0,0 (relative to the group) is always centre of the screen.  So instead of moving the group by x = -100 you move all the children by -100.

You can abstract this further by rendering to a snapshot and then zooming the snapshot.  You can then also add filter effects like a blur for some extra polishing.

[sizeoverload]

@XeduR

That’s looking quite cool. Also, this is the perfect place to drop this video.

Well, maybe we don’t need to use that much math. Just throwing this idea here without taking a deep dive into your code itself. I am quite certain that you are seeing this behaviour because your display group’s centre doesn’t share its centre with the actual map.

Here’s a code example of what I mean:

local rect = display.newRect( 200, 200, 100, 100 ) local group = display.newGroup() group:insert( rect ) local function finish() transition.to(group, {time=1000,xScale=1,yScale=1,x=group.x+100}) end transition.to(group, {time=1000,xScale=0.5,yScale=0.5,x=group.x+100,onComplete=finish}

The first transition should move the rect to the right and scale the rect down. What you actually see is the rect moving up on the y-axis and being scaled down. The second transition then returns it to scale and moves it right (and “back down” on the y-axis).

This is all occurring because the display group’s origin is at the 0,0 point (see documentation), which means that as the display group is scaling down, the rect, which is to the right and below of the 0,0 point, is moving left and up to accompany that change. Once the display group scales back up, this distortion is fixed.

Now, you could fix this issue by doing the calculations to offset the distortion. You’d need to calculate how much the distortion is going to move the map and to which directions and do your transitions accordingly.

Or, alternatively, you could take a peak at roaming gamer’s github folder or search these forums. There was a question regarding zooming to some object on the forums some time ago and I think that Ed created a sample project for it and that addresses this very issue.

Wow, I tried this snippet out, great way to illustrate what’s going on. Thank you.

Still pretty confusing how manipulating the x= in the first transition.to() is able to push the square up. Also, can you explain why you use group.x? Isn’t this just 0.

[sizeoverload]

Thanks SGS, your solution worked for me.

By restricting all object translations to the child objs of my group while keeping the group scaling (xScale and yScale on the group), I was able to get the results I was hoping for…

Now, when traveling between two countries in close proximity or even traveling to the same country, the camera does not stray away from that country!