Studio Meeting - Sprint 2 Week 3
Studio Meeting: Playtests and Working Session! This is our last sprint two meeting. The next meeting will be in-person.
Project Meeting:
Scope Change:
Why? Need a complete game. We want it to be well-polished and balanced.
Removing sea monsters, all enemies will be submarines.
4 encounters instead of 5. More engaging, avoid creating extra bugs.
Narrative Update:
Tutorial --> Encounter 2 (Pirates) --> Encounter 3 (Militia) --> Encounter 4 (Organized Crime)
Squad Meeting: Playtested. Lots and lots of bugs.
Studio Meeting - Sprint 3 Week 1
Studio Meeting:
Industry playtest at 11/1 Tuesday 6:30 PM
Industry playtest at 11/4 Thursday 8:30 PM
Case Study Pitches opened!
Squad Meeting: Playtested. This build has by far the least bugs, so we were able to get to a lot of the design questions. The biggest take away is that menus and messaging has a lot of work to do.
Active Item Window
The active item window is a part of the Ship-Building Phase, where the active system on the ship is displayed. It took a while to get the UI right since I needed to spawn the content in runtime. In the end, I used the grid layout component and Unity's scroll view to get the UI right. Then, I began implementing the functionality. I used Pub-Sub events to detect updates on the ship's layout (install/uninstall systems). The active item window's manager will read the player's ship data and display the active system.
Here is the result:
Ship-Building Polishing
As all of the features in the Ship-Building Phase are ready (and refactored). I took a deep dive to optimize it. There are a couple of things that I found that can be fixed: add constraints, add system/crew swap functionality, and optimize the code.
Task 1: Add Constraints to Non-System Rooms
New rooms were added after the Ship-Building refactor. This causes problems because some of these rooms are not system rooms (Ex. Ladder Room) and should not be able to house systems. Also, our gameplay went from a top-down view of the ship to a sideway view of the ship, which meant the crews should not be able to be placed on "non-floor" tiles. For these reasons, I made the tile detection system only sensitive to system rooms/floor tiles and added logic to send the system/crew back to its original state if the player dropped them onto an invalid tile.
Task 2: System Swaps and Crew Swaps
Originally, if the player places a system/crew onto another system/crew, the system/crew occupying the space would be sent into the inventory. It felt a bit counterintuitive to me. The most natural behavior should be the two systems/crews swapping rooms/tiles.
This was not easy to implement at all. It adds another logic to an already complex system, and unfortunately, the system I built was not compatible with this. From this experience, I learned the importance of keeping invariants. Essentially, the system/crew needs to be uninstalled whenever it is dragged from the ship so that it can be installed in another room when needed. After an hour and a half of code refactoring and adding the new logic, I finally got the swaps to work!
Task 3: Optimization
Reduced function calls (lock system): Shop items detects and update its state in update function calls, which means it is triggered every frame. This eats up a lot of computation problem because it might be running some costly operations (install/uninstall onto the ship). I added locks to the conditions so the functions are called at most one time at each state. This greatly reduced the amount of functions invoked in gameplay.
Crew Logic: The original crew logic was weird in that, when loading the crews from data, their names are changed. This is because new crews are spawned. However, in a player's perspective, those crew should be the original crews they bought. I fixed this by adding an extra name field in the crew's data structure. The "new" crew's name will then be replaced by it when the system spawns them in.
Better system/crew counting system: The original counting system was bugged in some edge cases. Since the new ship building system supports invalid placement, while still invoking a function call, I need to add a condition to system and crew's counting system. This way the system/crew count does not appear to be more than the actual value.
Combat UI Refactoring
Task 1: Refactor UI
Wireframe of the new combat UI. Added a system display and a passive abilities display. Also moved the enemy's view port from side-by-side to customizable (can be moved anywhere). Here's the new combat UI:

Task 2: Enemy Viewport
This was the hardest part of Combat UI refactoring. In the old layout, enemy's viewport is to the right of the player's viewport. This was easy to do, because it matches the enemy's scene's position. We can just use another camera to show it. This also means the player can directly interact with it without much problem. However, the new UI design requires the enemy ship to be on top (and to the right) of the player ship. We no longer can use the camera's display, since the relative position will be wrong. To maintain the scene position of the enemy ship, I decided to use a raw image to display the content of enemy's camera. The true position of camera on scene is shown below (Figure 1). The raw image is just a UI component so it can be place anywhere on screen.
Now to the hard part, the player need to somehow interact with the raw image (to target the enemy ship). I need to create an illusion of player can click on tiles of the enemy ship. I did this by mapping the location in the viewport to the actual location on the scene. In other words, a virtual cursor will teleport a location on scene that correspond the actual cursor's position in the raw image. This was extremely hard to get, but after a few hours of debugging, I finally got it right! Code and the result is show down below. (Figure 2).

Figure 1. Code snippet of the cursor/virtual cursor translation.

Figure 2. Picture of the cursor (green arrow) vs. virtual cursor (red dot) on screen.
Shops for Encounters + Inventory System
These two task was the final feature add I did during these two weeks. I am responsible for setting up the shops for the 5 encounters that we have and implement the data storing part of the Inventory System. (Foreshadow: I ended up on a huge tangent to create a tool to debug in builds)
Setting up shops is a really easy job, since we already have a pretty well built system for that. I modified the system a bit so programmers don't have to drag a prefab to assign each shop content. I used a enum class instead.
Inventory system should be a easy task because it was very similar to data saving of the ship layout. The only difference is we don't need the system/crew struct to store data, all we need was a list of system and crew types. Everything went really well in the editor, but when I tried it on a build, it was not saving anything! What's worse? I cannot replicate it in Unity Editor and I cannot view the console in the build! For this reason, I decided to add an in-game console command that generates a log file of the debug logs. After few hours of debugging using the log file, I found the bug is caused by a race condition, since the start function's calling order is not the same in editor and in build.
Bug Fixing: Fixed Almost 20 Bugs
Working Session
Blog Post
Timesheet
Task | Time Spent (hours) |
Studio Meeting | 4 |
Active Item Window | 3 |
Ship-Building Polishing | 4 |
Combat UI Refactoring | 6 |
Bug Fixing | 3 |
Shops for Encounters + Inventory System | 2 |
Work Session | 4 |
Blog Post | 4 |
Comments