[quote:2dkp5yjo]

but doesn't the main candy area never move when flipping between landscape and portrait?

The main candy area has to move because the north to south changes when the orientation changes and so the candies then must then drop in another direction.

In Construct 2 itself, I think I can compare Window Height and Window Width and place the HUD elements accordingly. It's the balls/candies that is the problem.

— - "I'm guessing you probably want to do something like Candy Crush Saga does."

I am actually following a tutorial I found on Tutsplus by David Silverman. I finished it and then I did think of Candy Crush and how those types of games work in any orientation. So I am wondering how it would work here.

" It switches around HUD parts based upon landscape or portrait. "

Are you saying that if I design for landscape mode, the portrait mode will take care of itself? Could you elaborate a bit - this part isn't not clear to me. I am just not getting how the balls will land up in the right place when the device is rotated.

Thank you so much for your reply.

My plan is to design for 480x320 (landscape mode) and make the background big enough to account for the other aspect ratios using scale outer. Further, I plan to place the GUI elements (score, lives and other stuff) by using Anchor. The individual balls are placed placed in a grid, separated by a certain distance from each other.

My problem is I am not sure of what happens when the mobile device is rotated and the screen becomes 320x480. How are the balls affected? What do I have to do to make sure that they end up in the equivalent position when the device is rotated and the game continues uninterrupted?

Bumping the thread in the hope that someone might have the answer I'm looking for.

Thanks for your reply. But with using Letterbox, isn't there a chance of black bars appearing down the sides, when the aspect ratio of the device is different from the one I designed my game with?

Hi,

After running into several problems trying to make my own very first game, I decided to go back to the basics and now an working through any and all tutorials I that might have something to do with my game. I just finished a really good Match-3 game on Tutsplus - very detailed and informative.

Now, I am thinking, is it possible to make a Match-3 game possible in both orientations simultaneously? That is, what happens when the player rotates his device mid-play?

The GUI elements won't be that difficult to handle, I think. But what about the individual balls. How to make sure that they end up in the right position when the device is rotated?

Any and all help will be very appreciated.

Thanks for your reply. Very informative. Situation sounds dire indeed.

So what to do for newbies like me who has a cool idea and would like to see it implemented. But in today's age with so many games coming out every month, what chance my game have of succeeding without a big name publisher?

I have been playing with Construct for a couple of month just as a hobby and came upon what I think is a pretty cool idea. And after a couple of weeks, I have hammered together a rough copy of the game that works. Now of course, before I even think of publishing it, I'll have to buy the commercial version which I intend to. And after that, I probably will have to approach a few publishers with it. Now do any of them have a problem accepting games made in Construct. What about Chillingo in particular? Will they accept my game? And what about any of the other publishers? Which ones are good with newbie developers?

Any help will be deeply appreciated.

Okay, I came upon another snag. I was doing a few test to see what happens when more than one ball in one column is destroyed simultaneously. It turns out the ball above do not fall into place as it should. So what to do?

https://www.dropbox.com/s/6z397fr1x4el0dd/Movement.capx

p

Thanks for the tip about using a new Layout, called "Unused". It's really helpful.

As for my game, the blocks won't actually look like that or be separated by 100px. I just created a quick layout to get my idea across.

Thank you so much, Bertie Booster! You're a lifesaver.

I used your method and it worked. I had to tweak it a little and I think I found a working solution. The capx is below. I really can't thank you enough.

https://www.dropbox.com/s/6z397fr1x4el0dd/Movement.capx

The math works on paper but in the game, the sprite never end up exactly 100px down. It's usually something like 98px to 100px.