Decoding the Schmup Design

I've finished the design for the first enemy, which I've lovingly nicknamed, "The Pinwheel".

  I designed their gold logo by mashing up the Aegis' shield design with a symbol of Zeus' lightning bolt. This purple and gold color-scheme will be their main visual calling card, so to speak. I also added the green bulb to indicate Health to the player, and it slowly goes to red as it's hit before it dies, like a diegetic UI. All around a fun time.

I also used this time to think about other enemies and enemy designs; I had a few ideas already, but this process really helped in 2 ways:

1) I figured out how to separate parts of the enemies, where the parent element is a static "platform" that controls movement, and it has a child element that shoots (this was all born from a desire for the pinwheel to shoot in a rotation pattern, but not spin itself). This opens up a lot of designs, both visually and how movement and shooting can play together, and with those designs came enemy ideas, but I'll get to those some other time.

2) More importantly, I figured out a spectrum, so to speak, that the genre seems to operate on. While I've seen people mention these aspects and their importance in variation, I haven't exactly seen it being talked about in this way, so I thought I'd put down my thoughts/findings here:

It seems that from all schmups I've looked at, from Touhou to R-Type to even that Lost Viking minigame found in Starcraft 2 have an enemy design formula that aims to balance between Movement-based challenge, and combat-based challenge. What I mean by this, is that you have a spectrum where on one extreme end the player's focus is entirely on moving and dodging threats, and on the other extreme end the player is focused entirely on shooting or killing the enemy. And along that line, studded in every possible combination, are Schmup enemies.

Some are immortal, and act as a temporary hazard you have to avoid, others are very much killable, and have varying attack rates and spawn rates  and movement patterns and health pools which determine where in the ecosystem of the game they fit. The Pinwheel is a medium-health enemy, taking a handful of hits to defeat; it comes as a compliment to other enemies, or a swarm, and fits the role of making a general hazard for the player. The goal is to zone the player out of certain areas, to force a focus on movement and limit maneuverability while other enemies make their attacks.

This kind of revelation was extremely helpful in forming ideas; It's nice to be able to think of a visual design, or a gameplay element, and work it into an enemy, but being able to point on a line and say "I want it to fit this niche/role" is going to be key in designing more enemies for the game.

Now let's get into the fun bits; honorable mentions of bugs features and mistakes design decisions that I found and made along the way:

1) Before I made the platform move, the Pinwheel was a single entity. I spent a good chunk of 2 hours trying to individually rotate sprites in different directions, before I looked it up and found out that's just not a possible thing to do with 1 game object. So I split the platform away from the turret, but in the wrong formatting, where the platform was just a child element of the turret. Since the platform was a child, it rotated with the parent, so of course my next solution was to spin the platform in the opposite direction; I was looking at inverse rotation formulas and everything, it was awful. only at midnight, with one of the cats bothering me, did I realize "oh wait, I can swap their roles and make the child spin....crap."

2) you'll notice that there's a small kickback to the guns on the turret; This is definitely done to be visually pleasing, and in no way is meant to mask that the bullet spawns practically in the gun barrel, and therefore looks like it travels out the side unless the gun moves backwards and away, this also was the reason for the slight pause when firing, which past me had somehow programmed in already so i just had to change a variable to 0, thanks past me! Programming that was as simple as making the gun animate back on the Y axis in a one-time ping-pong animation, and then realizing all the guns shifted in different directions, which lead me down the rabbit hole of figuring out the turrets being rotated does not change their relative positioning, and so I had to add in handling code that changed what axis the shift occurred on and in which direction.

That's it for now, thanks for stopping by and reading. Don't forget to follow me or check back every now and then for new updates.