Fun fact:
My last post got a lot of love, yet I was a big chimp-brain and fucked up the title, originally calling it Ludum Dare 49 - Day 1, rather than Ludum Dare 48 - Day 1, so... I'll have to get creative with next event's blog title...Anyways, on with today's update!
Yesterday I ended with something close to this:
Neat, but it was time to do better.
First, for play-testing purposes, I decreased the darkness of the overall map, just so I could see where the tiles were while testing out the physics stuff.
Then, I played around with how I wanted the player to interact with the pearl. Remember, this is a golfing game, so it should be exactly like golfing in real life.
Perfect.
Except, not really. I wasn't happy that every bump you made against the pearl would move it. I wanted to allow the players to get up close, or even run straight over it. To accomplish this, you gotta get familiar with Godot's collision layers.
When you have 2 or more physics bodies, they will collide - if they are on the same layers.
What are layers? Well, Godot offers 2 types of them for collisions. Each set has 32 layers, and objects can be on multiple layers.
Layer are the layers where this object object resides / sits on in the physics world.
Mask are the layers which this object will "scan" for other objects.
It can be kinda confusing to understand how these tango with each other, so let me lay out some examples:
As you can see, a body only has to be on the same layer in either the Layer group or the Mask group.
So, let me show you the layers my two physics bodies have:
KinematicBody2D Layers | RigidBody2D Layers |
|---|---|
As you can see, these two objects will no longer collide with each other.
No more running into it. Instead, let's dabble into Godot's AnimationPlayer node.
Woah... Lots of sick shit in there...
And I'm not gonna explain any of it AHHAHAHAHHAHAHAHHA
Ok, I will at some point, but I honestly think that Godot's animation utility is so fucking awesome, it deserves it's own post. I'm not even a certified wizard with it yet, so I'll wait before talking about it.
What I will talk about, is this little green thing:
Ya see, Godot has these things called Call Method Tracks that you can pipe into your animation, which will call a custom method (or function) in a chosen script whenever that frame gets played in the animation.
What this enables is making a little spinning animation for the player, but only calling code to actually hit the pearl at a specific keyframe. So the pearl doesn't move on the charge up part of the animation, only when it looks like the player has actually made contact with the pearl.
Pretty fucking rad, I know. These method call tracks are crazy powerful along with the rest of the animation editor.
In terms of actually moving the pearl, the hit_pearl() method I wrote basically just has the player-script call another method in the pearl-script, which does the following:
apply_central_impulse(Vector2(5000, 0))
This, as the wording suggests, applies an impulse (which is a short lived force) to the pearl.
With that, behold:
A wall-breaking pearl.
Whoops 🙈
I forgot, since the pearl is on new collision layers, that also means it won't collide with the tilemap anymore.
Simple fix. Just head to the Tilemap node and update it's collision layers as well:
It needs to stay on layer 1 for the player, and like I said an object can exist on multiple layers. You can actually just set one of these to be on both layers, but I decided to do both for... uh...
aesthetics ✨
Yay! You can hit pearls now!
And I'm sure it works perfectly and nothing is wrong with it at all.
Yeah, so, of course, that ain't right.
Remember the impulse code where we put Vector(5000, 0)? So this will only push the pearl to the right.
Good question, I had the same one! It's almost like you're in my head!
My first solution was to do:
var angle = player.rotation
apply_central_impulse(Vector2(cos(angle), sin(angle)) * 5000)
Which gives us:
Looking good, yeah?
WRONG, NERD.
This shit is broken:
The issue with that solution is that it relies on the player's angle. That works fine if the player is facing the pearl when they go to hit it. But as we can see in the above gif, it doesn't work if the player happens to be facing away from the pearl.
Maybe you want that in your game? Yeah? Maybe you fucking smell to, how about that?
For this game, I think it works better to shoot the pearl in the opposite direction of the player. So, stand to the left of it, it goes right. Below it, pearl goes up. Regardless where you face.
I just personally think it makes more sense and feels better gameplay wise.
With this better code:
apply_central_impulse(Vector2(-(player.position - position)).normalized() * 5000)
Yeah homie, 2 lines down to 1. How often do you fix bugs by reducing code huh? Pretty based.
-(player.position - position) gives us the correct direction, .normalized() does magical Vector stuff, and * 5000 is an arbitrary number I chose for the speed of the pearl to move at.
Mix it all together, add 2 pinches of salt, and you've got this:
I know these last few gifs might've all looked similar, but trust me if you play the game, you'll notice.
Speaking of...
Well, if me and my teammate manage to get it to where we like it in time for Ludum Dare, then soon!
But...
I doubt that'll happen 😅 As I said last time, this is about learning not releasing.
However! Both Rollin & I love this concept, and I'm confident it'll see the light of day sometime in the future 😉
Anyways, that's all for today's exciting episode of:
Learning Godot At Breakneck Snail's Pace
Thanks again for all the love on my last post, that was real kind & a great surprise.
I really just hope these posts are either informative, interesting, or at the very least entertaining.
Take care, see you all soon!
- Chimp CEO 🐒
Ludum Dare Post Series Links