Rotation orientation uderstandation

[isTrigger]

Let’s the default orientation is “landscapeRight”.
Now, create a group.

local groupA = display.newGroup ()
   
groupA.x = display.contentWidth/display.contentCenterX
groupA.y = display.contentHeight/display.contentCenterY

-- By the way, does a group need any anchors?

Create some objects. Only some.

local obj1 = display.newRect (groupA, x1, y1, 100, 100)
obj1:setFillColor (1, 0, 0)

local obj2 = display.newRect (groupA, x2, y2, 200, 100)
obj2:setFillColor (1, 1, 0)

local obj3 = display.newRect (groupA, x3, y3, 100, 200)
obj3:setFillColor (0, 1, 1)

Describe a very special funcktion.

local function onOrientationChange (event)
   local currentOrientation = event.type
    
   if currentOrientation == "portrait" then
      transition.to (groupA, {rotation = -90, time = 1000, yScale = -1})

   elseif currentOrientation == "portraitUpsideDown" then
      transition.to (groupA, {rotation = -90, time = 1000, xScale = -1})

   elseif currentOrientation == "landscapeLeft" then
       transition.to (groupA, {rotation = 180, time = 1000, yScale = -1})

    elseif currentOrientation == "landscapeRight" then
       transition.to (groupA, {rotation = 0}) 
-- Or how to set the default orientation again?

 end
end
Runtime:addEventListener ("orientation", onOrientationChange)

Well, it doesn’t work properly. Where is my wrongation?
Don’t say, that my own deep mistake was getting started to use Corona/Solar2D SDK, OK?!
Thank you.

P. S. The plot of my new exciting game: a gamer (or a gameress) must rotate a device to solve the puzzle. The GUI frame, that has special lacunas and niches for the puzzle pieces, must be oriented like a screen everytime. Directed by Robert B. Weide.

[roaminggamer]

I didn’t see you say what you expected it to do. You told us the problem you want to solve, but not what you expected to see when the orientation changed.

I suspect I know what you want, but I not big on guessing.

Question: Is this a ‘ball in a maze’ game where orientation is supposed to allow the ball/puzzle piece(s) to fall through the maze? Maybe you can link a game in GooglePlay that is similar.

[ldurniat]

Hi @isTrigger,

Do you read gotchas for orientation event?

• On Android, if your app only supports one orientation in build.settings , the orientation event will still be triggered for all device orientations. However, if your app supports two or more orientations, the orientation event will only be triggered only for the app’s supported orientations.
• There is a limitation in the Android OS where it will never report an orientation event when flipping between "landscapeRight" and "landscapeLeft" , nor will it be reported between "portrait" and "portraitUpsideDown" .

Which orientations support your application?

Have a nice day:)
ldurniat

[roaminggamer]

You might be better served making a tiny demo we can download, then tell us:

1. What you did (the demo will stand in for this).
2. What you saw (when you ran it)
3. What you expected to see.

Knowing that and having something to run ourselves, we can probably more easily help.

Question: What are you hoping this calculation will do?
display.contentWidth/display.contentCenterX

PS - The demo only has to have a the basics:

• build.settings & config.lua you are using
• main.lua with one or more groups
• rectangles in the group as you expect them to be in on orientation.
• code to re-orient the view.

[roaminggamer]

Note: If you’re trying to rotate groups and keep them in the center of the screen, then the <x,y> position of the group needs to be the center of the screen and objects need to be placed in that group with knowledge that they are being placed relative to center.

If you rotate a group whose position is in the upper-left corner of the screen, most of the group will flip off-screen.

[isTrigger]

[isTrigger]

[roaminggamer]

Short answer 1: That last image is not a game where the device is being rotated. Instead, the group containing the ‘in place pieces’ is rotating, then a piece is being dragged and placed.

Long answer: It is the workweek for me so I have to do my day job, but I’m pretty sure I could reproduce that exact mechanic. I’ll post back this weekend on what I find.

My first thought is:
a. Place two groups in the center of the screen: solved_group, piece_group (above solved)
b. Fill solved_group with solved puzzle, where the puzzle is made up of discrete pieces.
c. Identify pieces that will be ‘removed’ to make the puzzle.
d. Rotate group randomly by 0, 90, 180, 270.
e. Normalize the rotation to a range [0, 360)
f. Randomly choose one piece identified in step c.
g. In fields on that piece, note this info: obj.x0 = obj.x, obj.y0 = obj.y, obj.group_rot = group.rotation.
h. Place the piece in piece group at <0,0> and rotate the piece to be: piece.rotation = obj.group_rot.
i. Hide the piece.
j. Repeat steps d…i, till no more pieces can be ‘removed’

At this point, you are ready to start game play. All of the above steps would have been done in a single frame, so the player would not see the puzzle being prepared.

Now, one at a time reveal a piece from the piece group.

Give the user a way to cause the solved_group to rotate

TRICKY PART: Let them drag the current piece and write some snapping logic to identify when it is close to the ‘x0,y0’ position (i.e. solved position). Put it back in the puzzle_group, de-rotate it, de-translate it, then show next piece.

Repeat till puzzle is solved.

[roaminggamer]

This is one of those catch-22 cases.

One needs experience, so one makes a game to gain experience, but then finds oneself in need of more experience to gain the proper experience.

You don’t have a lot of tools in your toolbox yet.

• Tools == (euphemism for: experience with features, concepts, mechanics, etc.
• We all started here.

You want to add more, so you identify a game you want to make.

Then, you use the tools you have and those you can find to ‘make the game’.

Unfortunately, some of the tools are taking you in the wrong direction.

This is of course, how we learn and I think it is cool.

I’ll post back my findings this weekend. Till then, keep plugging away at it!

Cheers,

Ed (aka RoamingGamer)

[isTrigger]

thank you, Ed, for your beautiful words of support

That’s the last piece of my issuepuzzle, to clarify the whole idea:

PS. This game may treat someone with the carpal tunnel syndrome!

[roaminggamer]

@isTrigger

OK. I made a sample ‘rotating puzzle’ game. However, be warned.

1. It uses SSK so you will not be able to use the code directly w/o understanding SSK.

(That said, you should be able to easily read through the code (scripts/game.lua is main piece of code) and understand the high-level steps I took).

2. It is NOT exactly the game mechanic you wanted. I did not incorporate rotating the device as an input. Instead, I used touches (left and right side of screen, and current piece).

This can easily be modified to use device rotation events as inputs however. I simply didnt’ want to use those in the simulator and I did not want to test this on my device. (Too much work for a demo.)

• accelerometer - https://docs.coronalabs.com/api/event/accelerometer/index.html
• gyroscope - https://docs.coronalabs.com/api/event/gyroscope/index.html
• device orientation - https://docs.coronalabs.com/api/event/orientation/index.html

Links:

• Code: https://github.com/roaminggamer/RG_FreeStuff/raw/master/AskEd/2020/08/rotatingPuzzles.zip
• SSK Source (comes in zip above, but just in case you want to update later): https://github.com/roaminggamer/SSK2
• SSK Docs: https://roaminggamer.github.io/RGDocs/pages/SSK2/
• Some key SSK features I used:
• https://roaminggamer.github.io/RGDocs/pages/SSK2/libraries/misc/#easyshake
• (not documented) https://github.com/roaminggamer/SSK2/blob/master/ssk2/logic/puzzle/grid.lua
• https://roaminggamer.github.io/RGDocs/pages/SSK2/libraries/easy_inputs/

Screenshot

How The Demo Works
main.lua

• Loads SSK
• Loads game.lua module.
• Calls game.lua module to create game.
• Listens for custom (global) event ‘onSolved’ and runs code to draw next puzzle.

scritpts/game.lua

• Contains main game logic/functions:
• game.create() - Create game board and start play.
• game.destroy() - Destroy game board and clean-up.

During creation, the game logic:

1. Uses my SSK grid helper to split a single image into a number of rectangles, where each is a sub-image and in the right place to show the full image as if solved.
2. Processes this list of pieces and marks each (non-border) piece with random matching rotation, then hides that piece.
3. Shows last hidden piece at end of game setup.

This is suitable for use stand-alone and with composer, where the group you pass in to create() is the current scene view.

Game Rules/Operation

1. Tap left or right side of screen to rotate game board.
2. Current game piece will remain visible above board in center of screen.
3. When you think the board is rotated to match the current piece, tap the current piece.
4. If you guess correctly, the piece will slide into place and choose the next piece.
5. If you guess wrong, the board will ‘shake’
6. When no pieces remain, a custom (global) event ‘onSolved’ is dispatched after the board is rotated back to 0 degrees.

PS - I never make games where the user fully rotates the device (orientations) because you’re just inviting clumsy people to drop their phones. Also, the orientation feature is more suited to business apps where a user may want one of two portait orientations, or one of two landscape orientations. Rarely do I see people use all orientations.

[isTrigger]

Great work, Ed! I’ll meditate, aligning my chakras, with a wealth of useful information to assimilate and digest in full. As far as clumsy people, I agree…