beginning of layout should be fine..

Like ashley says, it has no gyroscope:

http://gadgets.ndtv.com/zte-open-c-1302 ... oto-e-1595

Bumping this thread won't solve that I'm afraid..

There are many ways to test if the pipes are connected.

Using detector sprites would be one, you could check if the sprites on the edges that are open (add imagepoints and pin the sprites to it are overlapping.

Another way would be using instance variables and checking overlapping at offset and comparing the variables with the object overlapping.

Even another way would be using an array to hold the grid information.

It all depends on your preferences and skill in creating the events.

How do you create that game?

First you make the graphics and import them into C2

Then you add behaviours to the sprites, or you program the wanted interaction in events.

Then you add the rest of the events that do not directly affect the sprites like the score and time etcetera..

Or you have someone else do it for you if you are not ready to create a program like that yourself..

Could be there are even examples for this kind of game on the forums if you search right..

Yet another way would be to first learn the basics of making programs with Construct2, so you can create a lot of this game yourself and only have to ask questions on this forum when you are really stuck..

The pinned sprite should be just as smooth, providing you pin once and not every tick (a mistake a lot of beginners make).

You answered the second question yourself, for an action is not a behaviour.

I'm an "If it ain't broken, don't try to fix it" kinda guy..

If you were to add more conditions it might be wise looking if using loops, repeats, functions and even arrays would be beneficial, but I like the simplicity of this and when looking at it I immediately see what it is for, all the other stuff can confuse me sometimes..

Something like this?

Isn't 8 direction behaviour almost the same?

With some tweaking you could get exactly the same movement.

There are even some examples on the camera between stages if you search the forum..

Here's one of the movement topics:

just put zelda in the search and tons of stuff comes up

I think most blogs and tutorials already explain the basics:

• try to avoid every tick events if triggered events will do the trick.
• try to reduce the collision-checks
• try to limit the amount of objects on the screen to prevent overdraw and not use precious memory
• use groups and (de)activate them when needed..
• use functions instead of repeating (almost) identical events

I haven't opened your capx, but it seems to me you should first pick all instances that conform to the condition and after that pick a random one..

I gave you two ways..

• use the pinned sprite with the scrollto behaviour
• use the system scrollto action

Which of these once did you do before and was visibly worse?

Instead of setting the scrollto behaviour on the player either set it on a sprite pinned to the player located above the player or use the system scrollto action and set it to player.x, player.y-200 (or whatever offset you'd like)