Seven Seas to Glory - Sprint Blog 6

 Sprint 6

My goal for Sprint 6 was to fix all issues and imperfections that were present in the game and make the ship combat a more fun experience for the player.

The first thing I did was make the cannon move up and down when aiming. This made it so the aiming of the cannon was more realistic to real life. I interpolated the cannon’s movement to make its rotation feel a lot more smooth. I also clamped the rotation between 10 and -1, so the player can’t rotate the cannon an unrealistic amount. This also allowed for the cannon to be angled down enough to still hit the enemy ships when in close proximity.

Next, I added two more cannons to each side to make the combat between the player and enemies more fair; enemies have three cannons each. I thought this would be easy at first, but then I thought about the issue with the special cannonballs and the possibility of the player having less than three but more than zero special cannonballs. I then decided to have each side have a master cannon that controlled the actions of the other two. The other two don’t have scripts of their own. This way, I was able to not only make sure that the special cannonball count was accurate to what the player had, but I made it so that two special cannonballs would shoot out the outer two cannons and one would shoot in the middle cannon. This made the difference in cannonball types feel less random and more purposeful. Another thing that stemmed from this task was making sure the special cannonball values were stackable. Both of them called an IEnumerator, which wouldn’t run if called multiple times. Instead, I created a bool that detected if the ship was hit, and an integer that stored the number of times the ship was hit. This allowed for the values to stack even if they hit the ship after the IEnumerator had already begun.

I, then, implemented the cannonball models. This consisted of making sure both the inventory and shop UI depicted the accurate cannonball models. I also added particle effects to the bomb, which made it look like it was lit. Most of the work for this was checking to ensure that all the cannonballs had the proper colliders and scripts attached.

After I was happy with the cannon’s functionality, I moved on to cleaning up the UI. Text would sometimes appear on top of each other, which made prompts hard to read. I began by first making sure only one health bar was on the game canvas at a time so that the UI was less cluttered than it needed to be. I then moved “Press F to return to ship” under the health bar, and the hand-to-hand prompt just under that.

I also implemented the sword model for the player. I had to ensure that the sword script was attached to the model, as well as make the collider a trigger so it would function properly.

Before completing any more cards, I had to deal with fixing merge conflicts that occurred. It took me two days to find all the conflicts from the merge because they weren’t all obvious. The most important issue that happened from the merge was that the cannons fired on the z-axis again. The script was the same, but they didn’t work properly. I tried making a prefab of the cannons and importing the package, but that didn’t fix the issue. I had to create a prefab of the water that was merged and add the prefab to a branch that didn’t have the merge yet. This solved the cannonball issue. Many of the other issues were finding discrepancies in the inspector.

During the last playtest, some people noticed that pressing Y for hand-to-hand combat didn’t always work. My teammate figured out that one of the reasons for this issue was that the duration of the choice was too short. We increased the duration to 10 seconds instead of 2. I then added a line that ensured the text would disappear after the duration was up. This helps avoid confusion about when the option is available. I also noticed that the option for hand-to-hand combat would sometimes appear when the player is already on the enemy ship, so I added a small if statement that made sure the player was in the ship mode before presenting the option. Lastly, I decreased the size of the hand-to-hand combat collider, so the player would have to be closer to the ship before switching to hand-to-hand combat. This makes it possible for the player to be able to jump onto the enemy ship every time, instead of being too far away.

My last assigned card was making the player ship collide with the enemy ship, instead of driving through. This had a larger impact than I had anticipated. I had to add a rigidbody to the player ship so that the collisions would register. I made sure to lock the ship’s X and Y rotation, as well as the ship’s Y position. I had to change the ship control script to move the rigidbody, rather than the game object itself. This then caused the player to fall through the mesh collider that was being used previously, so I had to add box colliders around all the areas that the player would touch. I had to make sure that I got the curve of the ship to be well represented by the colliders. Then, I had to add box colliders to each enemy ship. The rigidbody also caused the player ship to be pushed by the cannonballs. This felt awkward, so I had to fix it. I achieved this by changing the enemy cannonballs to triggers and having the player health script handle most of the cannonball’s functionality.

