getting_started/first_3d_game/07.killing_player

[giscus[bot]]

getting_started/first_3d_game/07.killing_player

We can kill enemies by jumping on them, but the player still can't die. Let's fix this. We want to detect being hit by an enemy differently from squashing them. We want the player to die when they'...

https://docs.godotengine.org/en/stable/getting_started/first_3d_game/07.killing_player.html

[Catley94]

Unless I've missed something, in the tutorial player script (using GDScript), the line:
$Pivot.look_at(position + direction, Vector3.UP)
Was originally:
$Pivot.basis = Basis.looking_at(direction)

I'm not sure where this changed in the tutorial? (Though it is possible I did skim over it)

[Arukorstza]

It does the same thing as the original far as I can tell, so I wouldn't worry.

[nbuckley]

Use $Pivot.basis = Basis.looking_at(direction) if you only care about aligning the node's orientation to face a specific direction vector (e.g., Vector3(1, 0, 0) for looking along the X-axis). In our case, that's all we care about, and so we should use this approach because it requires fewer calculations and thus should be more performant.

Use $Pivot.look_at(position + direction, Vector3.UP) if you care about aligning the node's orientation to face a specific point in space, taking into account both the target's position and the current position of the node. This is essential when you want the node to visually "look at" a point, rather than just align to a direction.

Since the position in the second line is the origin (Vector3.ZERO), and the Pivot node is also at the origin, the behavior of the two lines appears the same. However, they are conceptually different.

[v-kydela]

Looks like it was changed back now

[camcam95]

I can't figure out why my collisions are backwards? When I hit a mob from the side I jump and when I jump on top of a mob, I die... Mobs stop spawning just like if i died, so the reactions are indeed backwards...

[camcam95]

Hopefully someone will take something away from all of my pain... Make extra sure the MobDetector cylinder is larger than your collision sphere. Yes this was stated in the tutorial above, I'm the dolt...

[byeuji]

I also had to lower the MobDetector cylinder a lot lower than it showed in the example images on that step -- I set it to basically center on the main round mass of the player model, but still above the floor. This solved the "bouncing when colliding with mobs" issue for me.

[vmorris]

I think you must tweak our 3D shapes and locations a bit and play test it.

[Justin-Archmagus]

It drives me a little crazy that we aren't just adding an "else" statement to the logic we already have when we collide with a mob to destroy it and bounce if we are higher than the mob, otherwise get hit. I know it's to teach us about Area3D, which is useful, but it leads to situations like this if the two hitboxes for the Area3D's and the Player's collision shape don't line up well. It might be better to simplify the demo app and use another opportunity to each about Area3D.

[BourneSuper]

In my case, if I jump on top of a mob, the mob dies. If a mob hits me from the side, I get knocked into a jump, and then the mob dies.
I solved this by making the mob's collision shape slightly higher than the MobDetector's CollisionShape3D.
For example, in my setup, one position is Y = 8.1 and the other is Y = 8.0.
Obviously, the collision iteration code if Vector3.UP.dot(collision.get_normal()) > 0.1: causes _on_mob_detector_body_entered() to not trigger correctly.
So, one sentence in the tutorial can be misleading:
"You can reduce the cylinder's height and move it up to the top of the character. This way, when the player jumps, the shape will be too high up for the enemies to collide with it."
Actually, if you move the cylinder too high, higher than mob's collision shape, the player won’t die when hit from the side.

[xelanipep]

If the Mob spawns while the Player ïs in the air. The mob will be rotated towards the player and have their geo crashing through the floor. To fix this you need to modify the mob's initialize function:

func initialize(start_position, player_position):

	#Ignore the y-axis to keep the mob flat
	var flat_player_position = player_position

    #Set the player's y position to the same as the mob's starting position
	flat_player_position.y = start_position.y 


	#Now look at the player horizontally, but keep the mob flat
	look_at_from_position(start_position, flat_player_position, Vector3.UP)

	
	rotate_y(randf_range(-PI / 4, PI / 4))

	
	var random_speed = randi_range(min_speed, max_speed)
	velocity = Vector3.FORWARD * random_speed
	velocity = velocity.rotated(Vector3.UP, rotation.y)

[vmorris]

You can simply set the player_position.y value to 0, since this is a local value and doesn't change the real player_position... I think!

