Clean up setting enemy properties and enemy animation #1003
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
AllyTally
changed the title
AllyTally
force-pushed
the
enemy-types
branch
from
d163780
to
6ceea1d
Compare
In an effort to remove magic numbers, I've given every entity type a name. Hopefully I didn't miss anywhere.
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.
AllyTally
force-pushed
the
enemy-types
branch
from
6ceea1d
to
0240a46
Compare
|
Conflicts need to be resolved. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Changes:
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 PR also cleans up animation code, since that's a system which is tied into enemy properties. It 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.
Relies on #1007.
Legal Stuff:
By submitting this pull request, I confirm that...
CONTRIBUTORSfile and the "GitHub Friends"section of the credits for all of said releases, but will NOT be compensated
for these changes