Learning Questions

[generrosity]

OS/device including version:
Win10 Godot 3.4.4 64bit, GeForce GTX 1060 (nvidia 30.0.14.9729)

Issue description:
Questions from running the demo, and looking at the code, and appologies in advance if I have been dense overlooking things;

• Is there possible z-fighting in some of the models? The one I notice most is various lights around the walkway but not in the core entrance (level > structure.tscn > structure.glb > hall_circ1125_column for example)

• The first time that the player fires, I find that there is a momentary halt of the game before the bullet fires, and subsequent firings are fine. I can't detect this using the Profiler (it doesn't register the pause) - is it just my machine or would there be a bullet preload that happens earlier perhaps or some other expensive operation?

• Is there a defined end of the simulation? I can't find any triggers in the core area (in game or briefly in code)

• Is it intentional for players to get stuck in thge core lowest level?

• When the player lands, there is a reset back to a neutral stance. When moving and jumping, I think this results in a standstill after jumping - just wondering if somehow the character is still considered on_air and unable to move until the reset of legs occurs rather than blending. If I understand it right

• When opening the Player scene, there are many errors like this -
  scene/animation/animation_blend_space_2d.cpp:110 - Index p_point = 58 is out of bounds (blend_points_used = 4).

Thanks for your time again - Ive been looking at the demo with fresh eyes, and hoping it inspires others too :)

Screenshots of issue:
Possible z fighting?

[Calinou]

Is there possible z-fighting in some of the models? The one I notice most is various lights around the walkway but not in the core entrance (level > structure.tscn > structure.glb > hall_circ1125_column for example

Probably, I guess nobody bothered to fix it until now (I didn't notice it before you mentioned it).

The first time that the player fires, I find that there is a momentary halt of the game before the bullet fires, and subsequent firings are fine. I can't detect this using the Profiler (it doesn't register the pause) - is it just my machine or would there be a bullet preload that happens earlier perhaps or some other expensive operation?

This is a shader compilation stutter. Shader caching can get rid of it in subsequent runs, and ubershaders can attenuate this on the first run. Both of those features will be available in 3.5, but they're not in 3.4.

Is there a defined end of the simulation? I can't find any triggers in the core area (in game or briefly in code)

No, it's purely a "sandbox" level. You can't actually be injured either.

Is it intentional for players to get stuck in thge core lowest level?

No, I guess this wasn't taken into account when the level was originally designed. We could perhaps add a teleporter or two within the bottom ring to go back to the core entrance.

[aaronfranke]

• Is it intentional for players to get stuck in thge core lowest level?

I'm aware of it, but there's not really much of a point to improving this. By the time you get there, you've already seen the whole level, and if you want to go back to the start of the level you can just restart the game.

[generrosity]

It depends on the demo's purpose - is it fit for newbie consuption? It feels 'intentional' due to the barriers to moving outward.

Could I suggest - add the same barrier to the inside? (core.tscm - radial_player_only?)

Once the four enemies are dead, you could show a discrete 2d 'Press ESC to return to menu'. There is no indication you've seen the whole level or that 'esc' resets the level meaning someone might keep looking and failing. That would tie the end of the simulation off.

outside barrier

Is it intentional for players to get stuck in thge core lowest level?

I made a few changes to avoid get stuck in the lowest level, and to go where no robot has gone before.

# Set it to 15
const JUMP_SPEED = 5

# Remove the "not on_air" condition, so you can jump repeatedly when on air.
if not on_air and Input.is_action_just_pressed("jump"):

# Optional: if you want to run faster, multiply orientation.origin by, say, 3.
var h_velocity = orientation.origin / delta

You can even board on the flying ship. At high speed it is difficult, maybe only make the second change for that.

Edit: it should be obvious, but I forgot to mention that those changes have to be done in player.gd.
In the end, I set JUMP_SPEED to 10 and multiplied orientation.origin by 2.

[Calinou]

I wouldn't allow jumping repeatedly when in air, but adding double jumping could be nice (along with some air control).

Movement speed can also be increased slightly, but be sure to slightly decrease acceleration and friction if you do so (so the player doesn't accelerate too fast).

[aaronfranke]

I'm not sure that double jumping would fit well with the demo's aesthetic.

Maybe we could add rocket boots available by holding jump? It would probably have to be limited to about 1 second to avoid allowing accessing out of bounds areas. Note that this would require VFX work which I'm not capable of.

[Calinou]

Maybe we could add rocket boots available by holding jump? It would probably have to be limited to about 1 second to avoid allowing accessing out of bounds areas. Note that this would require VFX work which I'm not capable of.

That could work too 🙂

It's essentially variable-length jump when you think about it.

[aidan-j-rhoden]

Instead of opening another issue, I'll just ask my question here: Are the doors supposed to open? As I look through the code, it seems that they are supposed to open when the player enters it's collision shape, but they do nothing. Or maybe I'm just missing something. 😀

[aaronfranke]

@aidan-j-rhoden The animation was made, but never used.

[aidan-j-rhoden]

Aha! Thanks for your quick answer. So you would need to go through level.tscn and add a door where each one was pictured, or something similar.

I wouldn't allow jumping repeatedly when in air, but adding double jumping could be nice (along with some air control).

Movement speed can also be increased slightly, but be sure to slightly decrease acceleration and friction if you do so (so the player doesn't accelerate too fast).

I agree, I did the changes just to explore.
In the end, I set JUMP_SPEED to 10 and multiplied orientation.origin by 2.

The first time I ran this game, I quickly forgot it was a demo, and I was trying to accomplish "something".
I tried to figure out how to open the doors, how to climb the stairs of the reactor pillars, and how to escape when I got stuck in the lowest level.
So, I made the above changes to feel happy. LOL
Jumping repeatedly is my way of flying.

I wouldn't do that for a no-demo game.