# Mob initialize, called from Main
func initialize(start_position, player_position):
	player_position.y = 0
	# Position the mob and rotate it towards player
	look_at_from_position(start_position, player_position, Vector3.UP)
	# Rotate Y randomly
	rotate_y(randf_range(-PI / 4, PI / 4))
	# Get a random speed (integer)
	var random_speed = randi_range(min_speed, max_speed)
	# Calculate forward velocity
	velocity = Vector3.FORWARD * random_speed
	# Rotate the velocity vector based on the mob's Y rotation
	velocity = velocity.rotated(Vector3.UP, rotation.y)

[RensTillmann]

I had the same issue, on previous chapter I did try player_position.y = 0 myself just before that look... function and worked fine. So that's probably the way to go whenever you face a similar issue in the future.

[Audhagan]

The player can just run off the screen. Any ideas to fix this?

[Calinou]

See this user note: #35 (comment)

[Menekrr]

If I understand correctly, that is only for the 2D tutorial. get_viewport_rect() in the 3D code results in red highlighting for the line and the error message: Function "get_viewport_rect()" not found in base self.

I'm guessing that in the 3D version of the game, we would need to set up invisible walls in order to stop the player from leaving the viewport.

[nbuckley]

Not sure if it's the best way, but I used the SpawnPath bounds.

In player.gd at the top with the rest of your variables:

@onready var spawn_path: Path3D = get_node("../SpawnPath") # can also just use $"../SpawnPath"
var path_bounds: Vector3

Then in the _ready() function:

	# Calculate path bounds
	var curve: Curve3D = spawn_path.curve
	var aabb = AABB()  # Creates empty bounding box
	
	# Expand box to include all path points
	for i in curve.point_count:
		aabb = aabb.expand(curve.get_point_position(i))

	path_bounds = aabb.size

Lastly, in _physics_process(delta), near the bottom just above move_and_slide():

	position.x = clamp(position.x, -path_bounds.x/2, path_bounds.x/2)
	position.z = clamp(position.z, -path_bounds.z/2, path_bounds.z/2)

Depending on where you placed your SpawnPath, you may want to adjust the bounds slightly, or simply create a new Path3D node that's a bit closer in. 👍

[nbuckley]

There's another way of keeping the player in the bounds and that's having them reappear on the other side if they go out of bounds in any direction. To create this "infinity room", replace the last bit of code I wrote above (the position.x and position.z lines) and put the following in their place:

	# infinity room! if the player exits the bounds,
	# have them reappear on the other side
	if position.x < -path_bounds.x/2:
		position.x = path_bounds.x/2
	elif position.x > path_bounds.x/2:
		position.x = -path_bounds.x/2
	if position.z < -path_bounds.z/2:
		position.z = path_bounds.z/2
	elif position.z > path_bounds.z/2:
		position.z = -path_bounds.z/2

[SomeguyTMG]

Is the "hit" signal really needed in this tutorial (and the 2d tutorial)? can't we just connect the body_entered signal to Main directly?

[SomeguyTMG]

nvm, You cant see the Player children nodes' signals from Main. I was confusing something else with the hit signal when i typed the original comment

[KMouratidis]

Why turn off both Collision -> Layer and Monitorable? If something is not on any layer, does it make any difference if it is monitorable or not?

[Curistofa]

I'd imagine behind the scenes in Godot, checking Monitorable is probably adding the object to some sort of list of things to be Monitored.

So unchecking it is just good practice - even if it has a miniscule performance impact, you always want to make sure you're making Godot do things it doesn't need to be doing.

Once projects get more complicated, doing a bunch of very little things like that can add up to making a difference in performance

[birkb85]

If you hover the mouse over "Monitorable" the description says that when its true other monitoring areas can detect this area.
In this example there are not any other areas, but I guess its a good property to be aware of.

[BrunoProsdocimo]

For me, the player would never die. I don't know if the "OnMobDetectorBodyEntered(Node3D body)" function isn't working properly, but adding an "else { Die(); }" at the end of the for loop checking to see if the player has hit the mob from above fixed the issue.

[freakyfrogboy24531]

for me its the opposite, the player appears for a single frame the moment the game starts and then dissapears along with the enemies who don't even show up

[Menekrr]

Does that still happen if you commented-out the queue_free() in function die()?

[freakyfrogboy24531]

I tried that and only the player spawns, not the enemies

[freakyfrogboy24531]

after I added the signals the player disappears as soon as the game starts

