Can we make it easier to make a Void Enemy mechanic configurable?

[jgbourque]

I am wondering if it is possible to allow the void tile & decorative asset eating power of the Void enemy to be more easily added or removed while designing a new StoryQuest. And if there are other behaviors or states or the void enemy that might be made more readily configurable as well.

Just opening a conversation here!

StoryQuest Making
Example Benefit:

The game design benefit may be to offer more variety when mixing and matching other mechanics such as building a repel fill barrel type gameplay loop that uses the Void enemy to chase the player while they are trying to repel and fill barrels without destroying the tilemap along the way.

There are times however when someone may want to use the Void Enemy as a kind of timer wipe mechanic and they DO need the tile eating.

Another Example:
Maybe I want to spawn void enemies , multiple, within a scene to chase or even chase speed along preset path2Ds without prematurely destroying the world in the process.

[manuq]

@jgbourque great idea! And all the components are there already! We have walk behaviors, and a TileMapCover that can very easily paint tiles. It took me 3 minutes to make the player paint sand:

Grabacion.de.pantalla.desde.2026-08-14.11-59-24.mp4

• Add a TileMapCover layer. Setup: use the exterior floor tileset, use "Sand" terrain.
• Add 2 lines of scripting to paint the current coordinates of the player.

[jgbourque]

So playing that move back in reverse, if I remove that same code FROM the Void enemy, they will no longer "eat the tiles" and "paint the void" while chasing? @manuq

[jgbourque]

I might need to see the functionality get removed from the Void_Enemy

[manuq]

So playing that move back in reverse, if I remove that same code FROM the Void enemy, they will no longer "eat the tiles" and "paint the void" while chasing? @manuq

Void enemy works by painting tiles, not eating them! That is an illusion. Think the Void tiles as Harry Potter's Invisibility Cloak. They are tiles on top of all other tiles, and with the help of a shader they display a black background of stars that look far away. The Void enemy works by passing a TileMapCover node to its Void Layer property:

[manuq]

@jgbourque I converted this to a discussion.

[wjt]

So some concrete ideas:

• We could make the void-spreading enemy not strictly require a patrol path - in which case in its IDLE state it would just lurk in one position (until triggered)
• We could make the enemy not work but also not crash if the void layer (or for that matter the path, as an alternative), and show a configuration warning in the editor.

[wjt]

We could also refactor it so that different aspects of its behaviour are separated out into different components - e.g. the "consuming a +-shaped region of tiles" behaviour is not strictly connected to the patrol vs chase behaviour... But I don't think it's worth it, because this behaviour is so bespoke to this enemy, and the other components are already quite generic.

[wjt]

I implemented the first two bullets in #2887

[wjt]

The game design benefit may be to offer more variety when mixing and matching other mechanics such as building a repel fill barrel type gameplay loop that uses the Void enemy to chase the player while they are trying to repel and fill barrels without destroying the tilemap along the way.

It wouldn't make sense for the void enemy to not destroy the land in this case: that's what it does.

But if you wanted to make an enemy that pursues the player around a map, you can do this in a custom enemy scene using the NavigationFollowWalkBehavior