Devlog 01 Getting started beating em up

In this first video, the Dev talks about 4 key parts of making games in Godot, scenes, nodes, scene tree, and signals, all the usual intro stuff. We review how to make nodes, add child nodes, compose scenes, etc. Something new for me was creating a base scene for characters, adding stuff that would be true of most characters, nodes and script code and saving that. When you wanted to use that base class, open that scene, then you create an inherited scene. What problem this solves is that now you don't have to recreate all the nodes and the scripting over again each time you make a new scene based on this scene class. Then you can name the inherited class player or enemy etc and then add the unique qualities that NOT all characters would have, but just that one type of class. I can see this being very useful. Also right away we cover @export var so you can update variables in the inspector and not always need to go into the code to do this. What they didn't mention though was, if you change the var values in the inspector, does that override the code values? Once you fine tune your movements and know what variable values to use, should you then hard code them or keep using the inspector?

Some annoying mistake I made was when using Input.is_action_pressed, I kept using the predicted text of _is_action_just_pressed so instead of moving the player along as expected, it just moved one block at a time. That's because I had only pressed it once. It was a reminder that my students often take the predicted text, but don't look carefully, so it may look like their code is correct, but it's not. Always check, especially in this area.

Another part they didn't cover, yet at least, is that when you make an inherited scene, the nodes turn yellow in the new scene. I'm not sure what that means. I am going to look it up later, but my first reaction was, why is it yellow? Is this like a warning? It's not game breaking, but is Godot trying to tell me something? What should I be careful about? Hover over the yellow node names does not reveal any new info, nor does looking in the console where other yellow warning messages often appear.

At this stage, I have a small background and a player that moves in 8 directions. I like how we normalized so it doesn't move faster on the diagonal, but we didn't use .normalize. I didn't really get why we didn't have to though. It seemed like cleaner more efficient code so I'll float on this one. I did find the explanation for move_and_slide and for why diagonal goes faster if you don't normalize to be very good and clear.

One other new thing for me was to import the texture for a sprite2d node, but that texture was a sprite sheet, and in the inspector, you could set the rows and columns so they stack. I've only imported sprite sheets into the animatedsprite2d node and setting the rows and columns there. Not sure what the benefit of using a sprite2d node rather than animated when you import a sprite sheet, but we'll see. Maybe we will change nodes in the near future as we learn more about other node types.