[Ayyybel]

Edit: This was caused by the instantiated Player scene under the Main scene having different collision masking than the base Player scene. Double check that both the original and instantiated child Player scenes have the correct masking.

couldn't figure out what was causing this for me, but changing my collision detector signal function to be the following fixed the issue:

func _on_mob_detector_body_entered(body: Node3D) -> void:
	if body.is_in_group("mob"):
		die()

[Menekrr]

This is very strange.

Playing with my arrow keys, I can move in all 8 directions no problem.
However, I can only jump in the 4 cardinal directions, and FORWARD+RIGHT. In the other 3 diagonal directions, I am unable to jump.

Playing with WASD, I have no such problem. I have tried reassigning the Input Maps so that the WASD keys are added before the directional keys, and vice-versa, but no help.

I'm using a MacBook Pro Retina, Mid-2014:
Godot 4.3 stable
macOS Catalina 10.15.7
CPU: 2.5 GHz Quad-Core Intel Core i7
Memory: 16 GB 1600 MHz DDR3
GPU: NVIDIA GeForce GT 750M 2 GB; Intel Iris Pro 1536 MB

[Calinou]

This is due to keyboard ghosting, which is a hardware issue that Godot can't avoid. You need to use a different keyboard with antighosting (also known as N-key rollover) or switch to a different control scheme.

[freakyfrogboy24531]

is there a way to get rid of the error that happens after the player dies

[freakyfrogboy24531]

basically the program seems to not be able to run because the player is missing once the death hitbox intersects with an enemy

[freakyfrogboy24531]

I'm not sure if this is intended or not so I am confused

[freakyfrogboy24531]

oh, I fixed it

turns out I just forgot to link the hit signal

[freakyfrogboy24531]

guess I should have read the guide more clearly

[Menekrr]

Wow nice work on fixing that sh!t! I did a lot of mis-reading, too. In the 2D tutorial for example, instead of using VisibleOnScreenNotifier2D, I selected VisibleOnScreenEnabler2D. That created a number of weird situations that I was only able to "solve" by talking with folks on Discord, who then pointed out that I had used the wrong node. facepalm

[RensTillmann]

Logically speaking, if you just wanted to detect the collision against the mobs from anywhere other than the top (which you are detecting already) you could just add an else: statement like so (as per my understanding). I tested it and it works. But of course the hitbox isn't perfect because you are using the CollisionShape3D one created earlier for the Player node. But figured I'd share this simple method.

		# If the collider is with a mob
		if collision.get_collider().is_in_group("mob"):
			var mob = collision.get_collider()
			var normal = collision.get_normal()
			# we check that we are hitting it from above.
			if Vector3.UP.dot(normal) > 0.1:
				print("Squash it!")
				# If so, we squash it and bounce.
				mob.squash()
				target_velocity.y = bounce_impulse
				# Prevent further duplicate calls.
				break
			else:
				# Handle collision from front, back, or sides
				print("Hit from the side, front, or back!")
				# Game over logic here...
				break

ps. just wanted to say a quick thank you for whoever worked on these tutorials, they are really helpful for noobs like me, and are a great way to learn about the Godot engine. I hope we will have more of them in the future :)

[birkb85]

I like that they introduce the Area3D in the tutorial, its seems essential to know about when making more complex games, but I think you are right. In this specific game your solution is simpler and would work just as good if not better because it makes the game more forgiving as opposed to using the Area3D node with a wider collision radius.

[jyrque]

For anyone having problems with the MobDetector detecting enemies: make sure the Mob.tscn's CollisionShape3D is tall enough. I spent a moment too long just bugtesting if I had the player signals set up correctly without realizing this. Since the tutorial wants to make note of making the MobDetector thin and positioning it high, this case may be more likely than you'd think.

For reference, the relevant collision sizes I use are

Player/CollisionShape3D: SphereShape Radius 1.0 m
Player/MobDetector/CollisionShape3D: CylinderShape Height 0.3 m, Radius 1.2 m
Mob/CollisionShape3D: BoxShape Size(1.5 m, 1.2 m, 2 m)

[beders]

adding those numbers to the tutorial would be really helpful, as I was also struggling with getting the MobDetector to work properly

[yuexiaohuaz]

Reminder that if the squash isn't working, check if the Mob group exists. Wasted 30 minutes on fixing it :)

[ginocarlo01]

