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

Tap 4 spawn.

Pinch for zoom.

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

Although, that is probably not 100% what you want, cant look in the future, so the spawn happens on release.

Need to give the player at least a little time to get that second finger on the screen.

Or, you made the Player Sprite global and you have it present in each layout.

Nice to see that you use the same logic. It also means that what i proposed as logic for using a joker applies to your logic.

To bound the edges to view port.

For each sprite

___System > compare two values .. Sprite.BBoxLeft < ViewportLeft ( the compare does not pick !, why the for each)

________ Sprite > set x to ViewportLeft + Sprite.Width

___Else

_________move the sprite as you are moving it currently

___System > compare two values .. Sprite.BBoxRight > ViewportRight

________ Sprite > set x to ViewporRight - Sprite.Width

___Else

_________move the sprite as you are moving it currently

or pick them this way

System > pick by comparison > expresssion = Sprite.BBoxLeft .. Less than value = ViewportLeft

For each sprite (if more sprites can exceed the boundary's at the same time)

Ether way, you have to pick them.

(attached myself to this topic to follow updates, sorry 2 disturb)

It is nice to see that you plugin-developer-guys do this hell of an afford to get those plugins into c2.3.

It is even nicer to see that you plugin-developer-guys work together to get that gd job done.

Appreciated & Many Thanks.

99.

My gosh MKP1000. I saw your other question in your other topic.

It looks/feels like you never rode a bike and instantly want to participate in a Bike Parkour.

May i suggest that you first create a chat room, then worry about bubbles.

Now, i can tell you that a chat room is way out of my league, but then again, i am into Construct for only 17 months (close to).

So may i do a second suggestion. Plz follow at least 20 tutorials, so you understand the basics.

Then build something way more easy to start with.

Everything you ask is possible. You just have to get familiar with a few concepts.

-

Each layout can have its personal event sheet. You assign a event sheet to a layout in the layout's properties (in the left pane).

But, and that is interesting, you can have event sheets that are not assigned to a layout. You can 'include' those into an assigned event sheet. So, say, you have a bunch of events that are different for each layout, bring them in an assigned event sheet. You have a bunch of events that are the same for each layout, bring them in a unassigned and include them in an assigned event sheet.

https://www.scirra.com/manual/82/includes

-

Global / local objects

The property 'global' for an object can be "yes" or "no".

A global object (some are global by default, an array by example) will be 'just there' once it is created.

If you create a global object in the first layout, it will be present in every layout. And it wil keep its personal info, instance variables .... etc.

If you jump to another layout, you just take a global object with you. This also means, if that object is present in the next layout, you end up with 2 instance of that object, that one that survived the layout switch + the one that is already present in that next layout.

Local objects stay in the layout that they are created in. And they will just forget all their (non default) personal stuff (instance variables) when leaving that layout. Default personal stuff is everything that you have set in the layout editor. Everything that you changed to an object during runtime is non default stuff, so that will be all forgotten.

This is handy, but not always wanted. To avoid this use the Persist behavior.

https://www.scirra.com/manual/161/persist

An object with Persist attached to will not forget its personal stuff. So if you leave that layout, and come back, those objects will be the same as you left them.

-

Global / local layers.

Is a layer property. Every object on a global layer with a certain "NAME" will be auto recreated on a layer with the same "NAME" when switching layouts. Say you switch layouts. In the first layout you have a global layer named "HUD". On that layer you have objects. In the next layout you have also a layer named "HUD", but holding not 1 object. When you switch layout, all objects that are on "HUD" in the first layout, will be auto created on the layer with name "HUD" in the second layout.

https://www.scirra.com/tutorials/594/bu ... terface-ui

I really have no words to describe how handy this is.

-

Global variables.

Global variables in 1 event sheet are accessible/up-to-change in every event sheet.

This also means that, if you give each event sheet its own global variables, you will end up with a big mess.

Rather, make 1 unassigned event sheet, only for the global variables. Dont even include that event sheet.

Because the fact that they are global, you can use them to get values from one to another layout. They keep there values when changing layouts.

-

Other ways to make values survive a layout change.

Arrays and dictionaries are global objects by default. They do not suffer from the 'duplication' danger that goes with global objects, because they dont have a 'face' in the layout editor. (you can make instances during runtime, but lets avoid that for now)

Since they are global, you can store values in them, and those values will survive a layout change.

Perfect to exchange info between layouts.

-

On start/end of layout.

Those conditions are triggers. They run (only once) when a start/end is detected.

And yes, they for sure run their actions/sub events when you switch layouts.

You must think those trough, do you want this too happen ?

If not, you got to constrain them from running every time you enter/leave the layout. This is typical done by evaluating/setting an instance variable of an object with Persist attached.

-

Why use Persist ?

Well, global sprites are a nice thing. But also a PITA.

Usually you want to design a layout in the layout editor using instances of an object. Say, you switch layouts. In the first layout you designed a maze using instances of 1 sprite. In the second layout you do the same. If you make that sprite global, you will bring the instances created in the first layout with you to the second layout. And that is a mess you dont want.

So, rather use 'local' objects with the Persist behavior attached. They only live in their layout, and they keep their personal stuff between layout changes.

-

Switching layouts 'offline'.

That is another history. Got to do some tutorials about 'Local Storage'.

I hope i covered most of the 'layout switch' issues.

There is no difference between using a text displaying a 'non Japanese' and a 'Japanese' number.

I suppose there are plenty of fonts using Japanese characters.

If you use a font, that font has to be on the player's device, but that is true for every font.

So, if you are using a 'rare' font, you should use SpriteFonts. Even besides that i read reports everywhere that SpriteFonts perform better on mobile devices.

https://www.scirra.com/manual/166/sprite-font

https://www.scirra.com/tutorials/629/sp ... when-where

To connect them to a coin (graphical wise) , use the pin behavior.

https://www.scirra.com/manual/99/pin

To connect them to a coin (logical, and not using families) ...

Use a container

https://www.scirra.com/manual/150/containers

In the series 'Do Not Use Wait For Timings'.

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

Let the behavior take care of the acceleration. It is designed 4 that.

Pair the animation to the speed.

The 'Bound to layout' will not 'suddenly' stop the speed in the behavior when the player is reaching the boundary's. So the player looks 'stopped', but the behavior just keeps deacceleration. So .. the speed is not zero. although the player looks like the speed is zero. That is why the player will not intermediately start to move after hitting the a boundary. It will first finish the deacceleration.

This i why i offer you a better solution for the boundary's.

Nah, it is ok, i can debug mine, hard if i dont understand your logic, which is to expect.

But, say, how do you detect a 'Straight' ?