Finally, I grasped the fun factor of VVVVVV!!!!!! Ahahahahaha!!!!!!
Ah! You're here already?! Ahem Hello again, adventurers! It's been quite a long time since the last devlog. (Self-correction: Okay, maybe it was supposed to be last week or two, but hey, never a dull moment!) Previously, I promised you about the paddle and ball mechanics. Turns out, they lured me into a deep pit of experimentations, infuriating bugs, and finally, some elegant solutions!
So, from my observations, the paddles and the ball are the only game objects that moves (or transform manipulates) across the 2D space - both x (horizontal) and y (vertical) vectors. Paddles are player controllable game object where it only can traverse across one axis, while the ball can move freely across both x and y axis that can be controlled its direction indirectly by bouncing against walls and paddles. The rough draft can be like in the image below:
I wish I have a drawing pen...
Sounds easy and can be done quick, doesn't it? Then why did I spend more time on them?
Well, let me tell you what I was doing with paddles and balls back then.
It was easy-peasy to script the paddle movement as it requires to read the input so it can move across an axis in response of set input. Since my paddles were physics objects, I thought it would save my time by adding static walls on both top and bottom edges (see the previous image) to prevent my paddles going out of the screen - also doubles as keep-ing the ball bounce within the screen.
After testing the paddle, I reuse the other one as the opponent paddle, but instead of the same input, I made it to check if it's a 2P paddle, which listens for other set of input.
The moment where I started wasting my time a bit was choosing the visual node for my paddle scene. It was either ColorRect, Sprite2D, or MeshInstance2D, which all of them looks like the same.
The tutorial I followed- er... learned was using MeshInstance2D as the visual node. The other tutorials are either using the other two just to give a solid colored rectangle for it.
One of the reply I received on the short post days ago suggested to use mesh instead. From what I looked around, meshes are the most common visual object in games, and one commenter pointed out they are often more performance-efficient than sprites, especially as a project scales.
Even so, I barely got a grasp on meshes and thing. Perhaps it'll make sense in the future, but for now, I'm taking the advice!
Ah yes, I also play with rotations as well, to see if movement follows along the rotation. I guess a bit of scripting will do. Hmm...
What was I doing back then...?
Oh well, at least my paddles were ready. At that time, I jumped into the ball object.
The ball movement mechanics are a bit different. Instead move across a line, it moves across 2D axis - horizontal and vertical - so instead of just up and down, it can moves left and right and also combination of two. And instead of controlled by player, it moves freely on it's own while bouncing if the ball collides with other objects.
Still experimenting, I put the same scripting from the paddle scene, and modified it a bit. The result? Well, I might just discovered on what magnum opus I should make...!
Haha, kidding. I'll think about it when I finish this pong clone... (No promises though T_T)
Satisfied with the two axis move- I mean, basic movement mechanics across 2D plane, I duplicated the script aside for debugging purposes, and modify the script to move on its own once the game starts. It didn't bounce off the wall at first. According to my note, I should've included the bounce function in the script. Once put in the bounce function (which called reflect in other engines), it worked, but then it hit me...
It hit me so far that when I playtest the bounciness of the ball, my brain suddenly went to DVD screensaver thingy. Not to mention that I wrote a line of code that incrementally increase the speed upon bouncing. I knew that my experiment brought my rig a step closer to break it. At least this is 2025 where game programming nowadays is so robust, it has a less chance to break from my harmless shenanigans like that :)
Anyway, I tried to collide the ball against the paddle before concluding my development session... until I stumbled into a case that I least wished onto me...
...bugs...
Okay, I'll stop exaggerating. It's just a bug (not literal). Not many (as in not yet), but we should move on before I digress too much.
From the picture before, or my post if you never seen it on X and Bluesky (shameless plug, I know), you can see that the paddle 'slides' forward whenever it's in the clutch reaching for the ball. That shouldn't be possible in pong clone. (at least in few cases I can think of, but not on basics)
After posting that post, peeps suggested me using move_and_collide() instead of move_and_slide() (a built-in function to allow physics object to move and collide/slide upon collision with other physics object). So I read more on move_and_collide and swapped with it into my code.
And also I did physics jank because I was bored (and also busy at that moment). It almost slipped me into other rabbit hole, so I stopped playing with it.
While doing that, folks came to my post and told me that pong doesn't use full built-in physics, but tight custom 'physics' consisting of just bounce and collision detection. After a bit of thought, I could see why.
While the physics engine can simplify the process, physics engine tends to do lots of calculations to simulate real application physics, such as drag, momentum, kinetic force, and so on. Something that is way too overkill for a Pong clone.
And because of the physics that is not needed in this scenario, it causes things that is not supposed to happen. Speaking of, there's a case where the paddle got punched by the ball out of the screen, but that's rare and I missed to capture it in action. My bad 😥
To sum it up, it's not the fault of physics engine - it merely do its job. It's about whether the pong bouncing mechanics should be handled by custom physics or full-fledged physics engine.
Wait, I forgot to put the speed increment only once the ball bounces against the paddle. Hang on a minute.
Anyway, The bug happened when two physics body collides with each other, so I decided to convert the paddles into non physics object and write few lines of code to make the ball bounce.
It worked like a charm—no more slipping paddles. But woe was upon me, another bug just created. This one is a bug where the ball was almost pass through the paddle.
Well, even though it's just a bug that can be ignored until pre-release phase, it just bothered me to look at. Besides, it really pass through the paddle at higher speed. So, I went back to brainstorming.
From what I thought, the non-physics approach did not simulate physics as tight as the physics engine way. It tries to 'make' it bounce after checking for position instead of calculating the velocity and collision beforehand, making it looks 'fake' and, of course, giving an illusion of passing through.
So my solution is to put static body as a safeguard for a ball to not pass through the paddle. And it works like a charm! No more passing through at high speed.
Satisfied with the fixes, I had an idea to make the paddles a bit rewarding for putting skill into it. Let's say able to change the ball's direction depends on how far the ball bounces on the side of the paddle.
Looking at my note once more, I write additional script in the bounce function as best as I can understand, and...
It looks just as I wanted! Job well done!
Finally, I finished this part by scripting the ball to move slowly towards set direction as serve to the player's paddle, which signals the round start once the ball bounces from it. And also respawn the ball once it went out the screen. That marked a start for the next dev session later on.
Oh, yeah. I actually asked for opinion once regarding to top and bottom border on the screen, whether I should leave the chunky lines of border, or make it invisible to make the playfield a bit larger.
Turns out, some suggested the latter.
After considerations, I also prefer the open playfield too. It's not much, but it's nice to have an active community passing by sometimes.
In next devlog, we will discuss more on the scoring system, the game loop, as well as UI scoring basics. It's a matter of time to settle... the score!
Perhaps this will be my costume this Halloween. No pun intended tho.
Anyway, thank you for reading this devlog! I know this one is very overdue, but sometimes real life (and faulty power plants!) throws a wrench in the gears.
While waiting warmly for the next devlog drops, you can follow me on X/Twitter and BlueSky for daily short dev snippets and (a bit) exclusive harmless shenanigans. And as always, leave a comment down below! Every critique and suggestion is highly appreciated!
Ah, the power is about to going off soon, so... Happy Halloween, adventurers! And see you in the next devlog—
(SESSION TERMINATED: CONNECTION LOST(ERRNO:OOO))
Devlog #2 - The Vectors’ Vague Voyage via Various Velocity-Driven Variables
Coming Soon!
