Skip to content

Conversation

@manuq
Copy link
Collaborator

@manuq manuq commented Oct 21, 2025

Here I prototyped how it would look to use needles to go back the way that the Void has devoured.

manuq added 3 commits October 21, 2025 11:06
Add a pile of books that has a float metadata "ingest_time" and is set
to 2.0. This will be used to stop the Void spreading enemy for that
amount of seconds.

For testing, this prop is also hookable and will move towards the
player, colliding with it. So the player could change its place or bring
it from other "islands" with the grappling hook.
In TileMapCover: Report the nodes as they are being consumed. And fix
the function documentation comment, previously it was also returning
true or false if nodes (not tiles) were consumed.

In the enemy new ingesting state, it does nothing more than waiting.
Transition to this state if the metadata of a consumed node says to be
ingested, and set the waiting to that amount of time.

Also emit particles when not the enemy is not moving. The previous
solution for emitting particles when not consuming stuff was
distance-based. Now if the enemy is standing in the new INGESTING state,
nothing would be displayed.
@manuq manuq requested a review from a team as a code owner October 21, 2025 18:17
@github-actions
Copy link

github-actions bot commented Oct 21, 2025

Play this branch at https://play.threadbare.game/branches/endlessm/more-void-grappling.

(This launches the game from the start, not directly at the change(s) in this pull request.)

@manuq manuq force-pushed the more-void-grappling branch from 668b966 to 3780c63 Compare October 21, 2025 18:20
@wjt wjt marked this pull request as draft October 22, 2025 16:26
@wjt
Copy link
Member

wjt commented Oct 22, 2025

I think the special thread-following camera logic isn't working quite right here, I think it is not considering that the player is moving as it bounces between the needles.

It's also a little frustrating to line up each shot. Should we be even kinder to the player and give each needle a default direction that is the correct direction (or the most obvious correct direction if there are 2 options, making the player work harder to go a fancier route)?

@manuq
Copy link
Collaborator Author

manuq commented Oct 22, 2025

I think the special thread-following camera logic isn't working quite right here, I think it is not considering that the player is moving as it bounces between the needles.

Yes, I noticed this too and forgot to comment about it.

It's also a little frustrating to line up each shot. Should we be even kinder to the player and give each needle a default direction that is the correct direction (or the most obvious correct direction if there are 2 options, making the player work harder to go a fancier route)?

I was thinking in defaulting to the direction that is closer to the one the thread coming has. What do you think?

@wjt
Copy link
Member

wjt commented Oct 23, 2025

I was thinking in defaulting to the direction that is closer to the one the thread coming has. What do you think?

Worth a try!

@manuq
Copy link
Collaborator Author

manuq commented Oct 24, 2025

I was thinking in defaulting to the direction that is closer to the one the thread coming has. What do you think?

Worth a try!

Actually this is how it works today with keyboard:

recording.webm

With joypad or mouse is difficult because the direction gets updated in the immediate next physics process loop to the direction that the input action is.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants