Yes that's doable. You need to work with both raycasting, distances and property of triangles.

Here's the project revised for your needs: dropbox.com/scl/fi/o6yahpuq691w0bvw9edrx/Non-infinite-shadow-collision.c3p

I made a IsOnShadow(x , y) function that you can use to check if a point is on shadow or not. It works by raycasting from the sun to the point and from the point to the sun, keeping track of the first raycast hit.

Using this data + the height of the objects and the height of the light, you notice the following triangle similarity, calculate the amount of shadow projected onto the ground, and compare it with the distance from the point to the light exit point.

Supposing that you have an "HUD" layer with parallax 0% where you want to position your coins after you collect them; the problem is that in your code you keep your coin in the same layer and you treat the hud coordinates the same way as the world coordinates.

What i mean is that you may have your coin at position x:2000, y:2000 in your game world. If you simply move it to x:50 y:50, you're still moving the coin in the game world.

So, what you need to do is move the coin to the HUD layer and set its position to the position the coin would have if it was on that layer to begin with. Basically you need to translate the coin coordinates from the "Game" layer to the "HUD" layer.

Here's a revised version of the code:

Note that Construct has specific expressions to make the translation easier:

CanvasToLayerX(layer, x, y)

CanvasToLayerY(layer, x, y)

LayerToCanvasX(layer, x, y)

LayerToCanvasY(layer, x, y)

Hi! You're right, you can use the Line of Sight behavior.

Just like in real life, you know that a point is in shadow if there is an obstacle between the line that connects the point itself to the light source. We can use this to check if a specific point is on shadow or not. Simply check the LOS between the point coordinates and the sun coordinates.

If you have a big sprite with complex geometry and you want to check if that sprite is on shadow, you need to repeat the same thing, but with all collision polygon points. If no collision point has line of sight with the sun, then the whole object is in shadow.

Since Construct doesn't provide a simple way to get the collision polygon points in the event sheet, you can use image points placed at the position of the collision polygon points, and test if those points have line of sight with the sun.

I made a small working prototype that implement this mechanic: dropbox.com/scl/fi/5ocbuher2dshq0yyz3wqr/Shadow-collision.c3p

Like this

That happens because the On any touch ends condition applies whenever any thouch input ends: as soon as you lift your finger from the screen, the condition will be triggered.

The fix is very simple.

Instead of having:

On any touch end && is touching speedBtn

simply have a single condition:

On touched speedBtn (End)

Open a project. In the project bar (where you see all your objects) scroll down until you find the "files" folder and right click.

more info here construct.net/en/make-games/manuals/construct-3/project-primitives/files

In Construct you can create and edit .txt files if you wish. Simply right click on Files and select New -> Plain Text

There is not a specific expression for that, but you can calculate the exact number using events.

The number of line wraps is equal to the textHeight of the full text (line height offset excluded) divided by the textHeight of a single character / line.

Here's a working prototype: dropbox.com/scl/fi/jmccjnkc9tdvmhchvl8qe/Line-wrap.c3p

Note that modifying the text appearence at runtime is needed for the calculations to work.

If you want to keep the animation when the player is moving to the other side of the screen, you need to have a copy of your player sprite that can handle that animation while the sprite is at the other side of the screen.

Basically, as soon as the player leaves the layout, you teleport it on the other side of the screen, and you place your player copy where the player previously was. Then you animate the player copy.

I made an example project to show you how to do this. Note that i don't use the wrap behaviour for the player (implementin it is just 4 events). The animation itself is done with the tween behaviour. If you go in debug mode, you'll see that the player is inside the screen at all times.

Here's the project: dropbox.com/scl/fi/d4ab0aolo0vkmm2pueway/Tile-movement-warp.c3p

I suggest not to have a player of size different from the cell size. That could cause bugs in the future that will be hard to find.

You can stack various tiled backgrounds on top of each other in a single layer, and then change the OffsetX property of each background individually at an increasingly lower rate to fake the 3d parallax.

You can do the same thing with more layers if you wish.

Two things that instantly come to mind are families and hierarchy.

You should group your panels into a single family, so that you can call actions on all panels at once. Do the same for the text.

When you tap an object of the panels family, you first reset the 10 pixels offset of all panels using the family, and then apply the 10 pixel offset only to the desided panel.

You can also avoid having to move the text of each panel by using hierarchies. Simply set each text as a child of its panel (with the y position constraint) and then each time you move your panel on the Y axis, the child will move automatically without needing to write additional events.

When the sprite is in direct contact with the wall and the collision polygon changes, the polygon itself may overlap with the wall. When this happens, the engine assumes that the sprite is passing through the wall and instantly pushes it out. Shortly after, however, the collision polygon changes again, and the cycle repeats. Each time this occurs, the sprite's position shifts abruptly, and if the camera follows the exact position of the sprite, it results in a screenshake effect that you see.