Tag Archives: godot

pongodot day 4: paddles

SJR paddlin - Pong? That's a paddlin'
memes anyone?

That’s right, today it’s time to add paddles to pong. finally time to make this somewhat like a game with a player controlled element.

First step is input. Godot uses an input map through the player settings, allowing multiple inputs to translate to specific actions. For this I added three, padde_up, paddle_down, and an action I called launch, which will be used to launch the ball after a point is scored. This last one will not be used today, since the scoring mechanism is tomorrow’s task.

all the ui ones are there by default, and I didn’t bother removing them.

The input actions we’ll be able to use in code to move the paddle. Speaking of which, it was also time to make the paddles.

The paddles have a similar node structure to the ball, they are KinematicBody2D nodes, with a sprite and a collision shape attached. Putting them both in the scene with no scripting attached made the ball simply bounce off them, which is exactly what we wanted.

Looks a bit more like pong now, eh?

First up, the player paddle. The script here was relatively simple, getting the input is the only thing new about this script compared to what we wrote for the ball, and unlike the ball we are using move_and_slide instead of move_and_collide, since I don’t want the paddle to stop moving when you hit the ball.

Next, we’ll do the COM paddle. Later on I want to play around with an algorithm that will be fun to play against, but for now I’m going to make it super dumb.

The plan is to have the COM paddle simply follow the y coordinate of the ball, however, it’s going to have a slightly lower speed than the ball, so it lags behind a bit, hopefully allowing the player to score sometimes. When we get to the scoring stuff tomorrow I might change this up, but for today’s task it’s all about keeping it simple and stupid.

KISS

So here, we use get_node() to get a reference to our Ball object, and just simply move the paddle up and down to follow the ball. We can adjust the speed to make the paddle more likely to miss, but for now this works great.

That almost looks like a game!

In this gif I am controlling the left paddle with the up and down arrows! As you can see, nothing happens when I miss and the ball goes behind me, but that is tomorrows task. See you then!

-Ike

pongodot day 3: bounce bounce

Time for physics, which means that everything will go smoothly and I won’t have any issues whatsoever. First things first, I need to add collisions to my walls, so I changed the structure a little bit, using what I learned about balls.

Ideally the walls shouldn’t move, so we’ll go with this for now.

To my field object I added four StaticBody2D nodes that would become my new walls. The existing sprite objects become children of that and I just need to also add to each wall a CollisionShape2D that is the same size as the sprite. Quick enough.

I’m feeling a bit blue.

Now, I haven’t done anything in code to actually use the collision, so I’m not expecting much, but just for fun let’s go ahead and run the game and see what happens.

huh…

I’ll be honest, when I pressed run I wasn’t expecting this. I kind of just figured that the ball would pass through the wall like before. Then, I remembered something. In the code I wrote yesterday I move the ball using move_and_slide(), which would explain why it’s sliding along the floor when we are trying to apply that velocity.

Another similar method exists, move_and_collide, so I tried that. When I used move_and_collide() the ball instantly snaps to the wall and stops moving… That’s weird.

A bit of googling later revealed an… interesting design choice. While move_and_slide() automatically calculated velocity using the delta, move_and_collide() does not. I can’t say I agree with that design decision, but that’s how the scripting works, so instead I’ll multiply my velocity by the delta.

I need to find a way to make the code blocks in WordPress look good so I stop using screengrabs.

So, with that now added, let’s go ahead and run this again.

Stop! In the name of love!

Ok, so it does sort of jitter and continue to move along the bottom, but that’s ok. One of the nice things about using move_and_collide is that it returns a collision object when a collision occurs. I can use that to detect when the ball hits the wall, and then use the information about the collision in question to have the ball bounce off. Here is what that looks like.

final ball script for tonight

Three main changes here. First is I moved the velocity definition to the _init() function, this way I just set the starting movement of the ball. Second, velocity is not directly modified by the speed and delta, instead I added a local variable to hold that calculation. Lastly, I check the collider that comes back from move_and_collide, and if it’s not null I simply use the normal of the collision to modify the velocity. Adding twice the normal to the velocity seemed to do the trick. Now, when I run it (with an increased speed so we can get on with it faster), it looks like this.

It’s still not quite a game, more like a screensaver right now.

And that’s a success! The ball bounces off walls now, so that’s progress. Tomorrow the plan is to add paddles that will be player controlled. Until then!

-Ike

pongodot day 2: i am ball

Today’s goal was to add in a ball and get it to start moving. Pretty simple, and wanted to get a basic understanding of the scripting system in Godot.

Once again, using gimp I made a ball, keeping it simple it’s just a white 64×64 pixel square. Importing that into Godot and slapping it into the tree was quick enough.

Truly the most riveting of games

But just dragging things and assembling them on a screen was yesterday’s task, so today let’s get it to move.

Godot does support C#, which is the language that I am most familiar with, having used it most in both my professional career as well as in past game projects. However, the goal of this project is to learn, so instead, let’s instead use the built-in scripting language, GDScript.

