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."
and
"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?
...
angle...
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.