cocoNUTS.capx

Well... That's what I did, but using newline as a separator...

paragraphDisplay.capx

event 4 was true during rolling

the rolling animation could just play during one tick

and event 6 could never be triggerd

rollRoll3.capx

by deactivating the behavior instead of ignoring input you can avoid thatYann2011-12-10 10:00:38

What you ask is not crystal clear but I think it's something like that:

jumpCap.capx

I think 30px/s�

Oh no I know you would.

That I didn't really know is if you would really understand all that I did (: (but that's a bit pretentious isn't it? :D)

rollRoll2.capx

hm?

The ability to be global exist 'cause it's possible. That is to say, you can have persistance of object through layout.

But for graphical object (I mean by that object that draw something on the layout (sprite, text, tiledbackground)), I don't think it's necessary and it leads to problems as the one we just encountered that is "where do you put global object when you don't have the same layer structure in different layout?"

For score and live representation, you just need something that would display it in each layout. What you want to be global (that is to say travel through layout) is data. It's just the number you don't want to be reset.

The graphical stuff... there's no reseting, it's juste your sprite and text boxes you use to display your game.

So for lives and score, just use global variables to keep them

and in each layout

system: every tick
     -> TextScore: set Text to score
     -> TextLife: set Text to lives

smitchRace.capx

Yeah I ignoring control wasn't a bad idea but if you want to totally kill any movement caused by the behavior, deactivation is better.

However you see that it's not always a good thing for the climbing thing for instance. You would have to be pixel precise for the sprite not to fall after climbing, thus I had to use the ignore instead of disable to let the PlayerDetect sprite falls during the climbing. So you won't have to play the stand animation after the climbing.

nah! there's a simple way, just use waypoints

unless you want to make some funky curvy path you will probably just have straight paths and turns.

So you just have to now when and where to turn.

You place some sprites with an instance variable called direction

Sprite.direction equal either 0,90,180 or -90

you probably have an entry point for your ennemies and a starting direction, you make them move in this direction and when they overlap the sprite you just change the angle of movement to the angle of Sprite.direction.