Weapon Alpha - Printable Version +- The VG Resource (https://www.vg-resource.com) +-- Forum: Creativity (https://www.vg-resource.com/forum-126.html) +--- Forum: Game Development (https://www.vg-resource.com/forum-129.html) +--- Thread: Weapon Alpha (/thread-27336.html) |
RE: Weapon Alpha - Bombshell93 - 07-03-2015 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 RE: Weapon Alpha - Valo - 07-03-2015 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. RE: Weapon Alpha - Bombshell93 - 07-03-2015 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 RE: Weapon Alpha - Valo - 07-05-2015 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}} 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? RE: Weapon Alpha - TheShyGuy - 07-05-2015 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. RE: Weapon Alpha - Valo - 07-05-2015 (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. Is there something in my code there that looks like a patch? If there is I'd like to fix it ASAP! RE: Weapon Alpha - TheShyGuy - 07-05-2015 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/dadiospice/002_reference/debugging/index.html http://docs.yoyogames.com/source/dadiospice/002_reference/debugging/show_debug_message.html For example, you'd put "show_debug_message()" at places of interest to ensure that certain things occur in an the expected order. RE: Weapon Alpha - Valo - 07-05-2015 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. RE: Weapon Alpha - TheShyGuy - 07-05-2015 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. RE: Weapon Alpha - Valo - 07-08-2015 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. RE: Weapon Alpha - Kitsu - 07-09-2015 I love the overheat bar so much RE: Weapon Alpha - Valo - 07-09-2015 what do you think of this effect? RE: Weapon Alpha - Gors - 07-10-2015 after that, add smoke particles for the entire duration of the overheat and you'll be ok RE: Weapon Alpha - TheShyGuy - 07-10-2015 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. RE: Weapon Alpha - Valo - 07-11-2015 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. |