Creating a Layout Transition System

9

Index

Attached Files

The following files have been attached to this tutorial:

.c3p

transition-example.c3p

Download now 239.92 KB

Stats

12,468 visits, 25,908 views

Tools

Translations

This tutorial hasn't been translated.

License

This tutorial is licensed under CC BY 4.0. Please refer to the license text if you wish to reuse, share or remix the content contained within this tutorial.

Published on 1 Jul, 2019. Last updated 23 Jul, 2019

Triggering the Layout Change

The first thing to do, before we add the Area Change event block, is to create three Global Variables:

  • Transition_ID (Number) – this helps us identify which transition is taking place, between which layouts.
  • PreviousLayout (String) – The name of the layout that the player has transitioned from
  • PreviousLayoutTarget. (Number) – The trigger number of the transition sender the player collides with. This helps line up our transitions correctly.

Onto the layout change events. A large chunk of this section will be one event with a bunch of actions – the actions will fire when the player collides with one of our Sender sprites. We also need to make sure the Instance Variables on our Senders and Receivers match up. For this project, there are only two pairs of Senders/Receivers, so it doesn’t get too complex. If you’re going to have more, I’d recommend keeping a spreadsheet log of your transitions somewhere.

Back to the task at hand though. Starting with our green Sender blocks on FirstLayout, you can set a common value for ID, Direction and NewLayout for all the instances here. We’ll set the ID for this transition to 1, the Directionshould be set to Up and NewLayout to SecondLayout. Each instance of our Sender then needs its own TriggerNumber value. It doesn’t matter how you number them, as long as the system is the same throughout your project. In this case, I’ve labelled them as 1, 2, 3 and 4 going from right to left.

For the blue Receivers on FirstLayout, again, we can set common values for ID, Direction and NewLayout. These will be 2 for ID (as these are the receivers for the transition FROM SecondLayout), Down for Direction and SecondLayout for NewLayout. The TriggerNumber values are set in the same way as our Senders – 1, 2, 3, 4 from left to right.

Now, we move onto the Senders/Receivers on SecondLayout. Again, starting with our Sender blocks, set ID to 2, Direction to Down and NewLayout to FirstLayout. Then set the TriggerNumber in the same way you have the others.

For the Receivers, set ID to 1, Direction to Up and NewLayout to FirstLayout. Finally, set your TriggerNumbers as before.

Now that the instance variables should line up, we can put the events in.

So, the condition is: Player_Base ▶︎ On collision with AreaChange_Sender

Our first set of actions will set the values of our global variables as follows:

Action:

System ▶︎ Set Transition_ID to AreaChange_Sender.ID

System ▶︎ Set PreviousLayout to LayoutName

System ▶︎ Set PreviousLayoutTarget to AreaChange_Sender.TriggerNumber

Next, we need some actions to make sure the player cannot move during the transition.

Action:

System ▶︎ Set group “Player” Deactivated

Player_Base ▶︎ Set TileMovement Disabled

Now, we’re ready to call the function we created earlier. The Tag parameter of the Transition Function acts as the signal we’ll use to trigger the layout change.

Action:

Function ▶︎ Call Transition (state: “Out”, tag: “LayoutChange”)

System ▶︎ Wait for signal “LayoutChange”

Once the signal has been received, we can reactivate the player and trigger the layout change. So, the last few actions for this event are:

Action:

System ▶︎ Set group “Player” Activated

Player_Base ▶︎ Set TileMovement Enabled

System ▶︎ Go to Layout (name) ▶︎ AreaChange_Sender.NewLayout

If you preview the project as it stands, you’ll trigger the layout change, but the player is nowhere to be seen. The player objects do exist in this layout, but due to where we triggered the transition, they’ve spawned outside of the new layout. In order to make sure our player spawns in the correct place upon the layout change, we need one more event.

Condition:

System ▶︎ On Start of Layout

AreaChange_Receiver ▶︎ NewLayout=PreviousLayout

AreaChange_Receiver ▶︎ TriggerNumber=PreviousLayoutTarget

Action:

Player_Base ▶︎ Set position ▶︎ AreaChange_Receiver.X, AreaChange_Receiver.Y

Player_Base ▶︎ Set TileMovement Grid Position ▶︎ Player_Base.TileMovement.GridX, PlayerBase.TileMovement.GridY)

This last event tells the player that when we transition to a new layout, it should spawn on the corresponding receiver for the sender it collided with. So, no more spawning in weird places! So your final Area Change event block should look like this:

And that’s it! You now should have a working system where your player can switch between your two layouts. The system should also be scalable too, so why not try adding more transitions and layouts to this project to test it out? Just remember to keep track of all your transition data!

  • 0 Comments

Want to leave a comment? Login or Register an account!