There's always the make it fire stationary non rendering bullets solution.
Then have that bullet spawn the pattern itself.
Yep. I'm hoping Keith sees my mantis entry and has time to fix it. I'm guessing it is probably 1-5 lines of code that weren't quite right, depending on how it was implemented. If he does, great, I don't have to change anything. If not, then I'll use another solution when the Invader is ready to go.
- yeah this bit of the game is full of not fun buggy things.
That's a bit harsh. I mean, sure, there are some bugs, but mostly minor stuff. I'd say 90%+ of the things work right, 8% work mostly, and 2% don't work at all. If I can't make awesome things with that sort of system, then I deserve to be hit by invisible 10km IJN Torpedoes.
trying to synch up cardinal movers (spawned together) onto a fixed grid seems not so easy.
You and me both. However, I'm reasonably happy with how the current draft of the Invader v2.0 came out. The files are up on the Mantis if anyone wants to take a look.
tiles have a radius of 32 it seems, so in theory dead on 64... in theory...
Ah. Hmm. I was calculating them based on 66. Using your numbers... I have new numbers... that don't line up with the old numbers.. Hmm...
With a 31x31 room, it seems I can place an enemy at 1050 from the center (but I can't place the player there, strangely. Perhaps the placement point of the player and enemies differ?) This gives me an estimate of 68 pixels per tile for enemy placement. Using 64 it gives me 1984, which is definitely too narrow. Except that for the player that might be right. I stuck the player spawn at 800 because 1000 wasn't working correctly. So if the spawn points anchorpoint differs based on game entity... Or maybe based on hitbox size?
My take home lesson is, don't require pixel perfect movement, especially since the player isn't able to keep track of everything. Also, pray that Misery or Pepisolo doesn't decide to shift the movement speed, hitbox, direction shift time, or breathe too hard.