I can't write it for you before late September. I have too many other commitments, plus normal work, technical, and legal in nature. I'm having difficulty finding time too play Eiyuu, the only game (of any kind) that I've played in over a year, and I'm sotting time for that, for obvious reasons.
Notes:
You don't need to worry about the enemy ID of the in-built mini patra. You'd be using a custom enemy for orbiting foes, and one (or two, depending on the method) for a core.
Edge of screen: Alucard's stdWeapons.zh, and related headers will help with this. In fact, detecting the edge of a screen as a unction was why I had originally postulated stdWeapons.zh, which I set aside, and Alucard took over as project leader, making almost all, if not all of it. There are functions there that are extremely useful, and at some point, I may work to do the documentation on it with him, combining some of my misc functions and libraries with it.
Those functions can detect when an FFC is on the edge of the screen, and IIRC, when an NPC is, or an lweapoon, eweapon etc.
Two years back, I wasn't versed in C to any real extent, and had to use my knowledge of other languages to make out what was going on. It took a long while, but I eventually became adept, if not expertly, at ZScript, and its idiosyncrasies.
I don't rush making my games though, and I'm in no hurry. My main project, essentially requires making add-on game engines, and relies on some giigantic, and brilliant other projects, mostly by Saffith. Ghost.zh is an amazing tool, and well worth learning. Even now, I'm no expert, and I can't yet do some of what I need to accomplish, with complex movements.
Really, I'd like to code some kind of AI that makes enemies move in reaction to player actions, so that instead of pattern-learning combined with damage spams, there is a good degree of tactical combat. I want enemies to be fair, but I want them to be more immersive than the standard fare. I also want them to have personalities f their own, and as my game will allow the player to ally with many of them, I want that sense of involvement to be more than the standard tagalong fare.
While I understand that you want to put out a demo, you need to focus on making your game as a whole; concentrating on story, and planning ahead. People often critique my alpha releases because areas are incomplete, or seem broken somehow, but that's because I'm working primarily on the story, and the special game engines. I have plans for the game that make it massive, and I know it's a many-year development project.
If I designed it in a strictly linear manner, the demos may be more fun to lay, but it'd create an exponential amount of excess future work, as I'd need to redesign areas. I already need to redesign most of the golden dungeon floors that I've already made, because of my decision to make all tiles 8-bit, on the same CSet.
If you worry overmuch on one enemy encounter, in an opening level, you'll distract yourself both from achieving your long-term goals; and if you plan to have custom bosses for every level, it's not realistic to expect people to make all of them for you. Your best solution, is to start small... Make some item scripts, make a basic ghosted enemy, orb some ffc scripts. Learn a bit at a time, and then, after you see how some custom bosses, or global functions work, you'll have a foundation to comprehend them internally, so that you can apply that knowledge to make your own code from scratch.
If you want to release a demo now, use a placeholder enemy:: You can use the BigEnemy script to make something decent, if not fancy for the preset, as it's just an alpha release, and you can always change , or improve an enemy later.