Yes it would and yes you should make it an Instance variable. You might need to add a "for each" condition in order to work however. I am not familiar with the path finding AI but you can check this topic

Ashley I am not sure how I can describe it, I'm not quite sure what is it that I miss from the current state and functionality of the shadow caster. I'll try my best to make my self clear:

1) The system draws shadows, so in essence it finds areas that are behind (in relation to the light source) the polygons of the shadow casting objects and draws stretched dark shapes to simulate shadows. So far so good. But what happens when an object should cast its own shadows, be visible but gets behind an other object that is "taller" than it, so it should be shaded by the taller object? How can we achieve that? I have a workaround with the line of sight, but it's far from ideal.

[attachment=0:1vg4odv4][/attachment:1vg4odv4]

2) We can colorize the shadows but the other way around would be more useful. I know that we can use other sprites with blending modes to fake the color and add falloff, but I believe that if the system worked by darkening everything out except for the parts that are in direct view with the light source, it would be more evident and useful. At least as an option. Again, I understand that we can do that by using a white layer, but then things are getting more complicating and as I mentioned many times in the forums already, masking in general is not Construct's best virtue. Using blending modes to mask layers with other layers is... a sore to say the least.

I hope that I make sense!

What about if we want the blue sprite to cast shadows, be visible when in direct light, but when goes behind on other shadow casting object be covered from it's shadow..? The only solution I found so far is to use the line of sight behavior on the light to detect if it's visible from the light point of view, thus not shadowed from an other object=move it up in Z order, and when it's not visible from the light's point of view = push it behind the shadows. I find this solution not very effective or visually elegant.

Any suggestions?

Hello

• In regards to "jagged jumping"... You'll have to find the golden rule for your character. Basically, you want the part of the player that touches the ground (the feet) to be alined with the lowest part of the collision object. For example, you could use a different frame on the collision object that reflects the height difference from Idle pose to Jumping pose. Or you could use multiple collision objects for different body parts (to detect bullet hits) and dynamically position them using image points. I 'd suggest a simple solution though.

• I had changed the origin points to match the changing animation, but sometimes the character will land "inside" a platform. This will be fixed with the collision box sprite?

Yes! The simpler the collision box sprite, the more control you'll have over the player's interaction with the world around her!

On this Topic https://www.scirra.com/forum/viewtopic.php?f=147&t=94133&p=788441&hilit=slope#p788441 the forth post has an example that handle animation states (and slope angles!) in a very neat way. Basically, you need to exclude curtain states by saying "if this key is pressed and Player Is NOT moving---> Play run animation"

Keep it up!

Ok, I think I fixed it. Check it out below. On a side note, perhaps gameplay wise it would be better to use the angle(enemy.X, enemy.y, player.X, player.Y) to determine the attacking direction/animation, since there are moments that the enemy moves toward the player but the direction he is moving doesn't match the direction he should be facing/attacking.

I understand. I' ve updated and attached the example. It's not perfect, I don't know how to calculate the angles in a predictable manner. Some times, C2 returns a 180 degree value and other times it returns -180 degrees, which in essence are facing at the same same way, but brake down the conditions which set the direction variable... I am sure there is a mathematical formula that fixes that, but I am unaware of it. For the time being, try to improve upon this, until some wise forum member comes to the rescue!

sadNES you are welcome! Based on the same principles, I made an other capx, this time with a sunset theme. I've uploaded on this other topic, it's the last post on page 5 (https://www.scirra.com/forum/viewtopic.php?f=146&t=106045&start=40).

It's being so long since I saw Spirited Away, now I have to watch this masterpiece again

Thank you for taking the time and look at my site. It is actually not a finished site, it just holds some blog-ish reports that I made for my graduate project. You can however play the actual "game", (I prefer to see it as an interactive narration) which it's on the same page. Here is the direct link http://www.eli0s.com/Memories/.

Note, you ' ll need a somewhat powerful laptop or a decent PC to play it properly and I strongly suggest using Chrome.

Keep it up!

I really liked your animations, bravo

I don't think there is anything wrong with the Platform+ behavior. The problem is that you use the Sprite that holds all the animations as a Platform/collision object. Never do that!

Use a simple box that has roughly the size of your player (a rectangular shape) as the object that has the Platform behavior (and does all of the collision checking), and pin your sprite that has the animations into the first object. Don't forget to set the box to invisible.

Also, you can surely notice that there is jagged movement in the jumping anyway. That is because the origin point and the collision polygons of each animation are misaligned. Try to set the origin point of each animation on the same, relative point. Most of the times it should be around the feet, where an imaginary vertical line below the center of the mass meets the floor.

I hope I was clear enough

Some very interesting stuff mentioned here.

Dru this example is awesome! I'll be damned if I got half a line of math, but the logic is clear.

I think that if gray-scale masking were possible, most of those problems would have being solved.

I like the ideas for per-light falloff and light cone. I 'd also like to see a condition that checks if an object exists within a shadowed area. This will be incredible useful for covering/uncovering stuff when they are not in direct light view (hiding behind shadows).

I am glad that you made it work!

Now, I haven't really done any search for enemy AI yet, didn't need to. I am not sure about the 4 directions and the path finding though. The only true benefit by using it will be if you have obstacles. Otherwise, using events you will probably have more control around the enemy's movement.

This is a capx I had made for an other topic, the goal was for the enemy to move vertically until he line him self up with the player and then move towards him, in a Double Dragon fashion. You can get some info out of it that might help you build your own movement.

[attachment=0:7p6jpnto][/attachment:7p6jpnto]

As for the attack, just make a distance comparison* (or use an invisible sprite that is bigger than the enemy's sprite and check for overlap) and when true, set an Instance variable "Attack" to true and create the necessary events for the enemy's attack.

*The distance comparison should look like this:

(System - Compare 2 values)

distance(Player.X, Player.Y, Enemy.X, Enemy.Y) < any number you want ----> Player set Boolean "Attack" to true

distance(Player.X, Player.Y, Enemy.X, Enemy.Y) > the same number as above ----> Player set Boolean "Attack" to false

Have you disabled the default movement on the 8direction properties..? I think that this is the culprit.

On a different note, I remember that placing the bullet creation above the direction conditions solved some double firing problems. If you encounter this, move the event 29 just below event 24 (in essence, make it the first sub-event).

donelwero the sub-event 30 ensures that the triggering happens at the correct frame and it's fps independent. The every x seconds is somewhat abstract and inaccurate.

Also the "Is NOT attacking on event 4 is checked first and only when it holds true the following sub-events execute. The "is pressed" and "is down" on this matter are irrelevant.

You are doing something wrong. It should work and it is wiser to check the variables than constantly disabling/enabling the behaviors.

You are right about the trigger once, the advices were from my head, I didn't suspected that.

I think this is what you want. I've altered one of my examples that is lurking somewhere in the forums, in order to fit your instructions. Tell me if something doesn't work as it should.