I couldn't make the "if Vector3.UP.dot(collision.get_normal()) < 0" work properly, so I made another Area3D just for squashing the mobs. It is below the other MobDetector and it has a smaller radius

[KnuckleDustes]

I had a problem with my MobDetector, which was not emitting any signals.
Since I didn't see a solution here, I'll add it.
There is a misunderstanding in the guide that says that you need to disable all Masks except for “enemy”. You also need to turn on the “world” mask for it works.

I don't remember exactly, but I think I also had to enable the same for the Mob collision on the previous page of the guide, in order to be able to trigger the signal by jumping on it.
It seems to me that in the current version, the collision is just made under World if there is no corresponding interaction

[marianomontecchi]

Hi, thanks for the tutorial!

Question: my character doesn’t die. Any suggestions?

[Ednaxx]

But did the mobs stop spawning? You could double check if the signals are properly set and functions defined with the correct names. Also make sure to set the MobDetector's Mask correctly.
If you still need help, please provide more context ˆˆ

[marianomontecchi]

Thanks I fix it.

It was the CollitionShape3D, it was set up to high.

[Jacinto73]

Hey guys I'm trying to make a 2d text appear that says "Squash!" whenever player lands on a mob, I know Godot does 3d/2d interchangeably, but I'm losing my mind trying to figure out how to specify that I want the 2d text to appear at a specific position (a little higher than where the even occurred). I know there's get_camera_3d.unproject_position(), but I'm trying to add it to the squash() function b/c that makes the most sense, and the camera is off in the main scene. I've never worked with 3D; how can I do this? I've got it so the text does appear at the right time, but it's always in the center of the screen. I asked at r/Godot and was told "You can’t use a Vector2 (two dimensions) to set the position of a 3D (3 dimensions) node." - which I knew in the first place, which is why I have the Label inside a CanvasLasyer, inside a Node2D that's inside a Node3D. It seems like there would be a fairly simple way to do this. Could someone give me some guidance here? I'd really appreciate it.

[Calinou]

The easiest way is to use a Label3D node as explained in the 3D Labels and texts documentation.

[Coldbattery]

I'm having an issue where my character dies instantly as soon as I run the code and he seems to be dying to himself i.e.

I've looked over how the layers for each physics body is set up in the tutorial and mine are exactly the same. I had been assembling the code piece by piece from the tutorial and even when I copy pasted the full script at the end of this section in case I messed up with the script but same result. If I turn off the mob detector node the game functions but nobody dies. I don't get it.

[Keranod]

I had the same issue, to fix that i removed player Collision from layer 2.
He dies anyway when touching mobs.
To my understanding Mob detector is looking via mask at colliding with Layer 2 and Player itself is on Layer 2 (for me at least), so removing user from it was the fix for me

[MaxxBMD]

I had the same problem as well. For me, the collision settings on MobDetector were messed up. Its' mask was set to the default setting of Layer 1 ("player") rather than the expected Layer 2 ("enemies"). As a result, the Player object was detecting a collision with itself, and dying instantly. Just change MobDetector's mask settings and you should be good to go.

[coding-me-softly]

# player.gd
func _on_mob_detector_body_entered(body: Node3D) -> void:
	die()

func die():
	hit.emit()
	queue_free()

# main.gd
func _on_player_hit():
	$MobTimer.stop()

When the body_entered signal is processed by the Player instance in main, it emits its own hit signal and queues itself for deletion. At the same time, MobTimer is regularly sending a timeout to the Main scene.

How do we know everything here is properly synchronized? I bet it's really unlikely that Player is deleted before the last timeout signal is handled, but is it unsafe? Even if a signal and its resulting handlers were guaranteed to be run before the next signal and its associated handlers, wouldn't it be possible that the timeout signal is already queued for handling even when MobTimer is stopped? Or maybe stopping a timer invalidates all pending timeouts?

Maybe it's not the best place to get into a discussion of concurrent programming, but it would really help to understand what Godot's synchronization model is to avoid nasty bugs in the future.

[felipeourives]

The signal for OnMobDetectorBodyEntered wasn’t being executed, so I took a suggestion from the previous step and instantiated the Area3D like this:

public override void _Ready()
{
	var area = GetNode<Area3D>("MobDetector");
	area.BodyEntered += OnMobDetectorBodyEntered;
}

I don’t understand if the tutorial is outdated or if I’m missing something. I hope this helps someone.