Instance variables of each ball:

sizex <- width

sizey <- height

startx <- sprite.x at start

starty <- sprite.y at start

You probably know the center of your rhomb in x and y too. So the movement and size can be tweened quite simply back and forth. There are behaviors that do it, like LiteTween (behavior-litetween_t70700) or you can do it by yourself with the event system and some simple expressions (http://gizma.com/easing/ for reference).

About balls touching each other:

Be aware that they will necessarily touch each other, if they all reach the center of the rhomb, so you might want to stop a tiny bit earlier.

You can try to tweak the size reduction yourself (let it reach "0" a bit earlier than finishing the movement), or do the math and check how large (relative to starting size) each ball can be along the timeline.

I'm not sure how moving the balls via events by setting the position interacts with the physics behavior. Maybe there are problems or even easier solutions I am not aware off - I have not used the physics behavior so far.

Yes you can do that.

It would be retarded to make an standalone app for your book, if it's just a non-interactive book.

Use ebook formats or pdf for digital books, or do you want to make it interactive?

You variable is a number, so it can't contain text. Set up your variable as string.

> That depends really ... as the loop would merely consist of 1 for each going through the node sprites,

>

> No idea how that pans out in performance with nested loops verses the pin node images ... would have to try.

>

> But the approach ... is many times more easily to apply, with more variation options.

>

The way I see it with the nested loop you would only do the calculations of distance, while with the pinning, you would do the pinning (one time effort), but more importantly carry around those invisible objects for no (computational) reason.

Like lennaert already said, you could do a nested loop and check all image points of swarm 1 against all image points of swarm 2 with the distance expression. The nested loop could have 3 local variables (imagepointswarm1, imagepointswarm2, distance) and when the distance becomes smalled than the previously stored value for distance it just saves the current index for imagepoint 1 and 2.

I don't know how your swarms look, if they are very regularly shaped (example: cubes), it should be possible to predetermine which image point is nearest (or at least reduce the possibilities you have to go through) depending of the difference in x and y (their centers) and angle, as long as they are not overlapping.

You could perhaps spawn and pin invisible images on the nodes, and use something like pick closest.

And how would that be less resource intensive? ^^ Not saying it isn't an option, if the usere here is not well versed in programming logic.

Just spawn one instance of your spritefont object for each tile. You can select them easily later, for example by position or text. The basic tutorials actually teach you stuff like this.

No need for any cloning...

Send the positions continuously (or every x seconds) when an object is dragged + on drag and drop drop, no?

Wrong, ceil(21/20) gives 2.

You could put the health bar in the container of the sprite - this way it would get destroyed if the object, that's containing it gets destroyed.

Other than that it can also simply solved by linking the health bar to the sprite by simply using instance variables and simply selecting accordingly.

alphabet = "abcdefghijklmnopqrstuvwxyz"

for 1 to len(alphabet): set something to mid(alphabet, loopindex-1, 1)