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.

Seven Seas to Glory - Sprint Blog 1

Sprint 1

In my process of designing Seven Seas to Glory, I have noticed many differences from other game design classes I have taken. A big difference is the overall goal of the semester, which is to create a complete game, whereas the classes I’ve taken in the past only deal with creating part of a game. There is much more to consider regarding design, scope, and resources. The team that I am working with is also larger than any of the other teams I’ve worked with for a CAGD class, which means it’s very important to keep everyone on the same page for the design of the game. 

My goal for this sprint was to get as many of the main mechanics and models completed as possible so that a prototype would be completed in the next sprint.

I started off this sprint by doing the treatment. It was very exciting to be able to create a treatment for a game that I finally know is meant to be finished, but that also meant that I needed to keep the scope in mind. In other cases, I was aware that the idea wouldn’t fully come to fruition, so I created the treatment as if I had a much larger team and time frame. In this situation, I already had to change my original pitch idea quite a bit once I knew how many people I was going to work with and what each person was capable of doing.

This is where I made my first mistake, of probably more, as a designer. I didn’t create a design document for the game. Since this is the first complete game I am involved in, it didn’t cross my mind to create a design document. I was never involved in a project where there was a specified designer except for creating the prototype in CAGD 370, in which case no one in that class created a design document. I only realized my mistake when the other teams in the class were presenting and the other designers in the class mentioned making one. I plan to make one in Sprint 2, because it’s better late than never.

After the treatment, I moved on to creating a UI/UX wireframe. This was my first time making one, and it was interesting to realize how many different UI screens end up in a game. I ended up with 11 different screens. I created some of the screens, saved games, stats, ship customization, and inventory, knowing that they may not end up being created due to a lack of time; however, I wanted to make the wireframes for them anyway because they were still goal features.

I then gathered some concept art for the modelers in the team. One modeler was working on the ship while the other was working on the cannon and weapons. Since the ship was a main feature of the game, it was important to get it right. I found a ship that looked like it could be changed slightly without changing the hull of the ship, providing an easy way to add visual upgrades such as more cannons for more damage and more sails for more speed. The cannon was also a main feature, but the visual of the cannon wouldn’t ever need to change, so it was easier to find concept art. I got the concept for the view the player would have when aiming and firing the cannon as well. The art style was based on images sent by one of the modelers, and it was something that I liked so much that I wanted those to be the reference for texturing.

After feeling like I was done with the traditional work of a designer, which I wasn’t, I moved on to working on the game itself. I focused on making UI elements, main menu, controls, pause, game over, and health bars, since I already had the image of them in my head from the wireframes. These are also all important UI elements for playtesting since these would allow a player to start and learn the game without any guidance. I started with making the main menu since making a script for that would involve most other UI screens. A different team member will add the art later on. I then created
the controls screen. I made two different types, one that was a scene accessed from the main menu and one that was an inactive canvas that would be activated from the pause menu. I didn’t want the player to switch scenes to view the controls, because that would cause the game scene to reset when going back. I then made the pause screen and the game over screen that both share a script and canvas.

I did have a card for making the cannon aim controls, but I did not complete that because the sprint started on a Tuesday and ended on a Thursday, so it was only about a week and a half sprint instead of a two-week sprint, and I accepted the number of cards for a standard two-week sprint by habit.