This video really REALLY helped me get my mind around the coding part of Dreams, and I'm grateful for that. I just wish you moved, like, 20% slower lol. It was a little difficult to keep up at times.
Little editor's note. The reason it sometimes bounces you off like at 16:00 is because the signal manipulator for jumping away from the ladder is at the wrong spot. Instead of being after the AND gate, it should be placed BEFORE it to proces the X button input. ANOTHER SIDENOTE: if you're using the platformer puppet base, for some reason the sliding behaviour interferes with the rotation and will make your puppet shake when holding onto the ladder. Something in the sliding logic is acting up when it shouldn't, since you're not sliding. For now, disable that microchip to use this ladder climb method.
Excellent vid! It helped me make my ladder logic work! You might also want to consider adding a way for the puppet to center on the ladder. The thing that i did was i placed a cube inside the rectangular box that is the "ladder". This cube is then set up to follow the puppet. The catch is it only follows the puppet's y value. This means the cube can only travel vertically or up and down. Now on the cube is a tag. This tag is meant so the puppet teleports to this tag with a pulse. Then the teleport logic shuts off when you latch onto the ladder. That way you will always center on the ladder. (Your logic causes it so you can climb almost any part of the ladder). Thank you for this helpful tutorial! I hope my suggestion helps you and anyone else! Keep in mind it will take quite of bit of tweaking and trial and error to implement my idea (because it took me awhile lol)
The spaghetti! The horror! ;P The regular "left stick" is camera relative, for use with the puppet's run direction. So "up" moves away from the camera along a flat plane, basically. That's why it seems funky. So yeah, if you want just the actual stick direction and not camera-relative, using local is the way to do it. It wasn't clear why you needed to move the tag position. I'm guessing it's just because you didn't make the trigger zone go down beyond the ground, which should fix it also. Similarly, I don't think you explained why you added the trigger zone, as it was already working. Is it so that you can only get onto the ladder from one side? Making sure that is clear will let the viewer skip that part if they *do* want to allow the player to get onto the ladder from either side. (If I missed that part, I apologise.) A good way of keeping the gadgets tidy and more understandable is to use chips. For example, a great use is to place all the stuff that needs to be powered while climbing into a chip, and then simply power that whole chip to power everything inside. This is a little more efficient because you use fewer wires, but it's also a lot more understandable from a viewer/user's perspective because they don't see a load of wires and gadgets all over the place. ;P (Note these tips are generally for making tutorials. I mean, make things however you like. But these are ideas to think about to make the learning experience easier on the viewer. Do what you like with it.) You also only have to think about one thing at a time. When you look at one part all you see is "are we climbing?" then if we're climbing, we power on the climbing logic. Open the chip to see that. So we know we're climbing in here... "are we jumping?" then let's power this other chip. And so on. Crossed wires also are hard to understand, which grouping things into chips tends to help with a bit also. Ideally each wire should be clearly followable through the whole chip without breaking light of sight at all. This could mean spacing things out more, but that's preferable to the viewer getting all confused by things, in my book. Another way of doing something for some period of time in a less direct/logic/wirey way is to use a timeline. To turn off the climb detection part I would have a short timeline with a keyframe on it that powers off that AND gate, for example. Fewer (visible) wires, easier to understand what it's doing, etc. (I'll finish watching a bit later.)
Oh hey! I appreciate the advice. I kinda went into this mostly unprepared, so this will help me a lot should I make another one of these :) I tend to underutilize chips beyond just the initial grouping of a mechanic, but you're absolutely right in that they make things much easier to understand both for myself and for the viewer!
A rocket rotator would work better for when you jump away. It rotates the object to "face" the way it's moving. Another thing to think about is performance optimisation. The fewer gadgets you have powered at once, the less processing the engine has to do. So here you could leave the tag on--as that's pretty cheap to begin with. When the tag is in that trigger zone, power a chip with the detection part in it. If that detects you're climbing, power the chip with the "while climbing" stuff in it. This way almost all of the time it's only looking to see if the tag is in the zone without using the laser scoped and AND gates and timers and everything else. May not make a massive difference depending on the game, but it goes hand-in-hand with the organisation aspect of using chips so I thought I'd mention it ^^ Another tip for learnability: when you've built out some flow of logic, summarise what's happening. "So now if this is true and that is true, while climbing... the timeline will work. But also it will play forwards while pushing up, and backwards while pushing down." And maybe demonstrate these things as you go too, so it's clear what the thing you just made actually does, before making a new part. Something you can do to have "do this while true" and "do this while false" is to wire the test result (true/false) into a selector's "active port." That will send a signal out of channel A while false, and channel B while true. Well done on making tutorials by the way. The more the merrier! Subbed!
Thanks :) it's a little counter intuitive, but it has to do with the information about the detected angle the laser scope sends to the look at rotator. In any other case you would probably want to just point it forward, but not when using the laser scope like this!
Is anyone else getting any weird drift while climbing the ladder? The Player Character keeps drifting to the left for me and I have no idea why. I went into the keyframe and changed the puppet turn speed to zero but still having some issues for some reason
You might want to add a keyframe that turns movement off in the puppets tweak menu. That might solve the drift issue. I had a similar drift that drifted up but when i added this keyframe it stopped the issue.
Huge thanks! Quick animation question. The game detects that I'm above ground and thus triggers my puppet to the inbuilt jump descent posture, which interferes with my climbing and idle animation on the ladder. Even though I turn off all procedural animations this happens. Any ideas? I need to indicate to the system that I'm actually not freefalling somehow.
Hmm, are these animations on a different microchip? If so, you could turn off that whole microchip with the keyframe that also controls air control/turn speed. Otherwise I wouldn't really know I'm afraid.
@@yeaown8139 But there is a puppet interface that has its jump ascend/peak/descent hooked up to three keyframes, right? If so, you could power off the puppet interface with the keyframe I mentioned before.
I'm having trouble getting this to work with a first-person puppet. Do you anticipate any issues with it in this case? The ladder pushes me back, sometimes I glide for a bit and slide off. But I followed all of your instructions.
I solved it just now I was so stressed, I had to go to labels for the Lazer Scope and turn off “Unlabeled” because that’s apparently what the puppet is 😭😭😭😭😭
This video really REALLY helped me get my mind around the coding part of Dreams, and I'm grateful for that.
I just wish you moved, like, 20% slower lol. It was a little difficult to keep up at times.
Little editor's note. The reason it sometimes bounces you off like at 16:00 is because the signal manipulator for jumping away from the ladder is at the wrong spot. Instead of being after the AND gate, it should be placed BEFORE it to proces the X button input.
ANOTHER SIDENOTE: if you're using the platformer puppet base, for some reason the sliding behaviour interferes with the rotation and will make your puppet shake when holding onto the ladder. Something in the sliding logic is acting up when it shouldn't, since you're not sliding. For now, disable that microchip to use this ladder climb method.
Well, thank you! Spot on!
This is the clearest and most concisely anyone has explained this method, really impressive. thank you.
This was the most detailed tutorial about ladder climbing, you make it look simple and I actually learned a lot, thanks for the awesome tutorial.
Excellent vid! It helped me make my ladder logic work! You might also want to consider adding a way for the puppet to center on the ladder.
The thing that i did was i placed a cube inside the rectangular box that is the "ladder". This cube is then set up to follow the puppet. The catch is it only follows the puppet's y value. This means the cube can only travel vertically or up and down. Now on the cube is a tag. This tag is meant so the puppet teleports to this tag with a pulse. Then the teleport logic shuts off when you latch onto the ladder. That way you will always center on the ladder. (Your logic causes it so you can climb almost any part of the ladder).
Thank you for this helpful tutorial! I hope my suggestion helps you and anyone else! Keep in mind it will take quite of bit of tweaking and trial and error to implement my idea (because it took me awhile lol)
VERY helpful! Going to be practicing man!
Excellent tutorial! After seeing your amazing character on Reddit I was thrilled to find out you're doing tutorials. Keep it up!
You have a very clear way of explaining things, I look forward to ur future videos
This is perfect! Very clean! Just what I was looking for, thank you so much!
Great lesson, would love to see your wall run/
wall jump tutorial keep it up
The spaghetti! The horror! ;P
The regular "left stick" is camera relative, for use with the puppet's run direction. So "up" moves away from the camera along a flat plane, basically. That's why it seems funky. So yeah, if you want just the actual stick direction and not camera-relative, using local is the way to do it.
It wasn't clear why you needed to move the tag position. I'm guessing it's just because you didn't make the trigger zone go down beyond the ground, which should fix it also.
Similarly, I don't think you explained why you added the trigger zone, as it was already working. Is it so that you can only get onto the ladder from one side? Making sure that is clear will let the viewer skip that part if they *do* want to allow the player to get onto the ladder from either side. (If I missed that part, I apologise.)
A good way of keeping the gadgets tidy and more understandable is to use chips. For example, a great use is to place all the stuff that needs to be powered while climbing into a chip, and then simply power that whole chip to power everything inside. This is a little more efficient because you use fewer wires, but it's also a lot more understandable from a viewer/user's perspective because they don't see a load of wires and gadgets all over the place. ;P
(Note these tips are generally for making tutorials. I mean, make things however you like. But these are ideas to think about to make the learning experience easier on the viewer. Do what you like with it.)
You also only have to think about one thing at a time. When you look at one part all you see is "are we climbing?" then if we're climbing, we power on the climbing logic. Open the chip to see that. So we know we're climbing in here... "are we jumping?" then let's power this other chip. And so on.
Crossed wires also are hard to understand, which grouping things into chips tends to help with a bit also. Ideally each wire should be clearly followable through the whole chip without breaking light of sight at all. This could mean spacing things out more, but that's preferable to the viewer getting all confused by things, in my book.
Another way of doing something for some period of time in a less direct/logic/wirey way is to use a timeline. To turn off the climb detection part I would have a short timeline with a keyframe on it that powers off that AND gate, for example. Fewer (visible) wires, easier to understand what it's doing, etc.
(I'll finish watching a bit later.)
Oh hey! I appreciate the advice. I kinda went into this mostly unprepared, so this will help me a lot should I make another one of these :) I tend to underutilize chips beyond just the initial grouping of a mechanic, but you're absolutely right in that they make things much easier to understand both for myself and for the viewer!
A rocket rotator would work better for when you jump away. It rotates the object to "face" the way it's moving.
Another thing to think about is performance optimisation. The fewer gadgets you have powered at once, the less processing the engine has to do. So here you could leave the tag on--as that's pretty cheap to begin with. When the tag is in that trigger zone, power a chip with the detection part in it. If that detects you're climbing, power the chip with the "while climbing" stuff in it. This way almost all of the time it's only looking to see if the tag is in the zone without using the laser scoped and AND gates and timers and everything else.
May not make a massive difference depending on the game, but it goes hand-in-hand with the organisation aspect of using chips so I thought I'd mention it ^^
Another tip for learnability: when you've built out some flow of logic, summarise what's happening. "So now if this is true and that is true, while climbing... the timeline will work. But also it will play forwards while pushing up, and backwards while pushing down." And maybe demonstrate these things as you go too, so it's clear what the thing you just made actually does, before making a new part.
Something you can do to have "do this while true" and "do this while false" is to wire the test result (true/false) into a selector's "active port." That will send a signal out of channel A while false, and channel B while true.
Well done on making tutorials by the way. The more the merrier! Subbed!
nice tutorial, great pacing.. subbed :)
Dude awesome tutorial! So thorough, loved it. You got a sub from me! :)
Side question: why did you place the follower in the backwards direction?
Thanks :) it's a little counter intuitive, but it has to do with the information about the detected angle the laser scope sends to the look at rotator. In any other case you would probably want to just point it forward, but not when using the laser scope like this!
You are a legend
no u
I will give this a go !
Is anyone else getting any weird drift while climbing the ladder? The Player Character keeps drifting to the left for me and I have no idea why. I went into the keyframe and changed the puppet turn speed to zero but still having some issues for some reason
You might want to add a keyframe that turns movement off in the puppets tweak menu. That might solve the drift issue. I had a similar drift that drifted up but when i added this keyframe it stopped the issue.
never realised the "tag output" went high if the tag is being detected.. i've built all sorts of schemes otherwise.. tysm!
thank you!
Huge thanks! Quick animation question. The game detects that I'm above ground and thus triggers my puppet to the inbuilt jump descent posture, which interferes with my climbing and idle animation on the ladder. Even though I turn off all procedural animations this happens. Any ideas? I need to indicate to the system that I'm actually not freefalling somehow.
Hmm, are these animations on a different microchip? If so, you could turn off that whole microchip with the keyframe that also controls air control/turn speed. Otherwise I wouldn't really know I'm afraid.
@@Stuifie3 No, they are on the same chip :/
@@yeaown8139 But there is a puppet interface that has its jump ascend/peak/descent hooked up to three keyframes, right? If so, you could power off the puppet interface with the keyframe I mentioned before.
Nice
I'm having trouble getting this to work with a first-person puppet. Do you anticipate any issues with it in this case?
The ladder pushes me back, sometimes I glide for a bit and slide off. But I followed all of your instructions.
In the end I decided to use separate cameras for first person climbing and it's a lot smoother.
I've watched this video about a dozen times and I just can't get it to work. The ladder seems to repel my anytime I get near it.
I've made a remixable version so you can check the logic yourself and compare it. indreams.me/scene/dXcvqAnoFBj
sounds like you have one of the gizmos pointed in the wrong way
I solved it just now I was so stressed, I had to go to labels for the Lazer Scope and turn off “Unlabeled” because that’s apparently what the puppet is 😭😭😭😭😭
Awesome. Will this work for a 2D platformer
I think it should!
Angelotje
It kinda works for 2D. It’s trickier. Everything works, but I can’t get my character to face the ladder
Dosent work, it's just makes the puppet glitch into the ground and move towards 0.0 or whatever
Omg you sound so much like jonochrome its scary 😭😭
Ik kan me niet concentreren door die Nederlandse accent LuL