Layer Rotate and Collision

  • In playing with rotate layer I'm finding some unusual interactions.

    in the linked example. Layer 0 has a series of TiledBackground objects with Solid. Layer 1 as a sprite object with platform behavior. [Space] will rotate layer 0 90 degrees. [z] toggles sprite between layer 0 and layer 1.

    The unexpected result of rotating layer 0, is the sprite on layer 1 collides with the solid objects on layer 0 as if they never rotated.

    This oddity is removed if sprite and solid objects are on the same layer. Toggled in the example with [z]. That said when moving sprite to a rotated layer 0 it's position seems to shift relative to the rotation of the layer.

    Assuming this is normal behavior. What would be a good way of countering this effect? My goal is to have several different layers each with independent rotations, that will interact with a platform behavior

    My first thought is to simply have each series of objects pinned to a Pivot object. That will do the rotation. This solves the problem. but does not allow me to use Rotate layer. Which I'm trying to utilize for the competition.

    Links

       Link to demo example

    link to .Capx

    Thanks for any help.

  • I provide a capx in this topic.

    It's with physic objects but the logic for platform/solid is the same.

    It's a workaround, while waiting/hoping Ashley might add some way to get the relative position of an object (the position on screen once rotated. Currently, its X and Y and angle don't change since it is its "rendering context", the layer that gets rotated)

    Something like Sprite.x(Layer) like for the mouse object.

    It's manageable without, but that would really ease up a lot af things. Same for Sprite.Angle(Layer).

  • I didn't see the other topic. Thank you! that provides insight into what's going on and your example further helps me understand what I need to do in working around it.

  • It's a known bug that objects on different layers collide as if their layers weren't scaled/rotated/parallaxed at all. (Objects currently only collide taking in to account their X, Y, width and height, if that helps you imagine what's happening.) Hopefully this will be fixed in future, but it's a little complicated, I'm not sure it'll be done in time for the competition deadline.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • Thanks for the info Ashley. That being the case "know bug", would it be heresy to suggest altering The Rotary competition? With regard to mandatory use of 'Rotate layout' and 'Rotate layer'. To allow entries that clearly use Rotation as the core Design mechanic. Even if Rotate layout/Rotate layer are not the actions used to facilitate it?   

    Apologies, I know those are loaded questions.

  • I agree with onzephyr, I'm stuck because of the weirdness of the layer rotation, however I need different objects to follow or not that rotation (so I can't use layout rotation)

  • We could always use a time extension ;)

  • Indeed, I saw many people using layer rotation instead of a simple

    set X to centerX + cos(angle) * distance(cx,cy,sprite.x,sprite.y)
    set Y to centerY + sin(angle) * distance(cx,cy,sprite.x,sprite.y)

    Which will really rotate the object (making the collision follow) and you also give control over the center of rotation. With layer rotation you don't have that control.

    Moreover, now that family is on the rail, grouping object to rotate them is a piece of cake. Using Layers to do that also force objects to be in the same kind of zSorting group (we can imagine a game with some complex layering of object regardless of either or not they rotate...)

    Anyway, this unfortunately leads to bad programming design like rotating object and creating collision object on another layer and rotating them with the aforementionned formulat just to be in the contest rules.

    However, as the associated rule of the rotary contest is "Every game must make use of the system 'Rotate layer' or 'Rotate layout' actions. It must be an important feature of the gameplay and not just added on as an afterthought."

    And I think changing it "To allow entries that clearly use Rotation as the core Design mechanic. Even if Rotate layout/Rotate layer are not the actions used to facilitate it?" might arm some entries (for now... maybe just mine :D)

    'cause rotation being the "core mechanic" wasn't in the rule. The rule just stated that rotation should be "an important feature" and shouldn't be "added on as an afterthought" so there's a wide range of possibility between "core mechanic" and afterthought.

    (in my case layout rotation appears at level 6 and had a level of freedom in the maze)

    So if I might suggest something it would be "Every game must make of use or mimic the system 'Rotate layer' or 'Rotate layout' actions. It must be an important feature of the gameplay and not just added on as an afterthought."

    But I would also add that changing a core rule one week before the end might not be fair to some people (:

  • Indeed, I saw many people using layer rotation instead of a simple

    set X to centerX + cos(angle) * distance(cx,cy,sprite.x,sprite.y)
    set Y to centerY + sin(angle) * distance(cx,cy,sprite.x,sprite.y)

    ...simple answer - "No programming required!", or not everyone is such a math wiz like you <img src="smileys/smiley2.gif" border="0" align="middle" />

  • Well... In my opinion, using condition and action is already programming... so I don't really agree with the "No programming required!".

    But I'm ok with scirra using that little twist (it's more no scripting language required) 'cause it probably helps breaking some barriers people automatically puts in there mind when they read the scary word "program"

    Also math isn't programming, programming can use math, but both aren't the same.

    And, using that kind of argument isn't really open minded.

    And finally, the formula I used, you learn it in highschool, in a disguised way yes, but you learn it. It's not super advanced math.

  • And, using that kind of argument isn't really open minded.

    Open Minded? ...I do not understand, what you mean and what "open minded" has to do with this....

    BTW: I never had to learn the sin/cos/tan stuf, because I changed schools to "avoid" it <img src="smileys/smiley2.gif" border="0" align="middle" />

  • open-minded: "oh it's math, yeah I'm not good with math but let's try understanding it... Maybe I will fail but that won't hurt"

    close-minded: "no programming required don't need that kind of weird stuff"

    It's just that the same mind who can doesn't understand something can either try or reject it. That's what I meant. And what you said is more on the "reject" side.

    And be happy, you're not in school anymore, now you can learn usefull math.

  • Ok...so I now guess it was nothing personal.

    Actually I learned that kind of stuff during college/univercity, but have forgotten it in the last 20 years since I did not have to use it...

    AND I bought myself a very smart book, to keep up with you...I only have to read it <img src="smileys/smiley2.gif" border="0" align="middle" />

  • ... So if I might suggest something it would be "Every game must make of use or mimic the system 'Rotate layer' or 'Rotate layout' actions. ..."

    Sorry - I can't agree. I appreciate your argument, Yann, but (speaking for myself) one of the brain-straining challenges of the competition has been to manipulate the 'Rotate layer' / 'Rotate layout' actions to get control over the (apparent) center of rotation. Yes, it can be done. Wait for my (last-minute) entry. <img src="smileys/smiley2.gif" border="0" align="middle" />

    ... But I would also add that changing a core rule one week before the end might not be fair to some people (:

    Agreed - for the above reason!

  • Velojet

    I agree with your disagreement :D The brain-straining challenges IS indeed to find a way to make good use of that feature. Unfortunately that would mean that people should already have known all the quirk when the contest started (collision not following).

    As it wasn't documented, as far as I know, people started to design games thinking collision would follow, thus falling into bad programming design to keep on using layer rotation AND trigo, where trigo alone would have been better.

    My suggestion was just a way to reframe onzephyr's proposition (: so that no one would be harmed by a potential change.

    I think my entry makes also good use of layout rotation even if it's not the core mechanic =)

    In my thinkings, I thought that there could only be 3 ways of rotating the POV of a game. 3 ways 'cause 3 possible axis.

    X, the side axis, Y the height axis and Z the depth axis, all three aligned with your character of course.

    • the X axis, as a side view: I thought about rotating things with gravity, also some cool pitching movements as if you were on a boat so making a pirate platformer or something like that :D
    • the Y axis, as a top view: maybe some car racing game would have worked well
    • the Z axis, that was my choice 'cause I was sure it would be the less used of the three. Rotating along the depth axis. a Rolling movement. That's how I came up with this maze Idea. But I saw some game with the same POV. I think some good stuff will appear before the deadline :D
Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)