Space Booty Sprint 2

I started sprint 2 by working on the broadside cannons. Getting them to fire at the appropriate angles wasn’t too much trouble, but this did require some (anticipated) improvements to the weapon system. 

I wrote each weapon its own script using a base abstract class. Each weapon is separately attached to the player’s arsenal, and the existing weapon switch controls will select the appropriate weapon script. This lets me use the same set of controls to give each weapon a unique set of functionality, while keeping each one modular and self-contained.

This gif shows off just about everything I got working this sprint, which was a lot! It all comes together seamlessly, but there are a ton of little moving parts I had to get working.

I started by making sure the player lasers could damage objects. Then, I set them up with healthbars and flashing when they get hit. Next I made sure the turrets could rotate to face the player. The easiest way to do this would have been to just use Unity’s LookAt() function, but, anticipating what the future turrets are going to need, I wanted to make them have to turn gradually to face the player.

So instead I set up a spherical linear interpolation function. For the projectiles, I had to additionally incorporate some trigonometric functions to get their angle to be correct. The awesome end result is that the cannon turrets track the player pretty well, but not perfectly, and are susceptible to missing when the player moves and turns quickly.

And once I got the cannon battlements firing, I set up a health bar for the player as well, and all the appropriate functions (damage flashing too). Standard stuff. 

There were a whole host of other additions I made, such as the sprinting mechanics shown in this gif. It runs on a simple toggle system, but makes movement and combat quite a bit more interesting—it’s a lot harder to aim when you’re speeding up, which means it’s a bit of a tradeoff.

I also put together a pickup system that lets the player collect health and ammunition canisters. This is pretty standard from projects I’d worked on in the past, where there’s a base pickup class with a pickup function that can be customized to give the player whatever statistic is requested.

What did require more thought was getting them to spawn in an evenly distributed pattern.

This segment then got implemented for the space stations, which explode when their associated battlements are destroyed. Circles are tricky, but as always, some math can get it working. To let designers set this up however they want, the space stations have a publicly accessible list designers can place the matching battlements into. There’s a similar list for the pool of loot dropped.

Finally, I put together our first prototype by designing and implementing a miniature level that demonstrates all the mechanics created thus far. Our playtesters can try out flying the ship, firing the cannons, getting into fights with battlements, and collecting items.

Overall I’m super proud of the work I did this sprint, it puts our team in an amazing place to keep making progress on the game. I got a bunch of little systems all working together to create a cohesive combat system for the game. It looks obvious now that it’s put together, but even just this most basic enemy required both sets of projectiles, healthbars, aiming, and feedback. That’s why a lot of the code I wrote, such as the weapon system, is immensely scalable, meaning that future features will be even easier to implement.

ProcGen FPS Update 2/7/2025

 

Space Booty Sprint 1

Sprint 1 of Space Booty was a little shorter than usual, being only nine days, but with all my experience at this point I wanted to hit the ground running to be able to get to the fun parts. At this point, I’m pretty comfortable setting up things like player movement, camera controls, projectiles, pickups and the like, so it was mostly a matter of getting all the basics up to speed.

As the team’s lead programmer, I started by setting up the github page for our project and getting everyone on. Then I got right into the standard project stuff, using the new input system to setup basic Input Actions for player controls, and getting a basic gameobject for the player. I also made a script for the camera to follow the player around. At this point these all are tasks I’ve done for several projects before.

While it does use some resources, what’s nice about this camera system (as opposed to just making it a child of the player) is that it’s great at showing velocity and motion. Since the camera is interpolating to the player’s position, it lags behind a bit, so when the player character is moving really fast, it shows in its slight deviation from the screen center.

Next I got the camera to be able to rotate as well, and the designer handed me some changes to the movement to make W/S move forward and back and A/D turn the ship. I gave it a quick little model to help show off the ship’s orientation in testing.

Then I got to the weaponry, starting with projectiles. The laser beams have a simple script that propels them forwards, and I used Unity’s layer collisions to make sure they don’t collide with the player—a very comprehensive and solid solution.

I also put together a quick ammo system, with straightforward logic. Right now it just fires on player click, but in the future I also know how to get hold-to-fire if we want that instead (since I personally prefer it). 

Our player is going to have at least five different weapons to use, which means I do have to start thinking about how to get that to work. Though I only setup the basic weapon this sprint, I began some framework to iterate on in the future. The player has a list of its weapons, referencing a Scriptable Object for each weapon. Right now, this is shown in how each weapon has its own ammo count. In the future, I’m going to need to figure out how to get each weapon to have different firing patterns for their projectiles.

One brand-new discovery I made this sprint came with the weapon switching system. I did a bit of research and figured out how to use one Input Action to map to all the different numbered keys, returning the number of the key that was pressed. This is super exciting since it saves a ton of lines of code by compressing them all into a single contextual function. There aren’t any weapon models in the game yet, but I was still able to show off this feature by adding some quick temporary UI. As you can see, it works flawlessly, and I’m really happy with it.

With that, the basics of player movement and attacking are totally good to go. Most of the work was pretty by-the-book for me, but I still got to make some new discoveries and I’m happy with how much I could get done in only a little over a week. Going forwards, I’m confident that I can get the programming totally under control for this game.