Put any objects you want to destroy with taps into a family, then change your event to use that family instead of the sprites.

If they're the same object type, add "Pick top instance" from your sprite's conditions to the "On tap" event.

I can think of two ways this would be implemented in general, not necessarily with Construct 2.

1. Use bluetooth to discover and communicate with nearby devices. Construct 2 can't do this as far as I'm aware, and I'm unsure of the feasibility of writing a plugin for it.

2. Setup a remote server to exchange data. Every X units of time(5 seconds, perhaps) the player's device polls the service, including their own location with the request. The server takes that location and responds with a list of nearby players and their info. At this point there are a couple things you could do:

2(a). Open a direct connection to nearby players using websockets and bypass the server once contact is initiated.

2(b). Have the two clients communicate through the server, sending actions to the server as they happen and frequently polling the server for the latest actions of the other player. This would preclude the possibility of fast paced games.

Construct 2 should have everything you need to allow for either of the methods(a and b) outlined in option 2. Just know that this opens a can of worms concerning privacy, as user data -- likely non identifying, of course -- has to be shared with and persisted on a server somewhere, even if only briefly. The fact that we're talking location data here makes the issue especially touchy.

Actual implementation details would be complicated and depend a lot on what you ultimately want to do, so I'm just going to leave you with the general overview above. Hopefully that pushes you in the right direction, though.

The expression to get the angle is going to look exactly as I wrote it, but with the indices replaced -- no need to use atan. I can't give exact indices(depends on the controller), but if I had to hazard a guess I would say:

GamepadIndex = 0

XAxisIndex(Left stick) = 0

YAxisIndex(Left stick) = 1

XAxisIndex(Right stick) = 2

YAxisIndex(Right stick) = 3

...

The only way to find out for sure is to run tests. Set the angle of an object to the expression I gave with various indices and see what works.

Security cameras: Animations aren't the best way to go here. Instead, have one frame where your camera is pointing to the right and the origin is in the middle of the camera itself, then use the Sine behavior on that object to alter its angle. There are a lot of settings there where you can change how far it turns, how fast, etc.

Path movement: There are a lot of ways you can do this. One simple way is outlined below:

1. Give the enemy the CustomMovement behavior(remove the pin behavior, too).

2. Have four invisible sprites representing up, down, left, and right.

3. Give the enemy some intial speed through the custom movement.

4. When the enemy collides with one of the direction sprites, adjust his speed to move in the associated direction.

5. Place your direction sprites such that your enemy will essentially "bounce" from one to the next until he finds his way to the original position, at which point he starts all over again.

There are ways to achieve more complex path movements, and ways to do it using fewer direction sprites, but I feel this provides a good visual explanation of one method.

All you really need for this is to get the angle at which your analog stick is pointing, which you can get using the following expression:

angle(0, 0, Gamepad.Axis(GamepadIndex, XAxisIndex), Gamepad.Axis(GamepadIndex, YAxisIndex))[/code:1be38cjs]
You would, of course, replace GamepadIndex, XAxisIndex, and YAxisIndex with the desired indices for the gamepad and analog stick you're wanting to check on.  After getting this angle, it should be pretty straightforward to point/shoot/whatever an object in that direction.

Event 44 is unnecessarily complicating things. Remove it and set the object's Y vector in event 42 instead and you should be golden.

On a side note, you should have an event that sets bounce back to 0 upon jump. If you don't do this, your bounce state can get messed up if the player jumps right as they're first hitting the ground.

—, instead of using Set layer angle, use the Set layout angle action. This will rotate the entire layout.

The problem with what you're doing is that you're essentially comparing each icicle's Y position to itself, rather than to the other icicles. Instead, I'd recommend running For Each (ordered) on your icicle object, setting the expression to the icicle Y position, and running in ascending order, then run your move to top action. This should loop through each of your icicles from top to bottom, sending each subsequent one to the top until they're all in proper order.

Alternative version without shaders -- it does, however, use R0j0hound's Canvas plugin. This method is similar to how it would be done using a separate render target in another framework, such as MonoGame. It's not as elegant as the shader solution, but it gets the job done if shaders aren't an option.

That's a clever effect there. To simplify even further -- reducing it to one event -- you could do something like this:

Every 0.2 seconds, set opacity of WaterFall_1 to (WaterFall_1.Opacity - 100) * -1[/code:qzsunxlu]
Which -- given a starting opacity of 0 or 100 -- will toggle the object's opacity between 0 and 100 every 0.2 seconds.

Find out the combined height of all of your stacked objects, then every tick set the Y-scroll(Scroll to Y in System object) to something along the lines of:

clamp(scrolly, 0, CombinedHeight)[/code:2ad69kcr]  
This will set the Y-scroll to its current value bounded by 0 and the combined height of your objects.  

Ideally, this should be the last action in your event sheet so that prior events which change the Y-scroll don't override your bounding.