My Review of Hoppy Days

[Ace_theSuperVillain]

I wrote down some observations about the Hoppy Days lesson that I hope will help.

For a while, I found that the jump button was being very unresponsive, only working about half the time. It took me a while to realize I should fix this, that it wasn’t just my keys being sticky or the Godot engine being slow. After some poking around, I realized that is_on_floor() was only returning true intermittently. I managed to fix this with:

if is_on_floor() or is_on_ceiling():
		motion.y = 10
	else:
		motion.y += GRAVITY * delta

instead of motion.y = 0. I first tried motion.y = 1, but this was not strong enough. Since Yann didn’t seem to have this problem, I’m wondering if it’s because my collision polygons were not quite flat (I did not use the snapping tool).

It might interest you, I tested this problem by making an extra sprite to the Player object and making it visible when is_on_floor() was true. When I used to use blit engines for games, I would do that kind of thing a lot, often having it blit some kind of text onto the screen with more information, and there would be a global debug variable that I could turn on and off to disable all such information as needed.

When getting the paths to scenes, instead of right-click, copy path, you can just drag the item from the File System into the script editor. You can also do this with items from the scene inspector to get their relative path.

For the GUI animations, I tried to make variables for the animation names, like var anim_coin_up = “CoinPulse”, because I thought the code editor would be able to autocomplete variable names instead of needing to remember exactly what the string was called, but the editor did not autocomplete these variables, I assume because it’s wrapped up in so many references. I’d be interested to know if there’s a way to make it autocomplete for a project with a lot more animations.

I was disappointed that the spikeman is just animated. I was hoping to learn how to make enemies that physically exist, and one that could walk to the edge of a platform and turn around by AI. Using the AnimationPlayer was an interesting technique though.

I’d be interested to see a way to make the cloud check if any terrain is in its way before shooting lighting at the player. So for example, in a situation where there’s the cloud, then a platform, then a player, it won’t shoot.

I also would have liked to see a way to make the spring more physically realistic, like it idles on the spring.png, then when bunny lands on it, it goes to spring_in.png for a few frames, and then it goes to spring_out.png and launches bunny. Part of that would be easy by using the AnimationPlayer, but I’m not sure how you’d get bunny to stay on top of it while it’s in spring_in.png phase.

[Stef]

After some poking around, I realized that is_on_floor() was only returning true intermittently. I managed to fix this with

This problem is true in Yann’s case as well. However, you simply do not notice it if the collision surface is flat and the terrain surface is flat. You will notice it when either is not flat, however, e.g. when walking up on slopes. Essentially what is going on is the following. Is_on_floor only triggers if there is a downward force pressing you into the floor. This downward force is only there if there is motion. By setting motion.y to 0, there temporarily is no motion and hence is_on_floor returns false. Consequently, you will fall. Falling applies motion, and is_on_floor is triggered to true again. And the cycle keeps repeating itself.

Setting it to motion.y = 10 works. Personally, I like to set it to GRAVITY * delta. It does the same trick really, but to me feels easier to read. Essentially saying a form of base gravity is always present, a force that keeps you grounded rather than “levitating” on ground level.

When getting the paths to scenes, instead of right-click, copy path, you can just drag the item from the File System into the script editor. You can also do this with items from the scene inspector to get their relative path.

Yann ‘corrects’ himself in this in later episodes. For those reading this earlier on though, it definitely is a very user-friendly option Godot offers.

For the GUI animations, I tried to make variables for the animation names, like var anim_coin_up = “CoinPulse”, because I thought the code editor would be able to autocomplete variable names instead of needing to remember exactly what the string was called, but the editor did not autocomplete these variables, I assume because it’s wrapped up in so many references. I’d be interested to know if there’s a way to make it autocomplete for a project with a lot more animations.

Godot’s auto-complete can be a bit iffy. Generally speaking though, for scene-related autocompletion to work you need to actually have that scene open at the time. This is true for 3.0.6 at least. I am not sure how things will change with 3.1 in that regard soon, I haven’t played around with the beta builds yet.

I was disappointed that the spikeman is just animated. I was hoping to learn how to make enemies that physically exist, and one that could walk to the edge of a platform and turn around by AI. Using the AnimationPlayer was an interesting technique though.

If you would like to do this, it actually isn’t all too complicated in Godot. As always, there are several options you could use. For example, the test_move() function Godot offers on its physics bodies. As well as raycasts. As such, you could use a raycast pointing downwards at a 45-degree angle to simulate visionfor the Spikeman, have it collide with the terrain and if it is no longer colliding the Spikeman will know its on the edge. If on the edge set motion to 0, start a timer. And on timer timout have it flip horizontally (creating some form of pivot node that contains things such as the sprite and the raycast make this easiest), and set its speed again. From there on, just repeat.

Obviously this would create a very, very basic AI (if you could even call it intelligent at all), but it would certainly get you started.

A course on more advanced AI principles, goal-oriented action planning, etcetera however would certainly be more than welcome though.

I’d be interested to see a way to make the cloud check if any terrain is in its way before shooting lighting at the player. So for example, in a situation where there’s the cloud, then a platform, then a player, it won’t shoot.

After finishing the Heist Meisters course, you should be able to figure this one out .