Path Movement Behavior

This forum is currently in read-only mode.
0 favourites
From the Asset Store
Run, jump over or on enemies and reach the path’s end as fast as you can!
  • Is this what you mean by ease in and out?

    That works great! I was looking for a build in behavior but your math works too. Love this program, I just made a bad guy path that patrolled until he saw me and then ran at me. Thanks Again

    deadeye

    Old time term?

    But really not only does flash have the ease in and out but all my big boy 3d animation programs. It is an important part of any moment

  • > Is this what you mean by ease in and out?

    >

    deadeye

    Old time term?

    Yes, it's term that's been around since the 1920's at least, so I would say it's an old-timey term. It was a concept first used for hand-drawn animation. Sometimes called "slow in/out" instead of "ease in/out." It's one of the twelve principles of animation as written by Disney's Nine Old Men.

  • Yes, it's term that's been around since the 1920's at least, so I would say it's an old-timey term. It was a concept first used for hand-drawn animation. Sometimes called "slow in/out" instead of "ease in/out." It's one of the twelve principles of animation as written by Disney's Nine Old Men.

    Thanks for the word history it was was actually interesting, but I have a feeling that deadey's (Hot for Code words) legs are not as nice as Marina Orlova LOL

    Or do we need a pole?

    Deadeye 0

    Marina Orlova 1

  • I don't know who that is.

  • I don't know who that is.

    <img src="http://www.shallownation.com/images/marina_orlova_hot_for_words_1.jpg">

  • I still don't know who that is and furthermore...

    ...I don't care

  • I agree.

    She's just a bit too Katie Price for me.

    You know, how much is real, how much is bought, etc.

    Have we drifted off-topic?

    Krush.

  • Ah, I just realized that you have to create the path first with actions. Never mind on that part.

    I still think an actual visual editor would be best for this sort of thing. It would make it much more user friendly and remove the need for .path files. Still, I suppose it's no big deal to set a path with small "waypoint" sprites in the editor and use a loop to designate your path with the path object.

    You could make your own and use an image to create the path.

    Using the image manipulator object all you have to do is test if there is a pixel at a particular point.

  • I can think of several ways to make my own but I have to say I never considered using the Image Manipulator. Seems rather a complicated solution compared to some other methods you could use. Such as:

    + For each sprite ordered by sprite.value('node')
        -> Set waypoint at sprite.x, sprite.y
    [/code:2jovgvy5]
    
    Not to mention the problem of telling which direction you intend for the path to go based on where the next pixel is.
  • New Version 1.1:

    updated download in first post

    <img src="http://img442.imageshack.us/img442/1206/properties110.jpg">

    <img src="http://img13.imageshack.us/img13/3487/patheditq.jpg">

    ...and there it is: a path editor at edit time. Made from a gutted physics behavior.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • ...and there it is: a path editor at edit time. Made from a gutted physics behavior.

    This is the future of of enemies for 2d games.

    Nicely done, I have to try this!

  • Holy crap, that's amazing!

    You've really outdone yourself R0J0hound. Awesome work.

  • New Version 1.1:

    updated download in first post

    ...and there it is: a path editor at edit time. Made from a gutted physics behavior.

    Well there ya go.

    I can think of several ways to make my own but I have to say I never considered using the Image Manipulator. Seems rather a complicated solution compared to some other methods you could use. Such as:

    > + For each sprite ordered by sprite.value('node')
        -> Set waypoint at sprite.x, sprite.y
    [/code:2jqxzl36]
    
    Not to mention the problem of telling which direction you intend for the path to go based on where the next pixel is.
    

    You can also test for more than one different color.

    Plus there's all the nifty things you have access to in the better image manipulation programs, bezier curves for example. All much easier to set up than a clicking one x,y at a time.

  • Or use system expressions - lerp is linear path, cosp is cosine interpolation, then there is cubic and quadratic, which are essentially bezier curves.

    cosp(P1,P2,t) interpolates between the two points - P1 and P2 - based on t, which represents the fraction of distance between the points (0..1). You can simply calculate a distance between the points, then iterate from 0 to 1 using timetelda (and a speed modifier). Then when you reach a waypoint, you move onward to next waypoint.

    Cubic and quadratic require more than two points, but you can always take another waypoint for reference (you get smooth turns that way).

  • New Version 1.1:

    updated download in first post

    <img src="http://img442.imageshack.us/img442/1206/properties110.jpg">

    <img src="http://img13.imageshack.us/img13/3487/patheditq.jpg">

    ...and there it is: a path editor at edit time. Made from a gutted physics behavior.

    YOU ROCK!!!

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)