Seven Seas to Glory - Sprint Blog 2

Sprint 2

Now that Sprint 2 is complete, I’m even more excited about the final product than I was when we started. Working in a larger group has been great because we’ve been able to move much quicker. The core loop prototype still has some issues, but for the most part, it’s a great place to be in the timeframe we have.

My goal for Sprint 2 was to complete the core loop prototype, as well as add temporary in-game elements to help guide the player in the game.

This sprint started with me correcting the mistake I made in the last sprint, and I created a design document. While I tried to flesh out my full vision, I knew I didn’t have the time to put the whole sprint into creating the design document. I decided that the best course of action was for me to expand on features that are more important for this sprint and the next sprint. In a class setting, it’s really difficult to balance pre-production with production because I still need to be able to complete work on the game itself. There was also the added pressure of the core loop prototype being due at the end of the sprint, and I had to consider which priority was higher. The core loop prototype won. I do plan to flesh out more of the game design doc as soon as we kick off the next sprint.

After working on the document, I wrote the code for switching between the character and the ship. The goal was to have the character walk up to the wheel, press E, and then the camera would change to the ship view along with the controls switching to the ship controller. Conversely, if the player is driving the ship and presses E, they go back to the character. I had to think a lot about how to store the camera’s location for each mode, and I came up with the idea to have empty game objects as placeholders for where the camera is meant to be. Not only does this help with accurately moving the camera, but if at any point we want to adjust the camera view, we can move the game object instead of changing numbers in the script.

I moved on to the cannon and ship switch. When the player is driving the ship and presses shift, they switch to a different view from behind the cannon and can shoot the cannon. I did a similar thing for the camera view by using empty game objects. This is especially a useful method for this situation because the ship is planned to have upgrades for more cannons, so the camera view may shift in-game.

I then needed to write the script for switching sides when in the cannon. I created a bool called Left Cannon that was true when the player was in the left cannon and false when not. This way, I was able to make it so that the last side the player was firing the cannon on was the side they automatically went to when switching between the cannon and ship. This was an important aspect, as it would be frustrating for the player to constantly have to press E if they were in the middle of a battle with a ship on the opposite side. I was also thinking about how a player would play during a cannon battle. Most of the time, the ship you are engaging in battle with will stay on the same side for the whole battle.

After completing all the elements for switching between the different modes, I moved on to creating a save data script. This game has stats and collectibles involved, so a player needs to be able to save what they’ve earned and continue where they left off. Even though this wasn’t necessary for the core loop prototype, I wanted to get this done as soon as possible because I wanted as few save elements as possible when creating the base of the scripts. Part of the way to save data is by creating a script that takes in all the elements that you want to save. Adding to that script as we added more features that needed to be stored was a better way to ensure that we saved all the data needed for the game, rather than waiting until the end and possibly missing something.

Now that I completed the cards that were necessary for the core loop prototype and the save system, I needed to make a Google form for playtesting. Since the forms I created were for other developers and designers, I looked up an article about making a form for playtesters outside of the major. The most important things that I learned from that were using terminology that the average player would know and having a specific thing that you are testing for. Considering this is a core loop prototype, I focused on asking questions about the fun and controls.

I went back to development work after I was done with the Google form, and I created the aiming mechanic for the cannon. Although this was the card that I had left over from the last sprint, I haven’t started to work on it yet, and I wanted to start working on things that were absolutely necessary for the core loop prototype first. I made it so the player could only aim up and down because I wanted them to have to time their shot with the forward momentum of the ship. I restricted the amount a player could aim up or down, and the height affects the distance the cannonball can shoot.

At this point, the sprint was almost over and the features with added controls were complete, so I decided it was time for me to update the control screen based on the added features. I didn’t want controls that weren’t implemented yet to be on the screen because I didn’t want playtesters for the core loop to get confused by controls that didn’t work. I decided it was best to wait on this card until later, so I could update the controls accurately based on what was actually complete, not just on what was planned to be complete.

Lastly, I created a temporary tutorial text that would help teach the playtesters what they can do. This will eventually be replaced with pop-up prompts, but there wasn’t enough time left in the sprint to implement that at the time.