GDScript also makes sense to use since it is better integrated into Godot, designed to work natively. It’s syntax is very reminiscent of Python, which I have used in the past, and there is a lot about Python that I like, just haven’t had as much opportunity to use it in years.

Quick right click on the ball in the scene, click Add Script and we are off to the races.

The little scroll icon means I clicked the right thing.

More complex scripting will come later, but for now we are in extremely basic mode. For tonight’s brief session, the goal is to just get the ball to move diagonally on the screen. Everything else can wait for tomorrow.

See if you can spot the error.

Take one had a small issue. I made my ball out of a sprite, and it turns out this was probably not the best approach. As a sprite I don’t have access to move_and_slide, so, I need to make a few adjustments.

More nodes.

This is another area where I need to adjust my thought process. In unity all these properties would just be part of the same object, but in Godot I need to nest them in the tree structure. Again, under the hood it doesn’t work all that differently, it’s just a matter of shifting my perspective of how things are laid out.

With that I just needed to change the script I wrote so it extends KinematicBody2D instead of Sprite, and boom! I could now use move_and_slide to move the little cube across the screen.

I tried using code blocks in WordPress, but they don’t capture the highlighting the right way for GDScript.

A lot can be done to clean this up, but for now I hit play and presto! It works! Rarely do things just work smoothly on the second try, so I’m feeling pretty good about this.

woo!

Of course, it doesn’t obey the walls, but that is to be expected (as I didn’t code anything to make it obey the walls). That’s tomorrow’s problem. For now, I’m going to finish sipping on this improved whiskey cocktail and relish in another step closer.

Sipping on this while I coded was probably not helping, tbh.

-Ike

learning godot with #pongodot

So, I’ve been taking a break from game dev, which, to be honest, has been nice and somewhat refreshing. Most of that time the last six months or so have been spent working on my webcomic, which has been really cool, and I’m excited for the future of A Star Below.

The last time I really did anything major in game development was last year, for Ludum Dare 48. Along with some good friends of mine, we made a game in 72 hours… and then futzed around with it for a few weeks polishing it further. That game was Crashdown, which you can play now if you like!

Since then, haven’t done much in games. The aforementioned comic has occupied a lot of my free time and creative energy, but right now, with the comic on hiatus and my role on the script pretty far ahead it seems like a good time to jump back into game dev! And just in time for Ludum Dare 50!

For a variety of reasons I won’t get into right now, I am wanting to try out something other than Unity for this one. I have tinkered with Godot in the past, and while there were things I liked about it I did sort of bounce off it at the time. However, I thought this would be a good time to take another crack at it.

So, Ludum Dare 50 starts on April 1st, so I have a month to play around and learn Godot. So, that’s my plan, I’m going to spend the month of march learning Godot by making a Pong clone. I have named this endeavor: Pongodot.

My goal is to do 1 thing each day. I figure at that pace by day 5 I will have a basic working pong game, and then I will spend the next 26 days futzing around adding a bunch more features and bells and whistles as I see fit.

Day 1

So, for day 1, let’s talk about basic scenes in Godot!

For this project I am keeping things simple, and building my scene in 2d. I’ve got godot installed, added a new scene with it’s root node.

oooh, aaah

My background so far in game dev has been almost exclusively in Unity and C#. I (very briefly) played around in Unreal 3 one semester in college, and I tried out a Python library for games, though that second one wasn’t really an engine. Point is, my basis for comparison is entirely from Unity, and I will be using it to understand.

Two things setting up this scene that struck me. First, is that the scene itself is the root node. Godot structures everything as nodes in a tree, and if you think about the Unity scene as a hidden root node, this is really not a big paradigm shift, easy enough.

The second is that I don’t need to add a camera. In Unity, even when working within its 2D tools you need a camera, otherwise how do you show anything? Here it seems the camera is implicit, and the scene even draws out for you the view of it so you can set up your scene with that in mind.

There are 2D camera objects, but from what I can tell those are used for when you need the camera to MOVE and you don’t want to move the whole scene. For pong our perspective doesn’t need to change, so we can ignore that.

Next I just need to draw in the walls. For this I created a few simple png images in gimp, and imported them into godot. There was some fenagling, that I’m sure I could have handled better, and some weirdness getting everything sized, but oh well. With some effort we have a pong field.

I know, it’s impressive.

And that will conclude today’s foray into Godot. Just familiarizing myself a bit with the editor and scene layout, but hopefully I’ll be able to make more progress tomorrow when I actually add a ball and start learning a bit of scripting.

So far my thoughts: being used to Unity this is going to take some getting used to. The Unity editor has a lot more QoL improvements over where Godot is at right now, but I’m sure with more experience in the engine I’ll get more adept at it. Just this little bit of basic setup likely took me longer than it should have, but honestly that also might be PEBKAC, so ¯\_(ツ)_/¯

-Ike