Player update

[victorbstan]

Why?

Player code needs improvement

What?

• Camera was in awkward position
• WIP Swimming code (note: liquid types implemented in another PR)

[gongpha]

Can you elaborate on "Camera was in awkward position" ?
Your change seems to make the player looks shorter than the original.

Comparisons (can be observed at the position of the nails on the wall) :

The original (vkQuake)

vkQuake.2023-06-26.19-20-29-666.mp4

Your changes

Godot_v4.0.3-stable_win64.2023-06-26.19-15-00-255.mp4

Before the changes

Godot_v4.0.3-stable_win64.2023-06-26.19-16-15-997.mp4

And the swimming code you've noted as WIP looks OK. But it didn't work as expected yet.

Godot_v4.0.3-stable_win64.2023-06-26.19-27-02-237.mp4

[victorbstan]

• Reset the camera height on "around" node.

• Updated Step and Ceiling checks to have the step checking collider align with bottom of player and top of player + step height. This fixes an issue with not detecting very small offsets on ground surface as in the following screenshots

• Fixed underwater movement to detect steps when in liquid
• Added mechanism to play a variety of player sounds for each liquid type

[victorbstan]

• Added ability to detect player underwater submersion level: bellow mid-level = 1, above mid-level = 2, above eye-level = 3
• Drowning / damage in liquid multiplied by submersion level
• Coming up for air (gasping) sound added

Screen.Recording.2023-06-28.at.8.54.57.PM.mp4

[victorbstan]

2.08165e-12 shows up as 0 in editor, maybe this is a godot bug, or floating point rounding?

[gongpha]

Likely the latter. imo, that number seems very precise enough to me.

[victorbstan]

I tried updating by typing 0 in the editor but it doesn't want to actually set it to 0 just keeps the odd number...

[gongpha]

Confirmed that this is an unusual behavior. But occurred on the Y field instead

[gongpha]

Haven't you added water sounds, right ?

and it'll be better if you'd fix the collision box when a player is trying to swim up to a water surface. I would appreciate it ^^

Godot_v4.0.3-stable_win64.2023-07-01.01-44-06-268.mp4

[victorbstan]

No water enter sounds ("splashing") yet, but that would be easy to add.

The player is currently able to bounce on top of the water, by jumping or swimming up, which is not ideal, but no worse than before.

I think as an improvement, perhaps the player should not be able to swim/jump up more than half the bbox height out of water. But that would also mean that there needs to be updates to how "getting out of water" works when near a step or solid object -- perhaps by increasing the valid step height while in liquid to include the total height of the player?

[gongpha]

After my investigation. Let's say there are 2 crucial height points to check :

• Point A :
  • Approximately half of the player's bbox
  • Check if the player's upper half body is inside the water.
• Point B :
  • Roughly at the player's feet
  • Check if the player's feet are inside the water

Both points can be a very short box or something similar and must touch the water to be considered as they're moving in water.

See how :

vkQuake.2023-07-01.04-16-44-537.mp4

In the clip, You can see the player would fall out immediately when their feet are out of the water.

---

Why needed Point B ? Point A alone will do stuff anyways.

Check out E4M2.

vkQuake.2023-07-01.04-16-10-339.mp4

The pool in E4M2 has a very thin water volume. The player couldn't even move in the water volume, despite Point A colliding with it. This is because their feet are already out of the water, making Point B doesn't collide.

Or even if Point B collides with water (their feet are inside the water) if Point A (their upper half body) doesn't collide with the water. It wouldn't be considered that they're moving in the water.

And sure, our implementation could do. which it shouldn't.

Godot_v4.0.3-stable_win64.2023-07-01.04-22-04-288.mp4

This is my pure assumption. But should work in this situation :)

[gongpha]

Also, I found a good source about the Quake metrics
https://book.leveldesignbook.com/process/blockout/metrics/quake

So, I will write it some of them here. And include Godot units too.

Metric	Quake unit	Godot unit (1/32)
Collision hull size	32 x 32 x 56	1 x 1 x 1.75 (current is 1.5)
camera height above floor	46	1.4375
Maximum run speed	320u/sec	10u/s
Fall damage height (for handling fall damage sound)	256+	8+
Underwater height (above floor)	29+	0.90625+

[victorbstan]

We can use func _get_submerged_level() to check 3 levels, bellow mid-point (bbox entered fluid volume) is 1, mid-point (half point of character bbox) is 2, and eye level (camera/around) is 3.

[victorbstan]

There's also something we can decide to do, is ask if we want to implement "all the features", or work in a more incremental way, where we can have more peace-meal player improvements across many PR's. I don't know if we will successfully implement all the player features at once.

Also I will be away this weekend, so won't touch this until later Monday or Tuesday.

[victorbstan]

To make it more like in the original behaviour func _get_submerged_level() can be modified to add another point collision check at the foot level which would represent A and return 1...

[victorbstan]

Swimming should feel more like traditional game now (maybe not exactly, but closer) (should address: #9 (comment))
Also getting out of water is easier now, as there's a separate "stairstep_liquid" which applies while in liquids, that is much higher than normal stairstep.

[gongpha]

Looks better !
Also, I suggest you change the gravity as well. It seems a bit low. Compared with the original which falls faster.

it's around 800 or 25 in Godot unit.

[hemebond]

Is there an issue with ramps in this PR? I'm testing it on e1m1 and this 45 degree ramp can not be walked up: