I'm having a hard time understanding exactly what you would be using tweens for, especially when you mention that you want to apply tween to movement.
So, here's what I had imagined in my head when looking at the examples of what can be done with the tween engine :
First, and most importantly, I was thinking that it could be useful to control NPC movement, or someone runs past to tell you something when crossing a checkpoint type of thing, then I thought it would be useful for the flashing effect...
Then, I got creative, and I thought, "hey, I could use it for controls too, like when you start running the speed could be interpolated from the standing (speed = 0) to max run speed, or a jump could change the speed from the jump speed to max fall speed, etc...
Having had the chance to look a little deeper, it seems that this type of interpolation would get real messy real quick, and it seems that it's best that there be "triggers" and while the trigger is active start a set of tweens and return control (except things like flashing which doesn't impact motion on its own)
My understanding of tweens is the manipulation of sprites and effects such as your example of a sprite flashing, not necessarily physics. If you need something to handle physics and angles, you could try and look into Box2D physics which could make your life easier, or maybe even just apply your own collision.
Actually, I already have the collision detection scheme working (why I would only play with speed, not position)... I tried with box2d, and I could not find a way to get the controls as "fast" as I wanted without the player treating every slope up as a ramp to fly off of.
I did find a bit more about using tweens for controls, and while it does seem like it's doable, it seems that it would require a fair bit of refactoring... and I've done that too many times as it is (first go, I was using box2d, which I could not figure out how to get the controls the way I wanted... so, I ripped out box2d. Then, I had poorly planned the project structure, so I refactored to make an entity system.)
What I wound up using was the intersector class with libgdx, where the desired position is calculated, any intersections are calculated from that position, and if needed speed gets recalculated to exactly arrive at the collision.... it works even with absurd speeds.
As far as tweens go, I feel you can get away with using Actors or Shaders in order to apply effects to your character. All in all I feel it just depends on your approach to how you want to make things like cut scenes. For cut scenes in games, I've seen developers directly manipulate the velocity/position of their models. For example a warcraft cut scene where your character is being controlled, or even in the classic mario brother games when you win a level and he jumps on the flag at the end. Alternatively the larger studio games actually have amazing cinematic scenes that overlap the real game screen, like world of craft and many others... It just depends on how you want to do it.
I'm still a noob, so the tweens / cut scenes I'd be looking at would be FAR CLOSER to Mario style than world of Warcraft style...
Hmm... thanks for the link, I'll look it up...
As it stands, I have :
baseEntity: has the shape, position, speed, and whether or not it will be updated
groundEntity: is a base entity that has the extra data for handling terrain collisions (like the walkpath of terrain)
player: adds the sprite....
it might be worth looking into to make use of extra functionality if it doesn't add too much grief.
Here is my personal example of my main game Screen, which is by no means a definitive go-to guide. I just feel it's helpful to show a different approach to different problems:
Actors - I use them for my in-game UI, because I like applying effects/actions to certain UI buttons. It's as easy to make Actors and have them part of a Stage, because all you need to do is just put that stage into your render() method, and run it. Going deeper, I add my Actors to a Table, which helps me organize my UI so that it's easy to align on my screen. It also helps with resolution scaling because I'm making a desktop game, and my Table will automatically re-scale the properties of all my UI depending on the resolution.
Sprites - I use these for my player/enemy entities. Since I'm making a 2D game, I can get away with simply rotating my sprites when I'm changing direction, and you can swap textures of those sprites with other textures if you want to emulate some sort of complex animation(Or just use 2D Particle Editor).
Shaders - You can use shaders for different types of transition/color effects. This is applied to mostly my sprites, but I already try and make my own solutions before I may use shaders.
Actually, that's what I thought was the use for actors / stage was to handle UI, but that it would be possible to use it for simple collision detection, etc...
That's more or less where I'm at now with sprites, although I don't bother rotating the sprites for slopes... and I'm still debating if I want to mirror the sprites (at least the main player character) or if I want to do like Metroid and ensure that no matter what the gun arm is always on the right...
I have a feeling I'll have to learn more about shaders... but that can wait until I'm a little deeper in. I gotta stop talking about it so much because it's still in a state that's even too pathetic to put on WIP.