[Behavior] Rubber Band

0 favourites
  • [attachment=2:1glg6y09][/attachment:1glg6y09]Good localTimeOfDay everyone,

    I just started playing aroung with writing C2 Extentions a bit.

    Started with a go for a 'rubber band' behavior. ie. one object tied to another with a bit of dynamic.

    I couldn't find any other Plugin doing it, but might have missed something.

    Take a look, if you like. .

    There is also the code. .

    And in the rare incident of one of the more experienced C2 Veterans taking a look at the code, pointing out obvious mistakes, highlighting C2 best practices or just making useful suggestions is highly welcome.


    Updated the plugin (v0.7) to allow the usage of multiple bands on one object.

    (Docu says, this may break any existing usages of the plugin, if any should exist yet.)

    Relevant demo:

  • Very neat!


    It also appears quite efficient, I was just having trouble figuring out how to "chain" several objects (have smaller in-between objects that move at, say, 50% of the big main object) - attempt to use sequential Relaxed length values didn't work.

  • Haha, I didn't even get that far with my testing yet.

    What exactly are you thinking of? / trying to model?

    I am still thinking about supporting multiple 'targets' to be tied to.

    Having a sequence of items and each tied to _both_ its neighbors could provide what you are looking for, if i read you correctly?

    (edit: could also look totally weired, if i think about it... )

  • Basically imagine a chain where the spring is in my example - so if we could have a point in the middle of the spring, sort of moving about half as actively as the big ball it could look like a chain or rope.

    Basically I was thinking about "faking" a chain, but probably attaching a smaller object to the main one and then the big ball to it would work as well.

    I also forgot to ask - does the object size have any impact at all or is it all just value based?

  • The behavior is completely determined by the configured values.

    'Size' or 'Mass' would effectively just add to - or rather substract from - the 'Stiffness' value, if you try to compensate for size.

  • simulatedTea

    Nice plugin, thanks

  • It's very cool and friendly to use!!

    One of the greatest behavior!

  • Hey Somebody,

    I tried quite a few things. This is the first solution that somewhat works to build chains with. (And does not totally blow up the complexity of the code or the usage interface of the behavior itself.)

    It is still kind of twitchy though, and I probably would not recommend productive usage of complex structures build in this way. Although you might find something that works for you playing with the config parameters.

    Maybe still a bug in there. May also be as good as it gets for now. We'll see.

  • simulatedTea


  • Very cool update, linking to several objects is just great - see plenty of usage scenarios there. May be a little bit until I get to try it in a real gameplay scenario, but will surely comment then.

    Thanks again for a great plugin!

  • It may be a good thing if there is still some time left.

    I still want to flesh it out a little more. Add actions to change the band length at runtime, collision detection, etc...

  • Would also be great if we could have the linked sprites rotate in correspondence to gravity

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Beware, long story.

    I tried combining my movement with the build-in physics behavior. Because, you know, would be nice if I wouldn't have to do my own gravity (although 'Physics' doesn't have a config value for the gravitation, like I do), friction and elasticity and stuff, if I can just use whats already there.

    That didn't go too well.

    Basically my object just gets stuck. (Which feels somewhat familiar. Either Physics just refuses to move if it detects a foreigner or it constantly resets speed or something. I've been there.)

    So I took a peek at the code, and sure enough, it reads like one of my earlier drafts.

    "Remember position and compare."

    "If external movement is detected, measure and set own speed to the one observed."


    "Reset own speed once external source stops interfering."

    Just without the nice combinability feature that I settled for lately.

    So I put on my megalomania hat and thought, maybe if i rearrange things a bit, make'em work my way, I can make the physics Plugin compatible and cut the amount of work my behavior has to do.

    So, I roll out my pattern of 'collaborative movement' and yay, it moves.

    Only that it seems to be 'falling' towards 2 o'clock. Wait, what?

    Is that a bug? Did I confuse x and y by accident? But then where does that angle come from?



    I rotate the object and yupp, sure enough, it 'falls' straight up in the sky. hrmpf.

    Its not a bug - its a feature. The gravity is local to the object.

    Maybe i should not have ticked the 'Prevent rotation' config, so it could rotate to find 6 o'clock and fall down.

    But no - it just starts rotating, which makes it fly circles around its anchor. hrrg.

    Looking closer at the Physics I notice, -- 1 -- you can configure gravity via an action. It is labled 'Set world gravity'. (On a gravity local to an object? what might that do?)

    And -- 2-- that it can do something called 'joints'. It accepts options that read a lot like mine. This thing can probably obsolete my behavior.

    Why did nobody tell me?

    However, within 5 minutes of trying I could not make it do what my behavior does. I could have just googled for the docu or a tutorial at this point, but instead decided to blow off some steam in a wall of text.

    Now, I'm kind of at a loss here. What should I do? Abandon my behavior? Or finish it anyway, just in spite.

    Well a few things are to be said here.

    That Physics behavior is part of the C2 core. It has a far more complete set of features than I need atm. It is probably much more optimized than my humble pile of code. (It lies with a file bearing the awe-demanding, magic letters asm *subconscious quiver*.)

    But! there are problems.

    Actually the paragraph above is the problem. This behavior does too much. Its complex. (At least, I don't get how most things there work.) It does it all - maybe because that allows for better optimization? And it cannot be used only partially. It is a God-Behavior. That is not the thing I expect in a modular toolbox. At least not the first thing.

    I have already been thinking about this with my behavior. At the time of this writing, it does 3 things. A rubber band. Gravity. Drag. These could also be 3 separate behaviors. If they could play nicely together.

    So it comes down to the question how small, how specialized should modules be?

    Thats actually a pretty old question, you may have heard it in the incarnation of 'many small specialized linux-tools vs. a Windows-Monolith kernel' or systemV vs. systemd or...

    I think the pros and cons are pretty straight forward.

    Many small, focused behaviors:

    easier to explain & understand

    can only use the ones really needed

    more work to click together the desired behavior from its aspects (though this might be outweight by the more demanding work to understand the one-does-it-all behavior)

    possibly a lot of overhead for duplicated internal state and calculations

    -> Easier & low initial hurdle, suboptimal for professional, high performance or other advanced use cases.

    Multi-functional complex optimized behaviors:

    more difficult to understand / learn

    may enable andvanced behaviors which require an in-depth connection between simple components

    may not be flexible enough to be reduced to only the required functionality

    less overhead from duplication

    -> high effort to learn/master, interessting/required for advanced & cool projects.

    Now from the perspective of the C2 project I can understand that we don't want to prevent the cool&advanced stuff to be possible.

    But on the other hand the ease of use, especially for a non-programming audience is also a big part of the target group of C2. (Which, i may have to throw in here, it does a pretty good job at, at least from my POV, and atm i'm really excited by this. Awesome job guys. Really.)

    So, ultimately, I think we need both.

    Have a 'Simple Movements' section, containing tiny, stupid, specialized stuff like 'gravity', 'friction' and 'solid'.

    And an 'Advanced Movements' section for the likes of 'Physics', maybe as 'Combined Physics'.

    I, for my part, would like to see Physics additionally available in smaller aspects. Though I'm most likely not able to do it by my self. And some cross-cutting concernes like collision-detection might not work like this at all. I guess I would have to start with finishing this plugin. Seems like a legit first step.

    I have to put a disclaimer here: I have not much of an idea, of what I am talking about. I never tuned a mobile app for acceptable performance, I don't know how precious the CPU cycles there really are and what are the tradeoffs to be made.

    I also don't know what the dev's already tried, what failed and what didn't. Providing a working yet accessible set of compatible modules is a very non-trivial problem.

    I guess, i just wanted to get that off my chest. For anyone, who made it this far -- I am sorry. Thank you for your time and maybe your sympathy. Thanks for reading.

    And in case this post is beating an already dead horse/debate, maybe someone could link the earlier iterations for me to find.

  • Savvy001 maybe the Physics behavior can already do that - i am not sure. (after today)

    Could be worth a look, if you are serious and have the time.

    (I'm sorry if this is not the answer you were hoping for.)

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