5:51 Big tip: use invisible, intangible fancy objects to sense if the player is touching a certain type of object. For example, maybe you have a touch sensor that """kills""" the player whenever you touch a crate. Now you just need to add invisible crates to places the player should die in. If you have a lot of these places, this won't be optimal. Edit: This works a lot better for setups where you want something special to happen with certain blocks / things. Like "if the player gets on this launchpad, they launch". Just make every launchpad have an invisible fish and set a touch sensor to sense fish and launch the player.
Addendum: In most cases, the platforms that a player uses are almost exclusively Boxes, not Cylinders or Spheres. This essentially gives you two more Fancy Objects, with Cylinders being especially helpful since you can stretch their height without making it any wider.
Your multi-checkpoint system with the 2D marker for "checkpoint validation" has a serious flaw. The way you're using that counter to save the current checkpoint, it's really only storing the *number* of checkpoints obtained, not the actual unique checkpoint itself. As a result, it will only work correctly if the player gets the checkpoints in order, which is why you then need that validation setup that only lets you collect the checkpoints sequentially. This is pretty restrictive to the level design: if a player collects CP1, then takes a path that skips CP2 and brings them to CP3, they should not be punished by blocking that CP3 for them; they should be allowed to collect *any* CP that comes after their current one. But using just a plain counter to save the CP, as I said, only counts how many CPs you've collected, so it can't determine which CP they're at in these scenarios. A better way is to instead replace the plain counter with a variable store (i.e. a counter leading into a subtract nodon, then into a multiplier for a write-enable input, then back into the counter). This way, you can store not just "how many CPs?" but explicitly " *which* was the last CP?" And that enables you to do all your validation with only two nodons regardless of the number of CPs you have: your write-enabled input passes through a second multiplier that gets enabled if the current CP variable is less than the new one. By using a variable store, you can now allow (practically) infinite CPs, prevent CP-regression, allow the player to skip ahead past some CPs if they're adventurous/skilled, and do it all with only 5 nodons.
Yeah.... you only get the checkpoint if you get them in order. That is an *intentional* *anti-cheese* *measure* . If you want to allow the player to be able to skip checkpoints for whatever reason, just make the continuous markers go up vertically (taller nodons) to cover multiple Y values for future checkpoints. The alternate way to do this would be to pass (checkpoint ID > counter) with a comparison nodon straight into the counter increment port. Variable storing in GBG is absolutely terrible. You want to use it only as a last resort because it leads to issues of assigning/resetting numbers on different frames. I strongly recommend avoiding storing variables like the plague.
@@loupandsnoop "If you want to allow the player to be able to skip checkpoints for whatever reason, just make the continuous markers go up vertically (taller nodons) to cover multiple Y values for future checkpoints." But won't that still just add 1 to the counter, thus making it impossible to know which checkpoint they have when they restart? "Variable storing in GBG is absolutely terrible. You want to use it only as a last resort because it leads to issues of assigning/resetting numbers on different frames. I strongly recommend avoiding storing variables like the plague." Um... why? What downside is there to it? I can't imagine using any real programming language without variables (at least, not for one that also doesn't have loops like GBG lacks). Why should we not store values in variables in GBG? As long as you have a multiplier nodon for a "write-enable" buffer, there should be no race conditions. I've been using variables like that in basically every game in GBG and though all of my development, testing, and gameplay, I have never encountered any race condition problems. Even the very populate Tetris clone made in GBG uses them all over the place, and while I've seen many people play it many times, I haven't seen any bugs. Have you ever actually encountered a bug caused by race conditions on a write-enable-buffered variable store in GBG?
@@IceMetalPunk As long as the touch sensor is set to "WHILE TOUCHED", the player will still be on the checkpoint for the following frame. Then, the very next frame you'll get another +1 to the counter, and you'll keep getting +1 every frame until the CP ID is out of range. It just takes a few extra frames to get there, and you can add a timer/flag if you are paranoid that the player will only contact the CP for 1-2 frames. To be clear, this system is like the checkpoint system in Mario Kart. Mario kart has key checkpoints that you cannot skip during normal play, and the game will refuse to count your lap unless you go to every single key checkpoint. This is an anti-cheating mechanic, as you can't really "drive around" the checkpoints normally. Of course, if this style isn't compatible with your level structure, just use a CP validation setup that is more in line with your vision.
@@IceMetalPunk On variable storage (I didn't see you had more), yes it is garbage in GBG. A multiplier nodon is not the same as a variable. A proper variable storage setup uses the counter nodon and its reset port to store a number. The problem is that the reset port and count up ports need to be activated on different frames. This makes it so that your assignment happens some frame(s) after you were ready to assign it AND the variable's value is only usable some number of frames AFTER you mean to assign the variable. That's a huge problem because most code assumes that everything happens on the same frame. So you have to calculate with a number that you don't have yet, and have to store a number that may have just changed a moment ago. This leads to serious jank.
@@loupandsnoop I can definitely see the problem with that kind of setup, but that's not the type of variable storage I'm talking about. The one I'm talking about requires no use of the reset port at all. It's hard to discuss GBG code in text, but basically, what I mean is you start with a counter, which is where the actual value will be stored. The counter is the "variable", if you will. You run its value into the second input port of a subtraction nodon; the first port you'd set to whatever value you're trying to store. Then you take the result of the subtraction and put it into a multiplier nodon, which will act as a "write-enable" buffer/gate: when the second input to it is 0, the output is 0, when it's 1, then the result of the subtraction is passed through. You connect that final result back to the counter's Count Up port. No reset port needed. With that wiring, the calculation performs as follows: the subtraction nodon calculates how much needs to be added or subtracted from the counter to set it to the desired value. If the multiplier buffer's input is 1, that value then goes through to the counter and gets added, thus setting it to the proper value. If the multiplier buffer's input is 0, then it just sends 0 into the Count Up port and nothing changes. With this setup, as long as the multiplier buffer is 1, the counter will just automatically change to match the desired value input with no frame delay, and when the multiplier is set to 0, it just "freezes" the counter from changing.
If you want to add in effect to this but not have let’s play over and over again when the player passes by it. Then you can instead of the touch sensor nodon, you can use an object break nodon and add a dustractible object to the checkpoint.
I don't have the game i just like these tutorials
Same
I'm still glad you like the content.
@@loupandsnoop how do i do the random encounter thing like when you step in grass in pokemon
Same here
@@theguy9777 rng nodon
5:51 Big tip: use invisible, intangible fancy objects to sense if the player is touching a certain type of object. For example, maybe you have a touch sensor that """kills""" the player whenever you touch a crate. Now you just need to add invisible crates to places the player should die in. If you have a lot of these places, this won't be optimal.
Edit: This works a lot better for setups where you want something special to happen with certain blocks / things. Like "if the player gets on this launchpad, they launch". Just make every launchpad have an invisible fish and set a touch sensor to sense fish and launch the player.
Addendum: In most cases, the platforms that a player uses are almost exclusively Boxes, not Cylinders or Spheres. This essentially gives you two more Fancy Objects, with Cylinders being especially helpful since you can stretch their height without making it any wider.
YES
FINALLY
I'VE BEEN WAITING FOREVER FOR SOMEONE TO FIGURE THIS OUT
Well done. Might use this in an update of my stage for the secret stage with in.
Always wanted to make these but never knew how, thanks!
Whoever managed to make the Swap-Game Nodon work properly was a genius.
Your multi-checkpoint system with the 2D marker for "checkpoint validation" has a serious flaw. The way you're using that counter to save the current checkpoint, it's really only storing the *number* of checkpoints obtained, not the actual unique checkpoint itself. As a result, it will only work correctly if the player gets the checkpoints in order, which is why you then need that validation setup that only lets you collect the checkpoints sequentially. This is pretty restrictive to the level design: if a player collects CP1, then takes a path that skips CP2 and brings them to CP3, they should not be punished by blocking that CP3 for them; they should be allowed to collect *any* CP that comes after their current one. But using just a plain counter to save the CP, as I said, only counts how many CPs you've collected, so it can't determine which CP they're at in these scenarios.
A better way is to instead replace the plain counter with a variable store (i.e. a counter leading into a subtract nodon, then into a multiplier for a write-enable input, then back into the counter). This way, you can store not just "how many CPs?" but explicitly " *which* was the last CP?" And that enables you to do all your validation with only two nodons regardless of the number of CPs you have: your write-enabled input passes through a second multiplier that gets enabled if the current CP variable is less than the new one.
By using a variable store, you can now allow (practically) infinite CPs, prevent CP-regression, allow the player to skip ahead past some CPs if they're adventurous/skilled, and do it all with only 5 nodons.
Yeah.... you only get the checkpoint if you get them in order. That is an *intentional* *anti-cheese* *measure* . If you want to allow the player to be able to skip checkpoints for whatever reason, just make the continuous markers go up vertically (taller nodons) to cover multiple Y values for future checkpoints.
The alternate way to do this would be to pass (checkpoint ID > counter) with a comparison nodon straight into the counter increment port.
Variable storing in GBG is absolutely terrible. You want to use it only as a last resort because it leads to issues of assigning/resetting numbers on different frames. I strongly recommend avoiding storing variables like the plague.
@@loupandsnoop "If you want to allow the player to be able to skip checkpoints for whatever reason, just make the continuous markers go up vertically (taller nodons) to cover multiple Y values for future checkpoints."
But won't that still just add 1 to the counter, thus making it impossible to know which checkpoint they have when they restart?
"Variable storing in GBG is absolutely terrible. You want to use it only as a last resort because it leads to issues of assigning/resetting numbers on different frames. I strongly recommend avoiding storing variables like the plague."
Um... why? What downside is there to it? I can't imagine using any real programming language without variables (at least, not for one that also doesn't have loops like GBG lacks). Why should we not store values in variables in GBG? As long as you have a multiplier nodon for a "write-enable" buffer, there should be no race conditions. I've been using variables like that in basically every game in GBG and though all of my development, testing, and gameplay, I have never encountered any race condition problems. Even the very populate Tetris clone made in GBG uses them all over the place, and while I've seen many people play it many times, I haven't seen any bugs. Have you ever actually encountered a bug caused by race conditions on a write-enable-buffered variable store in GBG?
@@IceMetalPunk As long as the touch sensor is set to "WHILE TOUCHED", the player will still be on the checkpoint for the following frame. Then, the very next frame you'll get another +1 to the counter, and you'll keep getting +1 every frame until the CP ID is out of range. It just takes a few extra frames to get there, and you can add a timer/flag if you are paranoid that the player will only contact the CP for 1-2 frames.
To be clear, this system is like the checkpoint system in Mario Kart. Mario kart has key checkpoints that you cannot skip during normal play, and the game will refuse to count your lap unless you go to every single key checkpoint. This is an anti-cheating mechanic, as you can't really "drive around" the checkpoints normally. Of course, if this style isn't compatible with your level structure, just use a CP validation setup that is more in line with your vision.
@@IceMetalPunk On variable storage (I didn't see you had more), yes it is garbage in GBG. A multiplier nodon is not the same as a variable. A proper variable storage setup uses the counter nodon and its reset port to store a number. The problem is that the reset port and count up ports need to be activated on different frames. This makes it so that your assignment happens some frame(s) after you were ready to assign it AND the variable's value is only usable some number of frames AFTER you mean to assign the variable. That's a huge problem because most code assumes that everything happens on the same frame.
So you have to calculate with a number that you don't have yet, and have to store a number that may have just changed a moment ago. This leads to serious jank.
@@loupandsnoop I can definitely see the problem with that kind of setup, but that's not the type of variable storage I'm talking about. The one I'm talking about requires no use of the reset port at all.
It's hard to discuss GBG code in text, but basically, what I mean is you start with a counter, which is where the actual value will be stored. The counter is the "variable", if you will. You run its value into the second input port of a subtraction nodon; the first port you'd set to whatever value you're trying to store. Then you take the result of the subtraction and put it into a multiplier nodon, which will act as a "write-enable" buffer/gate: when the second input to it is 0, the output is 0, when it's 1, then the result of the subtraction is passed through. You connect that final result back to the counter's Count Up port. No reset port needed.
With that wiring, the calculation performs as follows: the subtraction nodon calculates how much needs to be added or subtracted from the counter to set it to the desired value. If the multiplier buffer's input is 1, that value then goes through to the counter and gets added, thus setting it to the proper value. If the multiplier buffer's input is 0, then it just sends 0 into the Count Up port and nothing changes.
With this setup, as long as the multiplier buffer is 1, the counter will just automatically change to match the desired value input with no frame delay, and when the multiplier is set to 0, it just "freezes" the counter from changing.
and well now we can make levels a lot longer, thanks as always loup :)
I just realized multiplication calculator nodon is similar to AND nodon. The difference is AND outputs 1
Yes
14:26 in order to mask the quick teleportation visual flaw, you can use a black block masking the camera that disapear after the game started.
what like... launch a object that doesn't move then teleport it if you don't "die"
If you want to add in effect to this but not have let’s play over and over again when the player passes by it. Then you can instead of the touch sensor nodon, you can use an object break nodon and add a dustractible object to the checkpoint.
Im making an rpg...how do i do after swap (battle) is over it doesn't lose location and destroys enemy?
I'll be coming out with another video on storing multiple bits of data soon.
I dislike that one person that disliked the video.
i was 8 hours late
Tks so much
HOW I DONT KNOW HOW