next »

[jacksnappert]

First time poster, long time listener!

Right now I'm working on a platformer, where a move of the main character is climbing up and onto a block as tall as they are. In this 60 fps game, the move takes a full second/60 frames to complete. I'm having difficulty trying to get the animation to run, and also thinking of a way to disable key events during it.

Right now the animation system relies on the step event of the main character holding two halves: logic (movement and key events) and animation (basically a bunch of if statements, that do a ton of sprite_index reassignments).

My main's logic for climbing looks something like this:

Code:

if (right key pressed)
    //Move, set flag that object is going right
    if (is on ground and climbable object is immediately to the right and up key pressed)
        //Set climbing flag, change object position

And then the animation portion has an if statement for the climbing flag and then a sprite_index = climbingSprite. The climbing sprite has also been stretched out to 60 frames.

Whew, this is a lot.

So, in a sum up, why isn't the animation playing out, and when I do get it to play out, how do I ignore addition key events?

I'm thankful for any help I can get - this is my first game, and while I expected this to be a task, I'm constantly surprised by how many roadblocks I'm hitting.

[Hima]

I don't quite understand your problem. From what I can gather, the sprite is shown and changed according to your code but they aren't animated? If so, you might want to check the image_speed of your player object.

[ChevyRay]

Can you post the actual code? It'll make it easier to determine where you're going wrong. There are many factors that could be your problem here, and there's not really any way to tell if it's your animation handling, your wall-detection, etc.

[bateleur]

when I do get it to play out, how do I ignore addition key events?

Usually the easiest way to do stuff like this is just to set a flag. So your climb code would include something like "disableControls = true" and then you use something like "if (keyPressed(right) && !disableControls) {walk right}".

[jacksnappert]

I don't quite understand your problem. From what I can gather, the sprite is shown and changed according to your code but they aren't animated? If so, you might want to check the image_speed of your player object.

Sorry I was unclear. It's the sprite itself that isn't showing up, despite changing the spite_index.

Sorry ChevyRay - here you go, this is the code executed inside the main's step event:

Code:

/* Physics and input code credit goes to Matt Thorson (mattmakesgames.com) */

//Friction handling
var accel, fric;
if (on_ground) {
    fric = S_RUN_FRIC;
} else {
    fric = S_AIR_FRIC;
}

/*      OBJECT LEFT-RIGHT DETECTION        */
//If solid object is immediately to the right, rNext flag true
if (place_meeting( x + 1, y, block )){
    rNext = true;
//If solid object is immediately to the left, lNext flag true
}else if (place_meeting( x - 1, y, block )){
    lNext = true;
}else{
    rNext = false;
    lNext = false;
}

/*      PLAYER INPUT EVAL       */
if (keyboard_check_direct( vk_right )) {
    //Running right
    rflag = true;
    hspd = approach( 2, S_MAX_H, 0);
    
    //Climbing to the right
    if (on_ground && rNext && (keyboard_check_direct( vk_up ))){
        //Set flag for display
        climbing = true;
        //Reposition character
        x += 32;
        y -= 32;
    }
} else if (keyboard_check_direct( vk_left )) {
    //Running left
    rflag = false;
    hspd = approach( -2, -S_MAX_H, 0); 
} else {
    //Stopping
    hspd = approach( hspd, 0, fric);
}

if (on_ground) {
    vflag = false;
    //Jumping
    if (keyboard_check_pressed( vk_up )){
        vspd = S_JUMP_SPEED;
        vflag = true;
    }

} else {
    //Gravity
    vspd = approach( vspd, S_MAX_V, S_GRAVITY );
}


/*      DRAWING EVAL        */
//All sprites are 32 x 32, with origins at (16,16).
//Exception is climb sprite, which is 64x64, with origin at (32,32)
//This is the bit I'm having trouble with. The climb animation is the character 
//scrambling up and over a 32 x 32 block
if (climbing){
    sprite_index = climb;
}
if (on_ground){
    //If unmoving, or if next to an object (so it doesn't keep running at walls)
    if(hspd == 0 || rNext || lNext){
        if (rflag){
            sprite_index = amRStand;
        }
        else{
            sprite_index = amLStand;
        }
    }else if((hspd > 0) && !rNext){
        sprite_index = amRWalk;
    }else if ((hspd < 0) && !lNext){
        sprite_index = amLWalk;
    }
}else{
    if (rflag){
        sprite_index = amRJump;
    }else{
        sprite_index = amLJump;
    }
}

Right now, only climbing to the right is implemented. In its current state, when the character is immediately next to a block, and the player presses right and then subsequently up, the character will instantly be transported up and to the right by 32 pixels, without being changed to the climb sprite (it also continues having upward velocity, but I'll fix that later ). Right now I'm just trying to get it to display (which explains the lack of making the climbing flag false, eh heh) but finalized, the key combo will change the character sprite to the climbing sprite, and when the animation is done with, the character will change back to a standing sprite and have been moved to the final position(up and to the right by 32) that the animation indicates.

bateleur: I actually don't know what in GML will allow me to ignore key events, that is, what code will be executed if I do set a disableKey flag. The only thing I can think of is somehow setting up a timed loop (though I don't know how to do that, either -_-) with no key detection code that will start when the animation starts to play, and then stop when the animation is done.

[Draknek]

Code:

if (climbing){
    sprite_index = climb;
}
if (on_ground){

That second if should be an else if.

If you're planning to add more states like this later, you might find that it's easier to have one state variable (which is either climbing/on ground/jumping) rather than having lots of different boolean flags.

[bateleur]

bateleur: I actually don't know what in GML will allow me to ignore key events, that is, what code will be executed if I do set a disableKey flag. The only thing I can think of is somehow setting up a timed loop (though I don't know how to do that, either -_-) with no key detection code that will start when the animation starts to play, and then stop when the animation is done.

I'm not suggesting that you ignore key events, I'm suggesting that you set a flag which is examined within your key event handler and which causes the handler to execute different code via something as simple as an "if/else" structure.

[jacksnappert]

Draknek: That was exactly it! Thanks.

bateleur: Ah, I see what you mean now. I think I'll set a disableKey after the key combination, and then an alarm that when it goes off (after the alarm finishes) will change the flag. Thanks!

[Craig Stern]

My immediate thought was what bateleur suggested. I usually use a single boolean variable canMove that is true by default, but is temporarily switched to false by certain events, then switched back to true by the conclusion of those events.