Posts: 607
Threads: 25
Joined: Mar 2012
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
Posts: 269
Threads: 3
Joined: Sep 2013
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.
Posts: 607
Threads: 25
Joined: Mar 2012
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
Posts: 269
Threads: 3
Joined: Sep 2013
07-05-2015, 12:01 AM
(This post was last modified: 07-05-2015, 12:12 AM by Valo.)
Sorry, I deleted the previous post as i have one with a slight update and i could use some more advice...
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?
Posts: 524
Threads: 9
Joined: Jul 2012
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.
Posts: 269
Threads: 3
Joined: Sep 2013
(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!
Posts: 524
Threads: 9
Joined: Jul 2012
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.
Posts: 269
Threads: 3
Joined: Sep 2013
07-05-2015, 07:00 PM
(This post was last modified: 07-05-2015, 07:16 PM by Valo.
Edit Reason: I looked like a dick leaving it like that. :I
)
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.
Posts: 524
Threads: 9
Joined: Jul 2012
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.
Posts: 269
Threads: 3
Joined: Sep 2013
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
Posts: 269
Threads: 3
Joined: Sep 2013
what do you think of this effect?
after that, add smoke particles for the entire duration of the overheat and you'll be ok
Posts: 524
Threads: 9
Joined: Jul 2012
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.
Posts: 269
Threads: 3
Joined: Sep 2013
I'm trying to code some of the simpler enemy concepts in starting with the scuttle enemies. Think like... killer roombas.
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!"
ooh.
oooooooooooooooooooh no.
Isnt coding fun.
|