Seven Seas to Glory - Sprint Blog 5

Sprint 5

My goal for Sprint 5 was to implement everything that was created in Sprint 4 in a way that works with the rest of the elements of the game.

I started the sprint by making the ship’s movement more representative of a real pirate ship. The ship controller would previously be disabled whenever the player was not driving the ship. I changed it so that the ship script stays enabled, but only takes in the player’s input when they are driving the ship. This allowed for the ship’s rotation to be consistent in all modes, as well as made the ship’s momentum continue when the player was in cannon mode. To further enhance the feeling of driving the ship, I made the ship accelerate faster than it decelerates. I also ensured that the ship stopped its momentum completely any time the player was in character mode. Unfortunately, this caused an issue with the ship cannons only firing along the world z-axis, instead of the local z-axis. This problem had to be pushed to the next sprint, despite my teammate and me trying to fix it for a very long time.

Most of my sprint was dedicated to creating the shop system. I began by making the UI screen for the shop. I exported all the visuals for the shop separately, like the background, shop sign, item box, etc. This allowed for the screen to be properly adjusted to any screen type, as well as allow for reconfiguration of the screen so more items can be added to the shop in the future. I also made a description panel that explained what the different items did, which follows the mouse when it’s hovering over the corresponding item. This kept the screen from being too cluttered with words, while still giving the player the opportunity to learn about the items in the shop. I also made it so the shop creates a gray overlay over the rest of the screen, except for the inventory. I wanted the player to be able to use the inventory as a reference to what they had currently rather than create a different UI element for that.

After completing all of the necessary UI components and the script for the description panel, I then allowed the player to enter the shop screen when they went near the shop. Since the shop wasn’t completed at this point in the sprint, I used a block to represent the shop and I made the colliders prefabs for when the shop gets placed in the scene. I used the popup UI script that I made in a previous sprint, so the player knows that they are able to interact with the shop when they enter a specific vicinity. I then made another trigger collider that registers in the game canvas script which causes the shop UI to appear when the player presses E. The game also enters a pause state when the shop UI is open, so the player can’t get unexpectedly attacked.

In order to finish the shop feature, I had to create the script for buying the items. I made each item spot a button to make this step in the process easier. I created a script that’s attached to the shop panel which handles the process of adding and subtracting values from variables in the player class. I made a separate function to handle the comparisons between the item price and the amount of money the player had, and then display that the amount the player spent was subtracted or that the player didn’t have enough money. I wanted the player to have more of an obvious indication that their actions did something, rather than just the visual they get from the inventory.

When the shop feature was completed, I was able to move on to updating the save file to include the ship’s position, the player’s money, and the player’s items. Since I already made the logic for the save file earlier, it was easy to reinstate the save button and ensure that the save and load system still worked as it did previously. After verifying that it still worked, I added the new values that needed to be saved. I added the bullet, exploding cannonball, freezing cannonball, and money values to the save files, as well as the position and rotation of the ship. I removed the player position from the previous sprint because I thought it would be better to save the ship’s location and spawn the player on a given point on the ship instead. This would avoid the issue of the player not remembering where their ship was once the islands were placed in the scene. I also didn’t save the player’s health because the player’s health regenerates over time, which makes saving the health not make much sense. I was having quite a bit of issues with saving and loading the ship’s rotation. For a while, the ship would automatically load with a rotation of (0,0,0) no matter what the values were set to beforehand. At first, I was storing the Euler angles of the ship, and my professor said that using Euler angles instead of a quaternion could be causing the issue. After switching to storing the quaternion values, the issue persisted. I was able to discover that the ship controller’s late update function was causing the issue. I fixed it by setting the ship’s desired rotation to the stored value on startup.

Lastly, I limited the amount of bullets the player has. This gave more of a strategic use for the gun, rather than making it a primary weapon of choice. This was a very simple thing to implement.