Tip: When determining a time limit, remember that players won't be as familiar with the level as you are. If you normally complete the level with the timer around 100, others might run out of time on their first try.
Name: Thunder Slimer Author: dahnamics Description: That annoying mini-boss from Spark Mandrill's stage in Mega Man X is now in SMW. Acts pretty much like the original Removal reason: While this is certainly a unique idea for a boss to port to SMW, it could use a few improvements. (I also don't think it really "acts pretty much like the original", considering it doesn't have any of the blue slime that the original did, but whatever...that would be pretty hard to code into SMW anyway...)
- There are some oddities with the object interaction. The part of the sprite that actually interacts with objects is smaller than its actual graphics, so it ends up going one tile into the wall on the right side. Though considering SMW doesn't have a 64x64 object clipping index that I know of, fixing this might require some workarounds.
- The thing takes forever to defeat. I would definitely either make it spawn throw blocks more frequently, decrease its hit points, or both. In fact, the first time I tested the sprite, I didn't even realize it was supposed to spawn usable projectiles; I ended up putting a shell generator in the room and only realizing after the fact that it actually drops throw blocks.
- And something responsible for several issues: Once again, there is absolutely no documentation included. No readme, not much in the way of info in the .asm file, nothing. Some things that came up that weren't mentioned and that you could make note of are:
- The sprite apparently requires the No More Sprite Tile Limits patch to work properly (otherwise, the player's sprite will be invisible).
- How do you determine what sprites to spawn? I know that SPRITE_TO_GEN is supposed to be thunder_slime.cfg and SPRITE_TO_GEN2 is supposed to be lightning_bolt.cfg (after some trial and error), but the average user would not, especially if they're used to the "just set the projectile to the next sprite number" kind of sprites.
- Where do you place it in the boss room? Again, it took a bit of trial and error to figure out that putting it 4 tiles below the ceiling would probably work best. For that matter, there is no mention of any specific layouts for the boss room...and even though it seems obvious, it might be worth making a note not to have horizontal scrolling enabled in the boss room either; I did in my test level and managed to accidentally despawn the boss off the left side of the screen.
- How are you supposed to beat it? You're supposed to hit it with the throw blocks it drops, but that isn't immediately obvious, especially when combined with the aforementioned low frequency of throw block dropping. The hacker might (as I initially did) get the impression that there should be some sort of enemy spawner in the room, and after attempting to jump on it and failing, a player might incorrectly assume that there's some special thing you need to do to defeat it.
- Okay, this one isn't a removal reason, just a minor nitpick, but you don't need that string of comparisons for the sprite states (at line 123, the NO_CONTACT label). You can use a pointer table for that; look into the use of $0086DF. It doesn't matter as much when you only have a few sprite states (though 7 is definitely pushing it), but it's good practice and organizes your code better.
Just work on the issues I mentioned here and this sprite should be good to go.