It has definitely been a while since my last entry. And I’m rethinking just how to approach this. Trying to write a large post every night will just burn me out. I’ll go over it more later, but for now, I’ve made some progress that I would like to share. This entry is a bit more technical than usual. So, the last time I posted, I was facing a serious dilemma that was taking more time from me than it probably should have. But this issue is something that seems paramount to get right, for it seems like a common problem I’m going to encounter in my game dev journey. 

That problem being having information in one scene being available to other scenes - and a quick side note: If I say “scene”, unless specified to be otherwise, I’m referring to an object-like structure, that has multiple components (or in Godot’s case, Nodes) to it, not a level or a collection of the said objects. As far as I'm aware, the Godot community doesn’t make a distinction between them, which kind of bothers me to be honest. 

 want to have areas of the paddles that change the direction of the ball when hit. To do that, I had to share information between the paddle and the ball, the ball’s current direction for example. The first way I approached it is by using “get node”, which sort of maneuvers through the game files’ directory to get a scene. But, I soon read that it's really bad practice to do that, and for good reason. It makes it harder to organize or change your project. As soon as you move a file that contains the get node functionality, it breaks the game and you have to reconfigure it to work with the new location. 

A better way to do this is through Singletons, which is a node that is on the same level as a root node and can be accessed from anywhere in the project. In a previous entry, I thought it was only scene-wide, but further testing showed me that it is the entire project. It took me a bit, but I figured out a good way to make it work through functions. 

And fun fact, I found more helpful info from the Godot documentation, not from scrolling through stack overflow and Reddit for the answer. Here’s the philosophy I’m looking to adopt. I want to try to understand the tools that are offered, how they are constructed, and the methods/functions they come with. Then, I want to look at the documentation to try to piece together the solutions directly. At first, it seems easier to just search for a solution only, but your game can quickly have very specific problems that haven't been answered online. From now on, I’ll try to figure things out using the documentation only for at least 15 minutes before visiting forums.

I’m learning that research is by far the most important skill to have in my opinion. As an indie developer, the ability to gather, understand, organize, and utilize knowledge is paramount, being more important than coding and drawing. Instead of doing coding exercises, perhaps I should look more into how to understand or experiment with what’s available in the manuals. For whatever reason, I have the urge to skim through them and I’m trying to break that habit. That barely worked in college, but today, I’m trying to learn about something I legit have a passion for. 

Another topic I had some trouble with is collision layers. Reading a bit about them and not taking the time to understand, I struggled with it for hours. This problem was encountered when I wanted the collision between the ball and the paddle on and off. I thought this could be achieved easily through managing the collision layers and masks, which determine what scene can collide with what other scene. However, there were some problems. 

Backing up a bit, the way I originally had the ball bounce off the paddle and walls, was NOT through the built-in collision detectors, but instead area 2D detectors. So when I turned off the layers, I was a bit surprised to see that the ball was still bouncing between everything. I finally got the expected result after switching off the layers of all the children nodes as well. 

Awesome! If that’s the case, I saw no reason to have layers activated in the children's nodes. It seems a bit redundant. So, I left the children nodes without any layers activated and only have the root node of each scene layered. I ran the game again … and the ball still goes through. I activate the layers in the children nodes and leave the parent one blank. The ball bounces, but now the paddles can go through the walls and each other. What the heck is happening? After some time bashing my head against this problem and experimenting with different layer/masking combinations, I finally asked, “Do Area 2d collision layers and rigid body collision 2d layers act the same way”. The answer is no. 

Here’s what happened. 

By default, the Area 2D node collision DOES NOT stop movement between two moving objects. I should have guessed from the name, but the “collision” in this case is just something that signals if something has gone into the area 2D. The collision of the Rigid/Static bodies DOES have the behavior that prevents two rigid bodies from going through each other. In my project, the root node of the paddle and ball scene is a CharacterBody 2D, which is somewhat similar to the rigid body. The child nodes are all Area 2D. This explains why the ball bounces between the paddle and walls even when the parent node has no active layers, as it has functionality that reverses its direction through area detection. And it is why the paddles and walls ignore their collision even though the child layers DID have collision, because area 2d collision does not act as a physical blockage. This simple revelation took me an embarrassingly long time to figure out, but I feel as though the experience gave me a good bit of wisdom. 

I eventually managed to get a better understanding of layers vs masks. On YouTube, I’ve watched this helpful short video by Branno that gave me a good explanation, “Layers determine what can detect me. Masks are what I detect” (I/Me being the object that is being configured). Again, it’s a good explanation, but forever reason, I still have a difficult time keeping those dots connected. An explanation I came up with that works better for me is this: “An object's layer is what another object’s mask detects”. That might make more sense to you, it might not. Remember it if so, discard it if not. 

I’ve been cleaning the organization of my files a bit, renaming some files and functions, and making some code and scenes more efficient. I also got the vertical movement working for the pong bot’s paddle. The camera is also set up to follow it too. When within a certain distance, the enemy paddle will enter an “active” state, in which it will spawn and then shoot out the ball, initiating the pong match. It’s pretty good progress so far. I just have made it so that when you are in vertical movement, you cannot reflect the ball. 

There has been a big absence of these entries and to be honest, it’s because I just get too sleepy by the time I’m done with my session of game dev. I’ll say this. If you have trouble going to bed at a good time, do some game dev. This activity puts me to sleep better than many methods I tried. I sleep like a log after just an hour of this pursuit. Trying to write a blog after that is honestly really difficult, which is why I’m taking a different approach. 

For one, I’m releasing these on Monday, Wednesday, and Friday nights. I’m also going to try to do these before I begin working. On the downside, the experiences I have from that session won’t be as fresh on my mind if I let one to two days go by before writing it, but recalling them effectively is what my notes are for.