Seven Seas to Glory - Sprint Blog 4

Sprint 4

My goal for Sprint 4 was to enhance the ship and hand-to-hand combat to be more engaging, as well as add visual elements that can replace some of the tutorial text.

Before I began working on adding things to the project, I took time to reduce the project size. Some old assets and packages weren’t being used anymore, and I wanted to clean that up before adding more things that would have to be sorted through. Somehow, a build ended up in the project folder, so it was nice to be able to delete that. At the time of doing this, I reduced the project size by about 0.5 GB. While that isn’t much, the project file is large enough on its own, so it’s better to dedicate all the space to what’s required. 

The first feature I worked on was the gun. We already had the model and texture for it, but now it was a matter of adding the ability to use the gun. I started by making the gun shootable. I wanted the gun to work similarly to the cannon in terms of scripting. The difference is that the gun’s aim is based on the center of the camera, whereas the cannon can be aimed up and down. I also wanted the controls to shoot the gun to be the same as the controls to swing the sword, so the transition in combat is easier for the player to adjust to.

I then adjusted the character controller to allow the player to switch to the gun. I achieved this by creating a bool for whether the player was using the sword or the gun. The player can toggle this by pressing either 1 for the sword or 2 for the gun. When the player is using the gun, pressing the LMB instead activates the gun script to fire instead of making the sword swing. At the moment, there is no separate animation for the gun firing.

After the player was able to switch between the gun and the sword, I made it so the gun has a reload time similar to how the cannon has a reload time. I used the same reload UI as the cannon, but I adjusted its duration to be slightly less than the cannon. There was also the issue of the reload UI staying on the screen when the player switched to the sword, so I had to make sure that the UI was no longer active when in the sword.

I moved on to creating the enemy drops that the player gains after combat. I started with the money gain. I wanted the player to gain a random amount of money from $10 to $100 after every successful combat encounter, but if the player is in hand-to-hand combat mode and chooses to kill the whole crew they gain an extra $100. I achieved this by creating a script called KillGain, which accesses the player class, and two public functions are called in the ShipHealth and SpareOrKill scripts. One function just gives a random amount of money to the player class, the other adds $100 to the random number.

I also wanted the enemies to have a random chance to drop special cannonball types, the exploding and freezing cannonballs. I added the logic for this in the KillGain script. I wanted the chance to get a cannonball type to be 50%, 25% for each special cannonball. The script makes a random number from 0 to 3, with the higher bound being adjustable in the inspector for future balancing. If the number is 0, the player gains a random amount of explosive cannonballs from 1 to 3. If the number is 1, the player gains a random amount of freezing cannonballs from 1 to 3.

Now that there was a way to gain special cannonballs, I made the special cannonballs limited to the amount that’s stored in the player class, with an infinite amount of normal cannonballs. I also wanted the cannonball to automatically switch to the normal cannonball when the player runs out of the current cannonball type they are using. This was decently easy to achieve. I didn't worry about updating the indicator text when the automatic switch happened because I knew I was going to work on the inventory next which would tell you that information in a more visually appealing way.

Lastly, I created the inventory system for the game. While it was still time-consuming, we essentially had something like an inventory already. It was more a matter of making it visible to the player and using it to replace some of the tutorial text. I first made the art for the inventory, making all the elements separate such as the inventory background, the text areas, the item boxes, the active indicator, and the images of the items themselves. The inventory’s active indicator corresponds to what the player is currently using rather than the button that the player pressed. This way, it’s always accurate to what the player is seeing. It also automatically changes from the sword or gun to the normal cannonball when the player switches to the cannon mode and back to the sword when the player switches back to the character. I also had to change the numbers that are used for the cannonballs for this to work properly. The biggest challenge at first was making it so the inventory didn’t take up too much space on the screen and having it stretch properly with different camera views.

Seven Seas to Glory - Sprint Blog 3

Sprint 3

My goal for Sprint 3 was to complete the electronic prototype by polishing the visuals and core loop mechanics.

I started the sprint by revising more of the design document to encompass more features of the game. Since the core loop is complete, and the sprint will mainly be focused on making the core loop as solid as possible, I decided that planning for more features in future sprints would be a good idea. I mainly focused on designing different enemy types, different ammunition types, and shops. Adding those would make the game more fun, and there would be enough time to polish it before the semester ends or new features are added.

Next, I added health bars to the enemy and player ships. Since I made health bars in the last sprint, I didn’t have to deal with the UI, but I had to code the ship health script for the health bars to do anything. 

I then created a popup UI script, so that when the player enters a certain trigger collider, a message will pop up that will tell the player what to do. I made the text public so that it can be easily changed depending on which collider it’s attached to. At the moment, the script is only being used for the ship wheel, but it’ll be useful when more interactable objects are added.

One issue that was discovered a lot in the core loop playtest was that players would fall off the ship with no way back up, or get confused as to which ship is there’s. I decided it would be a good idea to have the player be able to float and return to the ship because of this problem. I started with making the floating script that allowed the player to float in the water rather than fall into the abyss. This took a bit of adjustment to make sure the first-person camera was sitting on top of the water instead of below it, and I wanted it to be realistic to being in water. There’s a bit of a bobbing motion when the player initially lands in the water which slows down gradually.

After making sure the player could float in the water, I made it so the player could return to the ship with the press of a button. We didn’t have swimming mechanics or animations, and it wouldn’t have been a good use of time to implement that in this sprint. Pressing F was a better option. The player isn’t only able to return to the ship from the water, but the player can also return to the ship from other enemy ships. I didn’t program the script to work this way, and I couldn’t figure out what the cause was. I then realized that this helped solve a different issue, which was that players would forget which ship was theirs when they would jump to an enemy ship. I decided to leave it as is.

I moved on to creating different cannonball types. I started by making an ammo class because I figured this would also work for different types of bullets for the gun. I created an exploding cannonball and a freezing cannonball. Both were similar ideas in terms of coding, they were just accessing different enemy ship variables. The exploding cannonball deals extra damage over a given course of time, while the freezing cannonball deals the base damage and reduces the enemy reload speed for a period. I made a script for each, as well as added new functions in the enemy ship scripts for taking continuous damage and reducing reload speed.

Since there were different cannonball types now, I had to give the player the ability to switch between them. Instead of making a whole inventory system for a game that didn’t have enough collectibles to justify that at the moment, the player can simply switch between the cannonball types by pressing 1, 2, or 3. I also made a textbox that told the player which type of cannonball was being used.

There was one card that I had left for this sprint that I didn’t finish, and it was getting the water to render in a build. I discovered that the water rendering issue only occurred on Windows since my Mac build rendered properly, which made it even harder for me to complete the task. I didn’t have a good way to make changes and test out if they worked because the problem was only on Windows. The water was a free Unity asset from Boat Attack, so I searched for answers online to try and find if anyone else had the same problem. I eventually ran out of time in the sprint and I had to pass the card off to someone else who had a Windows computer for the next sprint.