Yann's Forum Posts

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

  • 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

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

  • 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)

  • 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

    TextScore and TextLife are Text object but they doen't need to be global, it's the variable that need to be, the data.

    And as I said in a post long time ago, there's generally not that much global stuff in a game.

    Unless you want a big stat layout with number of kill, number of death, precision of shoting, etc

  • 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.

  • AArgh... You can't put that in properties. The property box will take all that you enter in it as a string, it won't parse any variable.

    You have to write that kind of stuff in event

    System: Every tick -> Text: set Text to "Score :"&Score

  • With the Physics behavior you have access to X and Y velocity, you just have to check if it's equal to 0. If it is, it means the sprite doesn't move.

    Also you might want to check if it's less than a small value. 'Cause it might take time to completely stop. Just test.

    Example:

    System: Sprite.Physics.VelocityX < 0.01
System: Sprite.Physics.VelocityY < 0.01
   -> Sprite: set moving to false

  • Depend if you use a behavior

    If you don't you might want to use a behavior

    If you can't just explain your situation a bit more