Devlog #2: Spawning Points & Enemy Movements

My second devlog is up with a walkthrough of some of under the hood changes since my last devlog entry. I'm still using the same pretty placeholder graphics.

• I now have spawning points that gets triggered when the camera passes over them.
• I've added some initial path based enemy movements.
• There are a bit more advanced layer handling, using layers with sublayers for the different types of entities.
• The camera now moves over the world, so we actually have a scrolling background.
• I also decided on what kind of coordinate system to use and how to deal with anchor points. That will make my life easier later on when adapting to different aspect ratios.

Spawning Points

I was debating a bit with myself how I should spawn enemies and eventually I ended up deciding between a time based spawn or a position based spawn.

I went with position based spawn by adding spawning points to the level that triggers an assigned enemy when the camera passes over the spawn point.

Time based spawns would be cumbersome for many reasons. Changing the speed of the camera would require replanning the levels. As well as it would be quite difficult to design the levels without plenty of testing.

Using spawn points I can easily make a simple level editor where I can move spawn points around and combine them with different enemy types and movement patterns when designing the levels. I am also not locked to a certain speed so no major issues would occur if I change the velocity of the camera or the player.

Enemy Movements

I am building the game with the entity / component design pattern using the classes offered by GameplayKit to setup my component systems. Right now I have a GKEntity representing an enemy and I can attach a GKComponent that defines the movement for the enemy. The GKComponent can be configured with the path to follow. I have so far only implemented path based movement for the enemies.

I am quite sure I'll add some additional movement types as I get further along. I'm thinking along the line that I might make a protocol which different movement behavior types can conform to and then will be passed in to the component.

Next Up

I'll revisit enemy movements quite soon and expand upon that functionality, but before I do that I'll keep adding the remaining missing core functionalities needed to have a complete basic shmup engine up and running. Coming up next is a solid collision detection system that I am building on top of SpriteKit's physics.