The VG Resource

Pages: 1 2 3 4 5 6 7 8 9

there's no pro or con its purely a design choice, they should be functionally exactly the same too, barring ofc the flipped animation, if you're that stuck on them, wipe all you have on them and start from scratch, really it should just be,

Code:
//PSUEDO-CODE

previous_on_ladder = on_ladder

on_ladder = false

if colliding_with_ladder && can_climb_ladder { //if your within the bounds of a ladder and are allowed to climb

    on_ladder = true //assume you are on the ladder

}

if on_ladder { //assuming you are on the ladder

    if down_key_pressed { //if you are pressing down

        climb_down_ladder() //do whatever you want to do when climbing down

        player_state = on_ladder //confirm you are on the ladder via your state

    }

    else if up_key_pressed { //if you are pressing up

        climb_up_ladder() //do whatever you want to do when climbing up

        player_state = on_ladder //confirm you are on the ladder via your state

    }

    else if !previous_on_ladder { //if you were not previously on the ladder and are not pressing any ladder buttons

        on_ladder = false //then you have not told the character to latch on to the ladder yet, confirm not on the ladder via on_ladder = false

    }

}

//stuff handling when your not on a ladder as indicated by on_ladder = false

Functionally, they are not the same. These side ladders require being stuck to the sides of solid walls. And they cant be placed as fluidly or with as much versatility as a 'normal' ladder. Imagine some of the crazier climbing segments in Super Mario 2/doki doki panic if ladders could only be stuck on the sides of walls. The code for right side ladders as is could easily be modified into a blanket ladder code, with left side code deleted.

Thank you for the code advice though. I will give it a shot, but if i can't get these working by tonight, I'll probably just go with the standard ladder after all that was discussed on inc.

well like I said its a design choice, you actually gave a solid argument for why it becomes a limiting factor being stuck to the side of walls and honestly I can't think of anything that outweighs that, go with universal ladders, much more design freedom

Sorry, I deleted the previous post as i have one with a slight update and i could use some more advice...
[Image: AArKMce.gif]

The ladders work almost perfectly except for that frustrating hop when you reach the top. When the player's head collides with the pink tile at the top, he is supposed to instantly move up to right at the top of the ladder's 2way tile. The 2 way tile is nonsolid if you are under it, and solid if above. The issue lies in the line of code setting this off:

Code:
if onladder=true and vspeed=-1{ if place_meeting (x,y,obj_climbtick){y=ladder.y-26;onladder=false;canladder=false;image_speed = .20;alarm[2]=5;move=1;sprite_index=spr_idle;exit}}

let me break that down first.

If onladder true and vspeed -1: If you are in ladder state and climbing up. GM is weird in that the y axis uses negative numbers to indicate UP, rather than positive ones.

if place meeting x,y,climbtick: climbtick is that pink tile that your head collides with.

Y=ladder.y-26: the player's vertical position is set to instantly move to 26 pixels higher than the top of the ladder.

On ladder=false,etc: resets your state to the normal one and sets a five frame delay before you can climb a ladder again. I set this so you cant get stuck if you jump off a ladder while still holding up or down. 5 frames at 60fps is a hardly noticeable block.

The issue lies with if place_meeting (x,y,obj_climbtick){y=ladder.y-26.

The y position is too high, and valo actually enters his falling animation for a few frames. Now heres where things get interesting. 26 pixels is too high. 25 is too low. At 25, the player will fall as if they hit the jump button, as you dont go high enough to make the 2 way platform become solid.
I've been trying things all night and im out of ideas. Can anyone point me in the right direction?

It might have to do with other character's state code. It seems like it has to do with the way you have passable platforms. Personally, I prefer finding the problem and fixing it, instead of "patches". With "patches", you aren't fixing anything, you're covering it up- and not well. That issue will propagate elsewhere. Patch it up and you've got an unplayable crippled game.

That said... you could create a temporary ground solid for 5 frames anyways, which would push him up. That way, you can set the pixel offset to 25 without the player falling through.

(07-05-2015, 12:33 AM)TheShyGuy Wrote: [ -> ]It might have to do with other character's state code. It seems like it has to do with the way you have passable platforms. Personally, I prefer finding the problem and fixing it, instead of "patches". With "patches", you aren't fixing anything, you're covering it up- and not well. That issue will propagate elsewhere. Patch it up and you've got an unplayable crippled game.

That said... you could create a temporary ground solid for 5 frames anyways, which would push him up. That way, you can set the pixel offset to 25 without the player falling through.

Is there something in my code there that looks like a patch? If there is I'd like to fix it ASAP!

It's more about how you got about fixing problems. From the above code alone, I wouldn't know. It's up to you how far you go, though. You have to consider how practical it is, priority, is it game breaking, etc.

You know why the character falls when you have an offset of 25, but don't understand the hop at 26. Maybe there are rounding issues? Do you know the order in which your character data changes? For example:

...player input
...apply physics
...apply collision resolution
...draw everything

That's the typical order. There would be a visual issue if it was

...player input
...apply physics
...draw everything
...apply collision resolution

Then, your player would be seen a few pixels in the ground. Maybe, something similar is happening which makes the player pop up for a few frames (how many frames does it last?- ...5?).

If you still can't figure it out, you should try debugging. GM has a debugger, right? If it's not good enough, you can place debug messages that output to the console while the game is running.

http://docs.yoyogames.com/source/dadiosp...index.html
http://docs.yoyogames.com/source/dadiosp...ssage.html

For example, you'd put "show_debug_message()" at places of interest to ensure that certain things occur in an the expected order.

A big thanks to Terminal Devastation for helping me get the ladders sorted. I need to start working on the shooting code now.

Edit: sorry, leaving it like that makes it look I'm dismissing your input TSG, that's not my intent. I hadn't had a chance to use the debug method on the ladder code this time around, but I'll definitely keep those for future use. Thank you.

Haha, don't worry about it. My intent was to help fix the problem- and your problem has been fixed. I don't see any issues with that.

Ive fixed the beam animations (not shown in this gif, sorry) and i was trying to rework the overheat bar a bit. Is it more noticeable than the ones in the other gifs? I'll most likely still have a smoke particle spawn out of the players hand when the bar gets in the red zone too.

I love the overheat bar so much

what do you think of this effect?

after that, add smoke particles for the entire duration of the overheat and you'll be ok

Oh I just noticed the laser becomes unstable near overheat. It's a nice touch and removes the need for the player to look at the overheat bar. Like Gors said, you should add some kind of effect during the overheat cool down to further remove the need to look up there.

I'm trying to code some of the simpler enemy concepts in starting with the scuttle enemies. Think like...killer roombas.

[Image: csuuE9o.gif]

I got the motion working, pretty simple stuff. Red koopa level stuff, not really a big deal.
"You know what would be cute/neat? If they had a little surprised anim when they bump a wall or encounter a ledge!"
"you have a point personman , lemme try to add that in!"
[Image: Q2Da1TS.gif]

ooh.

oooooooooooooooooooh no.
Isnt coding fun.

Pages: 1 2 3 4 5 6 7 8 9

Bombshell93

Valo

Bombshell93

Valo

TheShyGuy

Valo

TheShyGuy

Valo

TheShyGuy

Valo

Kitsu

Valo

Gors

TheShyGuy

Valo