Here you go:

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

May not be the most optimized code, but it works.

I was looking at the .capx and I wanted to know if the grid can be made bigger or smaller. I tried increasing its size but the random path still restricts itself to the 4x4 grid space. Also, can you give an example at how you would apply this to a game? I'm trying to think about how it would work in a platformer.

...

Sure thing:

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

If you don't want to be able to walk left at all simply remove that action from the movement group.

It works very much like the older games. Thanks a lot.

Hopefully this helps:

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

What's going on in the original capx is that the y scroll occurs on the jump command, so the payer's y value is actually lower - or at least different - than the last y scroll value, which leads to a sizable jump in where the "camera" is looking. In my example, I use a value that only updates when the player's y value is less than itself for the scroll. I also could have probably done something like:

If player.y is less than scroll.y -> set scroll y to player.y

...but this only just occurred to me haha.

Is this something that's easy to reapply to an X scroll instead of Y scroll? There are some older videogames that would let you walk to the right but not back to the left (Contra, Adventure Island on NES) and I've been wondering how to accomplish this setting of not letting the player go backwards.

Thinking about how some of my games operate, I was wondering how to go about implementing directional damage. The example being whether the player is being hit from the front or from behind.

I'm not sure how I would create this since the player sprite can be considered facing left or right. And with 8 direction behavior, you would have front and back depending on the direction the player was facing.

Any ideas on how this could be done would be appreciated.

....

....

Hi. This is a solution I made for a pipe puzzle before but the concept is the same:

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

Thanks for this. It works just like I'm looking for.

You'll want to use the pin behavior, as well as put the segment objects into a family, which will let you pin segments to each other in order. https://www.scirra.com/manual/99/pin

Alternatively, you can simply give each segment the same set of movement actions/ai and have them offset by time.

Exactly how would you accomplish the 'offset by time' part?

I've still have yet to accomplish this in a way that doesn't involve complicated events. I know there's a way to do this since I've seen several games on this site do this.

The best example would be a select character screen from a fighting game. That probably would involve the most things to select from. Then I could work my way on to something with less/more choices after looking through a .capx. Any help would be appreciated.

This is definitely one of those 'Way too complex .capx files made by one of the geniuses at the Construct forums', but I think I can find something to do with it. Thanks for working on this.

...and as another behaviorless example there is this:

https://www.dropbox.com/s/aondowy4ycjgl ... .capx?dl=1

Click drag to mark start and end points.

I took dop2000's map, added in the event based astar shortest path search i've made previously, added some setup events to generate nodes at the corners of the walls, and then finally did an event based los to create a connection graph.

It works pretty well, I thought it would be slow. There are a few things that could be done to improve it.

* The corners can be moved closer in. Too close may cause issues with the los and generation though.

* Only unrotated boxes work for walls with this. Rotated boxes or arbitrary polygon shapes can be done. The generation and cleanup of the nodes in setup would need to be modified.

* The mesh is kind of ugly, so another idea is to build in an editor in the game to be able to give more manual control if need be. Tweaking the whole thing to be more navmesh like would be nice.

Anyways, that was fun.

cheers

I hope you keep working at this. What exactly can be done with this in regards to having sprites move along the path one draws out?