Clean up setting enemy properties and enemy animation #1003

This commit cleans up setting enemy properties. It deduplicates code, makes custom levels spawn enemies better (doesn't just pretend it's a certain main game room to set the settings) and makes everything a nice registry. This is the basis of a future system which might allow for more enemy types to be used in the editor, and even custom enemy types... But it was mostly done for cleanup, since I hated how the code looked.

This should keep most of the mess outside of `setenemyroom`, however `setenemy` still has a few variables I don't know how to tackle.

There's now variables in the struct to override certain properties.

Emitters are odd. They rely on `setenemy` to set the right type of the entities they emit. However, `setenemy` only gets called in specific rooms, so if you use these enemy types outside of those rooms, they'd just infinitely spawn themselves and, well, that's a memory leak. The prior fix for this was simply not allowing emitter types outside of those rooms. This, however, feels very hacky and is a little disappointing as well. This commit improves emitters by no longer relying on `setenemy`, and instead setting the emitted enemy type ourselves. However, `setenemy` still happens, and to make sure we don't set the enemy type *twice*, we set the `para` attribute of the spawned enemies to `-1`, so that `setenemy` will not do anything at all to the spawned enemy. The reason I don't remove the code in `setenemy` outright is a couple things: - The main game code still relies on it for spawning the initial enemies in the room - Custom levels may rely on the prior behavior (sadly)

There's a few cases in `setenemyroom` which are only meant to override the enemy colour set in the type, so let's move that to it's own function instead. While we're at it, we should move the custom level enemy color logic there as well, because it's in an awkward place. This will also help with things like custom enemy types in the future, or using things like the emitters in custom levels, because this will correct those colors in custom levels.

While the last commit was an attempt at making colors be set better, this one should help more. Basically, things that emitters emit now copy the emitter's color. That means, if you change the color of the emitter, what it emits will change as well. This means we don't have to worry about setting the colour ourselves, just the enemy type. `set_enemy_colour` is now called BEFORE setting the type, so the type's color will override the room color. This is what we want -- in the future there might be custom enemy types, and if you specify a specific color, you probably want that color to be used. But wait, don't the types usable in levels have their colors set? Well, this commit also duplicates the editor enemy types and sets their colors to `-1` so they'll use the room's color instead, or more accurately, they'll use the color they had previously, which was the room's enemy color. With this system, old levels which use main game enemies will have the correct colors -- the colors stored in their enemy types. And if it becomes possible to make custom enemy types, if someone makes an emitter which uses the room's color (by passing in color `-1`), the enemies which it emits will use the room's color as well, since it will copy what the emitter itself uses. All of that just to say: colors are now handled a bit more sanely.

So, the radar enemy type was originally 16x16. I meant to change it to something that made more sense, but I messed up and made it 32x32 instead of 64x64 like it is visually.

This removes the magic numbers used for `animate`, and makes the animation system far more flexible, instead giving entities the option to control what they need, instead of having a bunch of duplicated hardly-readable code.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Clean up setting enemy properties and enemy animation #1003

Clean up setting enemy properties and enemy animation #1003

Commits on Nov 17, 2024

Clean up setting enemy properties and enemy animation #1003

Are you sure you want to change the base?

Clean up setting enemy properties and enemy animation #1003

Commits on Nov 17, 2024