How do I Fix This Layout Change Conundrum?

0 favourites
  • 12 posts
  • Hi, this may be a confusing concept, but I will try my best.

    My game uses a lot of layout changes. If it was simply Previous Layout to Next Layout and vice versa, it might not be such a problem.

    There is an area of my game that, between Previous Layout "A" and Next Layout "C", there is Layout "B". Layout "B" is unique in that the player has the option to go to Layout "B-1" or "B-2". I'm drawing hallways for my game, and splitting a layout into to halves was the only way I could think of to give the player access to both sides of the hallway. You'll see what I'm talking about if you view my .capx(https://www.dropbox.com/s/3tm4azvmsgy1am2/Murder%20Castle.caproj?dl=0), but this is the basic idea in top-down view:

    Right now, I've got layouts prepared for A, B-1 and B-2.

    I've based my Event Sheet off of a simplified Layout Change .capx that a user made a long time ago to help me with the concept of changing layouts while maintaining player position (https://www.dropbox.com/s/nd4gmalux6qqilw/3ScreenLayoutChange.capx?dl=0).

    I've added Global Variables for the portals that tell the system:

    1) The name of the layout it's supposed to go to

    2) The position of the player on the new layout, whether it's Previous to Upper, Previous to Lower, Upper to Lower, etc.

    3) Whether the new layout is categorized as Previous ("A"), Upper ("B-1"), Lower ("B-2"), or Next ("C").

    Yet when I collide with Upper Layout Portal (*) the layout remains the same, but the player changes position, and when I collide with Lower Layout Portal (**), nothing happens at all.

    My understanding of Event Sheets is amateur at best, but everything looks to be in proper stacking order.

    What am I doing wrong?

  • That's a caproj, you'll have to make it a capx.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Edit: I just had a proper look, I see the names in the game don't correspond with the names in the post. Your problem is that you asked it to go to FoyerB when it has a space as Foyer B. Same for the other one. FoyerA instead of Foyer A.

  • Oh my God. THANK YOU PLINKIE!!! I would have NEVER figured that out!! Thank you!

  • Calling PLINKIE! Sorry, I didn't want to make a whole new post for this, but I'm not sure you'll see this.

    I got the portal working! The only thing I'm still having trouble with is the placement of the player on the new layout. Even though I have specified where the player should materialize after hitting each portal, the system just plops them wherever the sprite happens to be placed on the outside of the layout. I removed the sprite from the outside of the layout and then it didn't show up at all.

    Here is the new .capx:

    https://www.dropbox.com/s/8ki9vqkzjnv4eym/MURDER%20CASTLE%20GAME.capx?dl=0

    Do you have any suggestions on what I'm doing wrong?

  • There is nothing in Foyer A or Foyer B that matches the ID so it doesn't really set a position for the player. When you go to Foyer A, the ID of the portal is 4, but the one in Foyer is 2. The way the picking works in this is that the portal you exit from in Foyer has the same ID as the one you arrive in in Foyer A.

    To call me btw you use like Milanbaudelaire, then I get a notification, thanks.

  • Hi! I hope that worked.

    Okay, I think I see what you're saying, but I'm a little confused because the simplified layout change example I'm working off of ( https://www.dropbox.com/s/bxbgt3czuxq87lv/LAYOUT%20CHANGE%20EXAMPLE.capx?dl=0 ) doesn't have what I'll call "buddy portals" from layout to layout... you simply collide with Type 0 or Type 1 portal and the system reads where to place the player on the next screen, in this case at the player's last Y value and 25 pixels into the play area.

    What you're saying, I think, is that there should be "input" portals with a buddy--i.e., an "output" portal that specify where they materialize on the next screen.

    In the Foyer, the yellow (ID 1, Type 3, Direction 2) portal sends the player to whichever layout i denote is the Upper Layout (imagine two layouts stacked vertically, with one on top and one on bottom) and places them on the Left side of the layout towards the bottom of the screen. In this case the Upper Layout is FoyerA.

    There is no yellow portal in FoyerA, but there is a blue one... the blue portal (Type 4) sends the player to the Lower Layout, in this case FoyerB. Where they are placed on the start of the layout depends on the Direction. This blue portal in particular (ID 4, Type 4, Direction 1) puts the player at their last X value 25 pixels into the play area, because in terms of the "story" they're simply moving between different sides of the same long , narrow hallway.

    If, from the Foyer, the player had collided with the blue portal (Type 4) instead of the yellow one (Type 3), they would be sent to Foyer B and placed on the Right side of the screen near the bottom, because in terms of the "story" they would be entering the hallway from a different direction.

    If the simplified Layout Change example didn't have to use buddy portals, can't I do it that way too? Or is mine just too complicated and I need matching input-output portals?

    https://www.dropbox.com/s/8ki9vqkzjnv4eym/MURDER%20CASTLE%20GAME.capx?dl=0

  • Yeah I checked the simple one before I posted. The simple game ensures that there is always a portal on screen that is equal to curPortal. Your game does not. You are setting curPortal to either 2, -2, 1 or -1. Maybe you are trying to add and subtract from curPortal instead of setting it? I dunno, but the point is your game looks more like a buddy system. You can only set the position of the player if a portal ID = curPortal. So in Foyer A it is looking for a portal where the Id = curPortal, however curPortal is 2, and the ID of the only portal in the level is 4. The simple game does not have these declarations for setting curPortal to one of 4 values so it's really about what you were trying to achieve with those events.

  • Okay, I'm right on the cusp of understanding. With the simple game, I never really understood the purpose of curPortal, or how it worked. So I just gave mine random numbers.

    Okay. So, let's do this step by step. If you help me with the first one I can probably get the rest.

    From the Foyer, I'd like to:

    1) Collide with the yellow portal

    2) Be sent to Foyer A

    3) Materialize on the Left side of the screen, with the player sprite's feet on the "ground", on Layer 2. Eventually it would be great to change his animation frame so that he's looking to the right in side-view, but that's not important right now.

    How should I change my Instance Variables to achieve this?

    Thanks for being patient with me. I'm not a programmer.

  • This is why I rarely make example capx for people because it's better to do and understand what is going on. Assuming that in this game you know where you are going to appear on each layout, you set up buddy portals. So Foyer portal that leads to Foyer A has the same curPortal ID. When you collide with Foyer portal where ID=2, you spawn in Foyer A at portal where ID=2. In terms of the exact positioning of the player then yes you could do what you were doing with the direction variable. If it's a door where the player appears on the right, you set the portal up with variable that positions the player at portal.x+25. If it's a door where you appear below then you set it up with the variable that positions player at portal.y+25.

  • Great! I'm going to work on it all day today. Thanks for explaining that!!

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)