Space Booty Sprint 3

Sprint 3 was all about getting the game ready for the alpha build so we could present it at a public playtest. That means I focused on the one major component that was still missing: enemies. This gif shows off how it looks in game, these small enemy corvettes chase after the player and fire lasers when they get close (though everything's been made even faster in future updates).

I borrowed a lot of code from the battlement cannons, since I’d already set up stationary turrets that shoot at the player and can be shot at in turn. This meant that healthbars, projectiles, and damage were all already set up. What I needed to add was movement, which I did in a similar method using spherical linear interpolation of the corvette’s rotation to face the player. I made them rotate much faster though, so while they do need to re-orient themselves as they chase down the player, they’re threatening in packs because they’re quick at it and likely to attack from the front or behind.

The movement for the frigate enemy was even more complex, which I broke down into three states: idle, chasing, and attacking. Once within its vision range, the frigate starts chasing the player at high speed, but once in attack range, it needs to be able to line up its laser barrages from its side-mounted cannons. So I have its interpolation change based on its state, orienting around a rotation vector from either its front to the player or its side to the player when it needs to attack. You can see it make this adjustment in the gif.

What was a fun challenge was adding the upgrade shop, built up from simple treasure pickups I added using my existing pickup code. I started with a ShopMenu script that manages the whole menu, being enabled/disabled by hitting the shop button. It has a masterlist of references to the player and each button in the shop, and connects the player’s button presses to the appropriate upgrade.

The button references double as data storage for upgrades, since each button also contains the info for its matching upgrade. The ShopMenu directs their behavior, telling them when to update their text or attempt to buy an upgrade, but each Upgrade can internally handle all of their logic, such as checking whether they have been purchased or unlocked. Lastly, the player has a public function to update their max health once an upgrade has been bought.

There was an assortment of other gameplay features added this sprint, such as these laser hazards. Much like damageable objects, I made an interface called IHazard that lets the player run their individual damage function on collision. Each hazard can then be customized to what they need to do, but for this, it just damages the player. Since they’re all in their own scripts, they can also be given custom movement, such as spinning or alternating.

Other additions include a rocket weapon for the player, which is about the same as the laser blaster but slower and more damaging. With the weapon system I designed last sprint, it was a breeze to add. I also let the player respawn and reset their ammo on death.

One last developer feature I added was an “Essentials” package prefab that level designers can place in their levels to automatically set up the player, camera rig, and UI. This was to make it easier for my team to get their levels working without needing me for help.

And that’s everything! I’m really happy with the work I put in this sprint. Just about every aspect of gameplay got some sort of improvement or addition here, and it’s really developing into a full game, more detailed than many projects I’ve worked on in the past. Still, my experience is guiding me well, and I’m familiar enough with these types of gameplay systems that I can implement them comfortably. I think I’m working at a very sustainable pace that should get all planned features implemented by the end of the project, since the core gameplay is well established and should be easy to add on to.