Space Booty Sprint 6

This sprint was a lot of polish and finalization improvements from me. For example, I got into Unity’s built-in animator system to get weapon selection animations for the different player weapons.

This involved a little bit of code integration but I was fortunately able to get most of the logic working in the animator. I think it came out looking really good. You can also see the new ammo HUD, I didn’t make the UI myself but I got all the code integration working so that it updates with the respective weapon ammo counts.

In a similar vein, our team created some particle effects, and it was my responsibility to get them activating at the right times. I benefited a lot in this case from keeping my code organized, since I could go back into the base classes and add an explosion effect to play as a default on any enemy’s death. And the inheritance properties still let me go into individual objects and, say, scale up the explosions for that one in particular.

For space stations, which aren’t typical enemies, I had to go in manually but I saved some resources by getting the explosion size to scale with the number of battlements, so that larger stations automatically know to make their explosions bigger. 

The absolute largest task and biggest responsibility was getting all of the game’s sound effects working, since our team got together some sound files. This was a task that would’ve greatly benefitted from more earlier planning, but still came together decently well and I was able to retrofit all of the game’s objects with sound effects.

The big challenge of this system is that every object has to activate sound effects at different times. The pickups make a noise on pickup. The battlements make a noise on death, firing their attack, and repositioning. The player makes a host of noises on firing, weapon switching, taking damage, and dying.

So most objects needed to be manually assigned when to play their sounds in code, since everything functions so differently. But to help keep the process consistent, I did some research online and figured out how to set up a sound manager instance, which all objects can reference whenever they need to play sounds. Rather than each object having its own sound emitter, they call the sound manager which will assign them a copy of a prefab object that emits the sound and is then removed. I followed a lot of it from guides online but had to design my own function for looping sounds that are toggled on and off, such as the spaceship thruster sounds. 

Overall, the sound system ends up working well and sounding awesome, adding a huge amount of style and polish to the game.

Lastly, I wasn’t given a model yet but started on the basics of our final boss enemy. Its behavior for now is mostly pretty simple, since it stays in one place and fires homing rockets. The homing rockets, however, required a new script that was pretty fun to assemble. I wanted to make them more interesting so I have them spherically interpolate similar to the doom tower, meaning that the player can evade them by turning quickly. I set them each up with some modifiable properties for how long they chase the player and how fast they turn, and they make for an engaging part of the final boss fight. I look forward to finishing it up in the last sprint, where the speeds and timings will certainly be more refined. 

Ideally we wouldn’t be making major changes to things this far into development, but everything’s been kept encapsulated and organized enough I think it should be okay. The team is meeting soon to do some assembly and polish before the beta build, and the game should be feature complete by then.

Space Booty Sprint 5

The doom tower is, by far, the most complicated and impressive thing I worked on in Sprint 5.

The tower has two separate joints it pivots on, and as such, required a lot more math to get its aiming working properly. The base joint rotates to face the player as normal, but the second higher joint was more of an issue. After spending a long time trying all sorts of different solutions, I fell back on trigonometry to cut through to a solution.

Essentially, in order to find the angle at which the dish should point, we need to take the inverse tangent of the difference in y over the difference in x. Additionally, we don’t necessarily know which way the base joint will be aiming, so what I'm considering the x difference on the intersecting plane may actually require a distance calculation in three dimensions. We can find the appropriate value by using the distance formula on the x and z coordinates.

Getting the laser beam itself working was tricky as well, but I found the easiest solution was to just create my own model for it with a pivot at the end, so I can simply scale it forwards along one axis to match the distance it needs to go. Default Unity cylinders have their pivot at the center, which wouldn’t have worked for this.

Ultimately I really like how it chases the player in real time because it gives expert players the chance to try to dodge it if they can react fast enough. I think players often find it unfair when there's no way to avoid an attack, so I'm really glad I put the effort in to make the death ray something that really works and isn't just simulated with instant damage.

Next coolest thing is definitely the death ray. This is the final weapon for the game and required a few more bells and whistles than the others. First, it has a slightly modified projectile script that doesn’t get destroyed on collision. Most of the code is stored in the weapon script which handles its movements instead, since everything has to be more precisely tuned. It has a function that, using the same model as the doom tower, can rapidly scale the projectile forwards to mimic emitting a ray. For extra style, the ray disappears at the end by rapidly shrinking.

The biggest change was that the firing mode requires the player to hold the button down for a few seconds, which means I had to set up a new input function that cancels the charge-up when the fire button is released. It uses a coroutine that, after the initial press, waits for a second and cancels if the button is released, firing the laser if otherwise.

The biggest responsibility I had this sprint was getting the models imported from our modelers. Some of these were straightforward and one-to-one, but for some like the space stations or rotating lasers, I had to modify the code since the models had more moving pieces than anticipated. Others, like the enemy spaceships, were at a different scale than anticipated and as such had to have their movement variables (speed, range, etc.) readjusted.

A bunch of the new models can be seen in this gif, as well as the lives system I implemented to go with the new pickups and our designer's game over screen. As a programmer, I wanted to focus on making the prefabs developer-friendly by keeping them limited to only a few pieces, or preferably just one. When prefabs contain multiple pieces it can be easy for developers to accidentally click on the wrong one in the scene view. For some prefabs I just had to make new ones entirely, which felt suboptimal to me since the old ones had to be manually swapped out. I think this was good experience getting practice with using art assets in Unity, and is something I would like to learn more about.

Lastly, I got some basic animations working for the player’s ship, which will be expanded upon in the next sprint.