File Name: | Wild Mechakoopa |
Submitted: | by Darolac |
Authors: | Darolac |
Tool: | PIXI |
Type: | Standard |
Dynamic: | No |
Disassembly: | No |
Includes GFX: | No |
Description: | This Mechakoopa hops around with customisable period and maximum height. If the extra bit is set, the Mechakoopa will explode instead of recover after begin stunned. Includes a lot of defines to customise: -Custom palette for the extra bit version. -Expanded palettes for the recovering animation (up to 8 different palettes). -Customisable recovery time. And a lot more. Check out the readme for the details Based on the imamelia's dissasembly of the Mechakoopa. |
Screenshots: |
The biggest one is the placement of the explosion routine. It runs very early - before the sprite has checked its status. As a result, the sprite can explode after being killed - for example, you can stun it, wait a bit, then kill it with a star. What's more, checking the explosion timer every frame seems a little wasteful. It would be a better idea to move the explosion check to the beginning of the Stunned routine.
There are several oddities when stunning the sprite. For one, stomping the sprite makes it jump up, which is rather unintuitive and not a problem with the original disassembly. This is only really noticeable when the sprite's normal jumping ability it turned off with the !Nohop define. The sprite will also jump when its stun timer expires - the original Mechakoopa doesn't do this, but the disassembly does. I suspect these issues are caused by the sprite's "acts like" setting, which is currently 0F, a Goomba (Goombas do in fact jump after their stun timer expires). A2 (a Mechakoopa) might be a better setting but it may cause problems with the palette when stunned.
As a side note, some parts of the code, especially the graphics routine, can be optimized. It'd be nice if you could look into that a bit.
In my opinion, most of these issues are subjective and reasonably minor. You should, of course, try to fix as many of them as you can; just make sure to clearly mark any you couldn't fix (either in the description or the readme) when you resubmit the sprite.