scrollingTiledBg.capx

I wouldn't use a super big image for collision but build the collision out of a little resized square. This way you only load a little texture and you get a good level of customisation directly inside C2

I prefer using instance variable. It greatly helps with picking and is way more readable than simple array indexes. Also it's more in the logic of OOP.

To keep these data through layouts, I would make the object global.

To save/retrieve these data with webstorage or server database it could be interesting to have an action for serializing/unserializing these data into an XML or whatever string easily saveable.

Ashley has some ideas maybe.

healthBar.capx

a bit simpler healthState.capx

Be carefull only the origin point snaps to the grid

If the origin point of your sprite is in the middle it will snap by the middle

I often put the origin point at top-left for snapping

gridSpawner.capx

Noga your formula is overcomplicated

First using the same angle order as c2 (0 is to the right and then you move clockwise) makes the formula way easier.

You can sum it up as round(animationFramCount*angle/360) but as you well representated in your image you need to offset the angle a bit so the direction the sprite shows represents the center of the range of angle and not the minimum.

So it should look like

ceil(animationFrameCount*angle/360-0.5)

ceil(animationFrameCount*(1+angle/360)-0.5)%animationFrameCount

If I remember correctly, multimedia fusion 2 has two kind of "or". An or "logical" and an or "filtered".

Even with the experience I have with mmf2, cc and c2, I think I really understand this design choice now (well I dropped mmf2 long ago...)

Anyway, if it's that hard to understand, it's probably not a good choice.

So, I don't think having a logical and filtered else would be a good idea...

Ashley :D yeah I saw my mistake and thought about something else as a solution

So I reposted it with some changes

I honestly think that "else" shouldn't mess with picking as most system expression.

In my opinion, else is missing in c2 for only one algorithmic case: "when my previous condition is false"

Putting the inverted condition as an else doesn't work if the action of the previous condition makes the next one true (like Ashley's toggling example)

In short, I side with Geo in the idea of keeping the else logical only.

Also in Ashley's case 2 things can be easily handled by just inverting condition

+Sprite: X < 320
  -> Sprite: set opacity to 33
+Sprite: X >= 320 
  -> Sprite: set opacity to 100

+Sprite: X < 320
  -> set X to 400
+Sprite: X >= 320
  -> set X to 100

+Sprite: X < 320
  -> set X to 400
+Else
  -> set X to 100

+Foreach sprite:
  +Sprite: X < 320
    -> set X to 400
  +Else
    -> set X to 100

+Foreach sprite
  // check for sprite too far from the center of the view
  System: distance(scrollX,scrollY,Sprite.X,Sprite.Y) > 100
    -> do things

+Sprite: Y > LayoutHeight
  -> Sprite:destroy

+Sprite: X < 320
  -> set X to 400
+Sprite:invert picking
  -> set X to 100

if I understand correctly you have 2 components :

• shooting direction
• wind force

if it's correct, I think you should do something like

on Shot
  -> Ball apply impulse  shotStrength   at angle angle(ball.x,ball.y,directionOfShoot.x,directionOfShoot.y)

Every ticks
  -> Ball apply force windStrength at angle windAngle