HI all! Could some be so kind as to illuminate transformations versus animations or are they the same thing? This kinda boggles me as animations were not related to the collision mask or location of object in GM.
So when I see people using animation to move a node across the screen and it has collisions etc Im like “WHAT?!”
Am I understanding this, that animation is the transformation of a sprite or node etc, not just a layered affect?
Defold supports several types of animations:
You can play flipbook animations on sprites and gui nodes. Flipobook animations are basically just a playback of multiple images in sequence on a sprite or box node.
You can also play Spine animations on Spine models. This is a very efficient way of 2D character animation etc but it requires additional software.
There is also 3D model animations.
Finally, and this is what I believe you are asking about, we have property animations. This allows you to animate/tween/transform a property of a component or game object from it’s current value to a target value. This can be used to animate the position of a game object, ie move a game object to a new position. It can also be used to animate the tint of a sprite, ie fade from one color to another. Or to animate the volume of a sound, ie fade out and mute a sound.
When you use property animations to modify the position, rotation or scale of a game object you modify the transform of the game object (position+rotation+scale). And this impacts all components of the game object and any game objects that are children of the game object.
Does this make sense?
Yes it does. 
If I remember correctly, go.animate uses less processing overhead than constantly using go.set_position/rotation/scale in update(), correct? I can’t seem to find any reference to this currently. Something about crossing Lua/C?
The less lua code the more performant the game is. Ideally you should have no update function, just messages when animations should start / change / stop: when such a message is received, you use go.animate to animate position / scale / rotation / tint / …
This is quite natural. Events encode “status variations” and these happen rarely. When something change you request an animation and the (c++) engine executes it for you in the following frames.
Of course there are certain (hopefully very few) situations where you need update. But also in these situations you should have as few lua code as possible.
In short: lua code asks the engine to do something, the engine does!
Coming from c/c++ at the beginning I was using a lot update, now that I have learnt Defold, I use almost no update.
I hope this could clarify somehow the two approaches update / messages.
I try to live by the “less is more” approach to the update function, with as many objects as possible having actually no script at all, relying on a controller script and module(s) instead when possible, but have yet to find reliable workarounds in some pretty key areas, most specifically to do with pixel-perfect movement and collisions that don’t use any built-in physics/collision.
That being said, I’ve never made anything sizeable enough to run into any performance issues, and also live by the approach of “code now, optimize later (if necessary)”
Sounds like a great start to a finite state machine.