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.

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.

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.

Our Last Hope (Is Some Kid) - Blog Post Postmortem

 Postmortem

Now that the last sprint is completed, I feel quite satisfied with what was achieved given the time frame we had. There were a lot of successful things about the prototype and a lot of things that could have become successful if there was more time to do so. It was a huge learning experience to act as a lead, even if it was just in a small team of three, and I’m very happy with having the opportunity to do so. I very much felt like my team worked well together, and that is possibly the most important and successful part of making any game or prototype.

 Although the stress of turning in a working prototype caused everything to feel like it was crashing down, we managed to pull it together and turn in a successful prototype. Our main movement mechanic, grappling, turned out to be flawless. We noticed far too late that there was a rare occurrence where grappling would cause Kevin to freeze, and the only way to fix it was starting over. My teammate was able to find the problem and fix it, making the most important feature work perfectly. 

 We also had an issue with having Kevin take damage while the player was in hand mode, and having the old Kevin despawn if the player died from it. It was essentially a duplication bug, but it was really important to fix because the old Kevin would keep getting hit if it was in the line of a zombie’s movement. This caused the player to die shortly after respawning. I was eventually able to fix it by making a list of all the duplicated Kevin’s, and destroying them every time the player would die and go to a checkpoint.

With all the successes that can be considered for a five sprint prototype, there were some things that could have been grea
tly improved if more time was given. Luckily, none of the bugs are game breaking. There was one bug that existed for a while, and no matter how much we tried to fix it, we simply couldn’t figure out how. There are times when going back to Kevin mode when in hand mode would cause Kevin to disappear, causing the player to remain in hand mode with no Kevin to go back to. Kevin would come back if the player pressed E a couple of times, or if the player restarted from the last checkpoint. We tried to figure out what caused it, but we could never find any true way to make it occur. This made testing whether it's gone or not really difficult. We ended up adding UI that said “Kevin gone? Push E” as a last resort for the final playtest day.

Since a lot of the focus had to be on making sure the movement mechanics worked, some features that were worked on didn’t make it into the final prototype, and secondary features, such as weapons and combat, weren’t as polished. One thing that would have been nice to be able to fix was having only certain weapons be wielded by the hand, instead of all of them. I originally didn’t want the hand to be able to use the bat or ball, but making the distinction would have taken two more cards worth of work. There would have been a lot of factors to take into account, like going into hand mode when a weapon the hand can’t wield is already wielded by Kevin or picking up a weapon as the hand and switching back to Kevin with it. Unfortunately, there was not enough time to prioritize that feature.

 As far as using Agile development goes, I did a decent job of working on one card at a time up until the last sprint. Since we were using GitHub, we would never have more than one person using it at once. We all had our own personal projects that were copies of our shared one that we would work on and then push the packages onto GitHub. This wasn’t normally a problem, but since there were so many things to take into account with every new card completed, everyone took a bit more time on the GitHub when pushing their work to make sure it all worked properly and didn’t break anything. I ended up completing cards, but not being able to push the work immediately after because someone else was on the GitHub project. This caused me to move on to the next card before pushing and fully completing the current one. I was greatly feeling the pressure of time running out. Considering the yet to be assigned work I had to look forward to for other classes, I didn’t want to waste whatever precious time I had at the moment doing nothing. I do really like using Agile development but in the last sprint when it’s crunch time it was very hard to do it properly, and I have a lot to learn about how to skillfully do that.

Most of what I would change if I were to do this project again would be relating to Trello and Agile development. This was a very big learning experience for me, not only with using Trello, but also with leading a group in the development of a prototype. While I have been a group leader in other settings, being the lead of a prototype is vastly different. While I knew what needed to be done for the prototype, prioritizing each thing was much more difficult. I always felt like I had two or three cards off when prioritizing the backlog, even though we never missed a deadline for each playtest and the features we needed to have present. I truly believe that if I had prioritized the backlog better, some of the bugs that we still have or felt rushed to fix would have been dealt with much earlier or wouldn’t have occurred at all. The nature of making a game is hard, and things go wrong especially when learning a new system at the same time. I know that there's a lot more room for me to grow, more than likely more than I have mentioned, but the final product that my team and I completed is one that I can say I’m proud of.