Custom Enemy Lottery

[Oi27]

Put a bunch of custom enemy ideas in replies! I will pick a reasonable(!) one at random and have a go at making it.
==RULES==
-One entry per user.
-Normal enemies only: no custom bosses.
-Remember hardware/engine limitations.
-Attach 4bpp SNES gfx with your submission if you have some you'd like to use.
==DATES==
-Winner will be picked 12/16/22 at 6PM EST.
-Enemy will be finished by 1/1/23 and assemble with ASAR.
==ETC==
Be creative, and please only submit if you are currently making a hack.
Good luck!

[MetroidNerd#9001]

The Ghost of Ninjoe: Basically a merger of the Wrecked Ship ghosts and the Ninjoe enemy from Super Paper Mario. I don't have 4BPP graphics, but I have some reference images.
[spoiler] [/spoiler]
This enemy will teleport in like WS ghosts to a random point near Samus, either on the air or along the ground (whichever is more reasonable to implement/you think works better). It will fire shurikens at Samus, either one aimed directly at where Samus is, or three where they are horizontal, diagonal up, and diagonal down (again, you have discretion). If you shoot it, it has a random chance of teleporting away, leaving behind a bomb that explodes in about a 3x3 radius. It throws once before disappearing and teleporting to a new location. Because I am not providing actual 4BPP graphics, you don't have to do the graphics yourself if you don't have the time/don't want to.

[TobiMikami]

Funny you mention Super Paper Mario, I was just thinking about that game yesterday! Specifically that last level with the black and white, I thought about implementing a little something like that, might have to use my engine to make the free code version of a mini hack lol.

One idea off the top of my head is an emeny similar to LoZ Wind Waker's version of the "Floor Master" and I say this iteration particularly because:
1. Unlike the decapitated roaming hand, this floormaster is a black hole that's immune to damage, it doesn't appear until you get ridiculously close and it emerges at the speed of sound damn near, with that freaky noise, and if it grabs you it drags you down into its creepy portal thing to another world. This video shows it in the original game.
https://youtu.be/b-a4SFfMWWY
What's interesting is that they can actually be frozen with ice arrows and shatter with skull hammer, which is a very Metroid like concept on its own, the dark, creepy ass aspect of these things is another. And finally, the most important part, the ability to drag you back to another location, I can envision it utilizing something like those rooms in Maridia that have the quicksand and stuff, with different door transitions so you don't get dragged to the room below its wherever you changed the "door" pointer to for it. It was a quick snap of the mind idea, but I always loved these things outside the game cause they're so fuckin bizarre, that black and purple hand reminds me of a demon trying to drag you to hell or some shit, creepy but beautiful

[Exister]

An enemy kind I'd like is something similar to these floating red enemies in circle of the moon: an enemy that floats relatively close to samus and then shoots a slow but big projectile that curves to hone in on you. Slow, flying enemies are pretty underrepresented in sm, fish or atomics would be the only thing that comes to mind but they're very thematically specific and aren't very interesting in how they interact with the player. As for the graphics, I unfortunately don't have anything, perhaps a flying alcoon would work? Alcoons already spit fire stuff so that works, and a flying one would round off the swimming and standing seahorses- er, I mean, alcoons :heheh:

Example video of the floating red enemies in action:
https://youtu.be/3Es-6fefSs8?t=1846

[Tundain]

Totaly not last minute entry: tesla coil
Basically, a turret that shoots instantaneous electricity sparks in all directions (due to game limitations, this prob just means in 8 directions). Whenever samus is nearby, it pops up, starts charging, and if samus doesn't kill it quickly, it releases it's spark before closing again (while closed, it's invulnerable).
The turret can be placed on ceilings/floors? maybe on walls as well? (that's free to choose, i was thinking if it's just ceiling/floors, it could "pop up", but that's pretty trivial).

Don't have any gfx at hand, but i can try to make some if necessary.

[Oi27]

Tobi wins! We'll try making the floormaster enemies. Updates will be provided later on in this thread!
Video of ingame RNG: (drawing starts at 12:30 in)
https://www.twitch.tv/videos/1680966178

[Oi27]

floormaster

Teleporting action and graphics are complete!
The animation seemed like the hardest part so I tackled this first; it takes advantage of a property where you can draw sprites behind the background but also in front of Samus, acting as a layer mask.
Individual tiles in a spritemap can have this layer property on or off, but this caused issues with the background of the portal; we want it to the graphic of the "inside" of the portal to stay behind Samus, while other pieces go on top. We can't do that and the layer masking with one enemy since we're using both the inbuilt spritemap priority and the enemy-specific layering options.
To account for this on the closing animation, I made a separate enemy projectile that acts as the "background" of the portal enemy, and the actual enemy is the ring that closes around you. The projectile is set to the lowest priority, so it draws underneath all the other sprites, including the layer mask. It exists until the enemy is killed and follows it around, and has some specific animation code related to shrinking during the portal animation. Although, if you look closely at the gif, there's still a bug where this projectile isn't teleporting as well, so you can see the level background inside the ring while Samus is exiting. HMMMMMM....
Another existing bug is that the camera has to be in a pretty specific position or else it causes graphical glitches from the screen failing to update.
---
Editor Setup:
Speed1 = Teleport destination X
Speed2 = Teleport destination Y
Tilemaps = Movement type (when we get to it)
---
This means each Floormaster in the room can dump you out at a different place. Exciting!

Enemy is ~50% complete.
For the hand code, the plan is to copy the existing grabby-hand in the game and go from there. What could go wrong!?
Then the next step is to have a few AI modes for the Floormaster to:
+move around the room randomly
+seek Samus
+stay stationary
based on the initial tilemaps value.

[TobiMikami]

This is absolutely amazing! I just now noticed this I've been plugging away on my own programming, I actually gotta do  vertical doors and save file loading room transitioning fun, I might implement the same feature if I could ever get my whole Samus/view synch whatever in order with that, what size in pixels are you limited to for it? I might be able to sprite it up by hand well.within the SM 16 bjt color structure, it'd literally be more about the space to protect it without it looking all "scrunched up" and hard to see.

I see a lot of really good opportunities for this, not only as originally designed, but it also acts as a sort of "portal" like the one from the Impact Crater to the Artifact Temple in .Metroid Prime, perhaps this would create a means of accessing unique areas based on the developers mapping of the doors from that point on and whether it's a one way trip. This is so cool to see, these are things that I'd have never thought possible on 2014. Incredible!

[Oi27]

Deadline extended to 1/20/23:
Didn't have as much time as i thought to make it over the holidays. No stress!
Ran into some difficulties getting the hand part of the enemy to work with the vanilla Hands 🤔
The approach I decided on is to have the portal part of the floormaster possess the next enemy index, which the level designer should set as the vanilla Hand.
Its code will be tweaked slightly and it might make them unusable by themselves - this will be avoided if possible.
And some of the difficulties have been with having the two enemies work together nicely. Notably, the Hands do not like to be moved.
This may also entail a lot of hardcoded pointers for checking what state the Hand is in; not sure how to approach this aspect yet. The BEST move would be to include the Hand's entire code and label all of its functions; maybe just bite the bullet and do that.
Aside from that, the enemy is in more or less the same state as the previous update.
More will be on the way!

[TobiMikami]

I'm seriously impressed with the state from the previous post, and the fact that you have a pretty solid idea of what you gotta do within the ROM to write for it! If I was writing this AI as a free code that'd be no problem, but trying to make it work within the confines of a compiled program, I wouldn't begin to know what to hijack and move where, so kudos for being able to get this far really! This was always one of those cool thoughts in the back of my head that I was like maybe someday somebody will make a cool gimmick contest hack with something like this, it's so cool to see it come to life for real, you're the man, keep up the good work!