Space Booty Sprint 4

During Sprint 4 our team got a lot of good feedback from the playtest, and while the game design seemed to mostly work pretty well, all testers had issues with the controls. So the most important improvement I made this sprint was definitely revamping the controls to use the mouse for the camera. In line with this, I also set up weapon switching to use the scroll wheel.

After doing a little bit of research things weren’t as difficult as I thought they would be, using the existing code with a new control binding that reads the mouse delta to detect movement. The main change is that now the code runs in Update instead of FixedUpdate, which deviates slightly from how I’ve been taught to do things, but it’s necessary in order to get the camera rotation smooth and fluid.

One problem I solved was that the editor can be a bit clunky to use while the game is tracking the mouse, so I quickly put together a simple pause menu that’ll freeze the game and make the mouse visible again. This perfectly makes the new controls easy to use now and sets us up well for later.

The first big challenge of the sprint however was getting the new prefabs imported. I worked alongside our producer to ensure everything was working correctly, since certain parts of the models needed to be fixed in Maya and re-imported. For the space stations, we created templates without battlements so that designers can swap in and out any type of battlement. My main contribution was giving them collision boxes so they function in gameplay, and re-establishing their prefabs with the new object organization. 

The more challenging part was getting the cannon battlements working again—their math before was relying on them being a certain size, and the finalized model is a bit higher than the placeholder. I updated the Pythagorean math and made sure it scales with the height the player is at. I used a similar technique for the loot space stations drop to ensure they spawn at the correct height for players to pick them up. The reason I made these changes was so that designers don’t have to worry about building their levels consistently around y=0, and can eyeball it a lot more without breaking things.

The fun part of this sprint, however, was obviously the explosions. The two exciting features I implemented were the player’s fourth weapon and the bomb towers. The player mines can be dropped behind the player and will explode on contact with an enemy, or after a few seconds. The enemy bomb towers work in a very similar way, with code that is mostly copied over with a few differences.

The only trick was that I needed both players and enemies to take damage from triggers as well, since explosions should be a trigger zone that can be passed through. For enemies, the player mines deal no damage since it should all come from the explosion. For the player, both the mine and the explosion deal damage and the player’s immunity frames ensure they’ll still only get hit once.

In order to get the bomb tower to launch bombs properly, as it rotates, it spawns four bombs at its head, each with a rotation of 90 degrees from the previous one, and uses a force to launch each one forwards relative to its rotation. The bombs I’m pretty proud of—they start being affected by gravity, but stick in place once they hit the “ground” which is set to the player’s height. This way, the visual of them being launched plays out perfectly, and their gameplay functionality is still mathematically consistent.

Lastly, there were a few other improvements, such as enemy AI improvements, checkpoints, and stargates at the end of levels. Overall I think this was another good sprint for me. I had a little bit less to do than before but the changes made this sprint were very important ones crucial to the polish and feel of the game. I think that the improved controls will make players really like the game, and that the new features added will be exciting.

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.