Best way to travel from layout to layout

which is the best way to travel from layout to layout while remembering the point of entrance/exit?

i managed to achieve this using global variables and a messy set of events but today i discovered there's a persist behavior. I already can see the uses i could have for that behavior but when talking specifically about the player object, (a character that has to travel back and forth from layout to layout), which is better?

When the character goes into a house, and then goes back outside, it has to spawn in front of the door andnot at the start of the level, but it also needs to remember all of the possible pickups inside of the house as well as the possible pickups BEFORE entering the house. i haven't gotten that far but i feel like theoretically, when i go back to the outside, the persist behavior wont keep the info of what was picked up inside the house , and will do so ONLY if i go back in the house. Is that correct or how does it work?

When you move out of the layout, you will lose everything except those that are Global objects. Usually Sprites are not Global by default; you need to turn them on. It depends on the nature of the pickups or how many Sprites you want to remain for you to manage.

In regards to persistent pickups: I would like to suggest working with a 'database' of objects that you expect to be in a layout. This 'database' is actually a Dictionary, which are Global, so they persist. They are saved when you 'Save Game', so that's bonus.

The Dictionary contains information about the item, for example. its default location, and its state/status (eg 'default', 'pickedup', etc) and whatever seems relevant to you. This Dictionary defines how the item will be displayed, if it were to be displayed at all.

So for example, I have a Dictionary object called 'ItemsDict'. ItemsDict has an instance variable called `owner`. `owner` refers to the House that will refer to this dict. When I have ItemsDict.owner=House_A, this means that the items that will be contained in this dict are items from House_A.

Then imagine we instantiate another ItemsDict and assign `owner` to House_B. So now we have 2 dicts.

Now when we enter a layout, we pick the appropriate ItemsDict using the owner name. You may use the layout's name, or some other mechanism. Once you pick the correct ItemsDict, you cycle through all the keys, and instantiating new Sprites that correspond with the data inside ItemsDict.

When the player has interacted (eg picked up) with an Item, you have make sure that ItemsDicts is updated first by removing the item/key or changing the values, or whatever is appropriate. Perhaps your update mechanism (ie the one that controls the visibility/presence of Sprites) should always derive its state from ItemsDict so that you only have to change ItemsDict and let your updating mechanism handle the visual updating of the scene.

If you exit the layout the Sprites will be destroyed, but ItemsDict will remain. Then go into House_B layout, the same process applies; Sprites are recreated using ItemDict.owner=House_B. But when you go back to House_A layout, the Sprites are recreated, but the objects you've taken will no longer be in the dict and thus won't be created. And that's how you may approach persistence.

Re portals: the player character, whether it is encapsulated as a single Sprite or multiple Sprites, I recommend to be Global because it's usually efficient as the player is the most consistent element from layout to layout.

First, I suggest creating an instance variable in the player called something like `portal`. This makes you avoid the use of global variables.

The concept is having an 'outbound' portal and an 'inbound' landing area. These are two different Sprites. The 'outbound' portal has 2 instance variables called `layout` and `landing`, which is the name of the layout and landing id, respectively, that this portal is going to deliver the player. The 'inbound' landing Sprite has only one instance variable called `name`, which is its identifier.

For example, inside a House_A, there's a portal with `layout=FirstAvenueLayout` and `landing=House_A_entrance`. In the layout FirstAvenueLayout, there is an 'inbound' landing Sprite with the `name=House_A_entrance`.

When the player goes over the 'outbound' portal (ie is overlapping object), the player acquires the `landing` variable value and puts that value into its own `portal` instance variable. This tells the player that whatever layout he ends up in, he will always be placed on the 'landing' Sprite with the same name. In this case it's 'House_A_entrance'.

The System, on the other hand, will acquire the `layout` variable of the portal, which tells the System to move to that layout. When the layout is loaded (ie On Layout start), the player looks at its`portal` variable and finds the 'landing' Sprite and positions itself there.

It is important here to make sure that when you 'land' at a place that it is not in the same place as an 'outbound' portal, or else you'll keep on bouncing back and forth. You may place other event conditions that prevent this, of course.

Hope that made sense.

Oh man, that's a lot to process.

I have a bunch of question but i will get them all together after re reading what you wrote, but the one that is bothering me right now is this:

A global object exists through all the layouts, but it has to be created initially, what happens when you return to the layout of creation? does it duplicate? and if so how can you avoid duplication?

+On start of layout

+Object does not exist

-> Create object

Or, place the object(/instances) manually via the editor, so they do not have to be created dynamically by events.

Regarding your OP -

Global - The object does not get destroyed when changing layouts.

Persist - The state of the object will be remembered for when you return to the layout.

To keep track of entrance/exit positions without a mess of global variables, here is what I recommend:

A single (can be invisible) entrance/exit object with an instance variable ID keeping track of pairs, and another instance variable with the target layout. Every pair of doors needs a unique ID linking them together.

When your global character sprite comes into contact with a door, it saves the ID of the door to its own instance variable, then gets sent to the new layout. On start of layout, place the character on the door with the matching ID. This will work both ways, and with any number of doors, as long as each pair of doors is uniquely identified. No global variables needed!

Oh man, that's a lot to process.

I have a bunch of question but i will get them all together after re reading what you wrote, but the one that is bothering me right now is this:

A global object exists through all the layouts, but it has to be created initially, what happens when you return to the layout of creation? does it duplicate? and if so how can you avoid duplication?

Metathronos, yeah if you return to that layout and the event fires (due to the condition) it will duplicate. You have various ways of dealing with that, like checking against a particular object/instance and say if it exists or has a certain instance count, then don't create.

Or you could use a different layout and event sheet to gather your assets, both Global and not, and never go back to that layout.

faulknermano so... do i create a layout that serves as a container for all objects?

And then:

in the case of the global objects, in the rest of the layouts where they are needed i just place them in the needed position through the event sheet?

in the case of other objects i still need to create them through the event sheet ?

I am just wondering what is the most efficient way of handling the objects. Is putting them all in the same layout a better practice? for instance, making the player object and the tilesets global so the event sheet from that unused layout can define all the collisions and behaviors between player sprites and tiles so they can then be recycled in every other layout?

oosyrag i'll give that a shot.

I found an old example I made with something similar and updated it with the ideas I mentioned above.

https://www.dropbox.com/s/ek258mwmirfke ... .capx?dl=0

I just switched my player object to Global and the resulting mess has been hard to clean up. your solution is very elegant compared to the chaos i had , i'll try to set it up using your example

oosyrag

I set it up and it works great but i need the player to be able to go to a different layout on overlap, but in some cases on key press. kind of like in zelda : adventure of link where you can exit an area by walking all the way to the left or right and at the same time you can enter a house by pressing a button. How could i achieve that? I'm thinking i'd need an instance variable for the door and then use it as a condition to decide whether the player goes to the layout on overlap or on keypress.

That should work - use a boolean instance variable "Auto". If true, it will change layouts on collision or if false, add an event for a key press and overlap.

Alternatively just use two different kinds of "Door" objects with their own rules.

Used the boolean option, it works like magic. Thank you so much