Studio Meeting (2 hours)
This week's meeting is the studio's last sprint 1 meeting. We did a playtest on the game and discussed future work.
Studio Meeting: Cameron went through the logistics and some spotlights.
Project Meeting: We playtested the game for 30 minutes and reported all the bugs to Jira.
Squad Meeting: The design team covered the tooltip system and the specific tooltips that must be implemented into the game. The design team also went through the refactoring of the ship-building phase and combat phase. My task was to refactor the ship-building phase and discuss with the programming team the feasibility of drag and drop.
Programming Team Meeting: We reviewed what we did for the week and what we will do next week. I brought up the drag-and-drop system and got a thumbs-up to do it.
Bug Fixes (5.5 hours)
Bug 1: Room disappearing when system type exceeds max count: This was a tricky bug to fix. This bug was found when a player tried to buy more than one Medbay, and the room in the system disappeared. I looked everywhere to find where incorrect delete may have happened, or somehow the game object gets disabled. Turns out it is not deleted nor disabled. During git's version control, the "Invalid Color" field in "RoomHighlight.cs" has somehow been changed to transparent. I changed the color back and fixed the bug.
Bug 2: Replaced system gets overwritten by the original system: The data storing system is flawed. Whenever a system swap happens, new data is appended to the data list. This means during the combat phase, the first instance of the data (original system before swap) is read in. I added a condition always to replace existing data (for the same room) and fixed this bug.
Bug 3: Drone's type is incorrect: This was an easy fix. The design team limited the amount of "Shield Type" systems to 1. "Shield Type" systems include Shield, Deflection Shield, Drone 1, and Drone 2. The drone's type was not set correctly, so players were able to add 3 "Shield Type" systems onto the ship. I just have to change Drone's type to "Shield" and fix the bug.
Bug 4: Ship Building Reset Problem: "ShipBuildingManager.cs" uses a singleton architect and will not be destroyed across scenes. This caused an issue when the player restarted the game. This is because some serialzefield requires objects in the "ShipBuildingPhase" scene. I cleared the dependencies of these objects and fixed the bug.
Bug 5: Should not stop the player from buying system even when the ship is full: Since the design team added the new replaceable system, it no longer makes sense for us to detect whether the ship is full of systems or not. This is because even when the ship is filled, the player can still choose a system to swap out. I removed the "Ship Filled" constraint and fixed this bug.
Bug 6: Cancel Button does not work for crew members: While implementing the "Replaceable System" feature, the design team only asked me to rework the system for ship systems. However, it gets quite confusing when the player can cancel the purchase of a system but not a crew member. For this reason, I made the crew replaceable (cancel button work on the crew).
Ship Building Phase Documentation (4 hours)
I continued with my work from the previous week to build a ship-building phase guide for the programming team. The documentation was finally completed this week. However, I will soon work on this task since the ship-building phase was refactored. That being said, I've attached the documentation down below.
THE SHIP BUILDING PHASE DOCUMENTATION:
Ship Building Phase Refactoring (15 hours)
This was extremely heavy work. I am really surprised that I could finish it within one week. The design team changed how ship-building worked and added a new system! We went from a stateful pop-up shop where the player can purchase an item and select a room/tile to place the system to a stateless stationary shop where the player can drag items around and place them anywhere (literally).
Task 1: Ship Building Layout Overhaul
This was the easiest part. I just have to rework the user interface to fit the new ship-building phase. I attached a comparison down below (Figures 1 & 2).
Figure 1. The Original Ship-Building Phase UI
Figure 2. NEW Ship-Building Phase UI. The ship is spawned in during runtime.
Task 2: Drag-and-Drop
I am super excited about this feature. I made a Lab scene to nail the drag-and-drop system first. (I cut down this feature a bit in the final implementation). I want the object to have ragdoll physics when dragged. In the end, I was able to use "PlayerController.cs" (a super awesome script that we wrote during the summer) and the "Spring Joint" component to get the result I wanted. The results are should in the video below!
Task 3: Inventory System
The design team added a new system into Ship-Building Phase - Inventory System! Players now not only can drag bought items onto the ship but also can choose to store them in the inventory system for later use. At this phase, I just built a simple data storage system for the items purchased. How players interact with this system will be explained in Task 4. The data storage system is very similar to the ship's, systems and crews are stored as a struct in a list in "PlayerData.cs."
Task 4: REFACTOR
Finally, this is the bulk of the work. Since the draggable items can transfer data, we no longer need communications between the shop buttons and the rest of the scripts. For this reason, I cut down on many unnecessary scripts and made the ship-building phase so much simpler. There are three main parts (trinity): Shop, Ship, and Inventory. Each part keeps certain invariants. Shop purchases and spawn items when dragged and refund items when released. Ship uninstall items when dragged and install them when released (this part gets complicated). Inventory spawn items when dragged and store items when released. There is more complication in the ship part since there are certain constraints and logic. For example, the amount of systems with a certain type is limited (e.i. 2 Weapons Only) and swapping systems. Luckily I tackled each problem individually and got the system to work together.
Task 5: Descriptions
The "final" task (I thought it was the final) was to create a description system that displays what each shop item does in the middle. I did this with a simple Pub-Sub event that updates the UI whenever the mouse hovers over to the shop button on the item gameobject. Descriptions are stored in the item prefab.
Task 6: Resolve Merge Conflict
Everything worked so well until I tried to pull from the master branch. Since the change was so huge, merge conflicts are not avoidable. However, the situation escalated when I accidentally reverted my branch. Although I could cherry-pick my branch back, git marks deleted work as valid, and there's a lot of work loss during this process. So solve this, I had to clone the master and merge my changes into it manually. You would think this was the end. NOPE. As more pull requests merged into the master, I got even more merge conflicts to solve. At the very end, I was able to get my changes in, but because I spent so much time on this, there are a couple of things that I did not work on. This will be discussed in the next section - future work.
Future Work
After refactoring the ship-building phase, there is still a bit of detail that I did not get to. I will get to the following in the future:
Work on crew/system constraints on newly added features (sideway view, ladder, and door)
Active System UI
Better system replacement logic
Fix Jacky's "Update Shop" tool
Result
Not going to say too much, just enjoy the video!
Blog Post (2 hours)
Timesheet
Task | Time Spent (hours) |
Studio Meeting | 2 |
Bug Squashing | 5.5 |
Documentation: Ship-Building Phase | 4 |
Ship-Building Phase Refactor | 15 |
Blog Post | 4 |
Kommentare