The thing about Owl's enemy behavior

[Rusty-Box]

Owl strikes me as one of the enemies that is missing a certain... something. An enemy that drops mainly bombs but can also drop several other objects is a great and interesting start. However with its current implementation, utilizing Owl in levels is rather tricky, especially in regards to the "defeatable badguys" count of the level completion statistics. Place them to high, you can't defeat them. Place them too long, they are less of a threat.

Now you could suggest: "have Skydive explode on impact with objects and let them be thrown back at them as a means to defeat" and I agree. Do that too. But! That does not fix the issue for Owls that do not carry Skydives (also one could argue that it also still limits the ways you can use Owl since they must always be in throw-able range of Tux)

Now I did some thinking myself and came up with the two rather simple approaches.

1. Owl no longer counts towards the "defeatable badguys" count in the level statistics
2. Owl, upon dropping the object they carry, flee the scene, flying up high in the air, despawning shortly after being off-camera, counting as "defeated" in the level statistics.

What we could also do is giving Owl a new attack/behavior for when they are out of objects, ideally something that brings them back in closer range for the player. I also am personally against the idea of them respawning their object of choice, however this is technically also a thing one might think of.

[tylerandari13]

Lol I have an idea.

What if there was a smart owl that after dropping the skydive would start heading for a specific point (probably a spawnpoint in the water) to go get another skydive?

[pazkero]

Maybe a setting "restock at (x, y)" (are such stuff even a thing? I assume if you can set an object you could also set something like that) which if set, makes the owl head to (x,y) position, and if not, moves it to off-camera and de-spawn automatically.

So the default behavior would be that once dropped it leaves scene, and if a restock parameter is set, it'll make a loop movement. Tech-wise, you would probably first implement #2 as the default and add a comment about this future™ setting, and then when time permits and if it doesn't make a salad of the logic, you implement what @tylerandari13 suggested. (So if in practice this turns out like a bad idea, you already "fixed" the issue, and left an improvement note for the next willing contributor to deal with)