top of page

Project Light: Sprint 1 - Week 2 [9/25 ~ 10/2]

yhawhwa

Studio Meeting (2 hours)

This week's meeting is the studio's first production meeting.

  • Studio Meeting: Quickly went through logistics. Went on a progress showcase! Love and appreciate everyone's work! Cameron explained how to report bugs on Jira. To post a bug, we will want to include the description of the bug and HOW TO REPRODUCE it. Cameron also discussed things we need to include in the Blog Post.

  • Project Meeting: We went through the narrative of Project Light. We are in a post-apocalyptic world. Humanity has been forced underwater. We want to transport medicine; however, enemies want to rob us, and we might encounter evil sea monsters. The overall theme will be - Ocean is Evil.

  • Squad Meeting: All of the members in the M&M squad went over what they did this week. The design team made the wireframe of the UI layout in Figma and discussed the next step, the art team produced some narrative artworks. At the end of the meeting, I was tasked to work on the tutorial flow.

More Drone System (4 hours)

Although I've already spent a lot of time on the Drone System, I found a major design flaw in the system. The "intercept-on-line" mechanic only worked because the projectile of the enemy ship always hit straight on. This might not be the case in the future. On top of this, the drone flies in a circle, but the design documentation specified that drones should "fly within the boundaries of the shield (ellipse)." Due to the abovementioned problem, I decided to spend more time making the drone move in an elliptical movement and intercept enemy projectiles on an ellipse.


Task 1: Elliptical Movement

This was the easy part! Since I am using polar coordinates to calculate the movement of the drone, I was able to change the function from x = r*sin(theta) and y =r * cos(theta) to x = a*sin(theta) and y = b cos(theta), where a and b is the length we want in x-axis and y-axis (Figure 1).

Figure 1. Code for drone's elliptical movement. Changed "OrbitRadius" to "OrbitXAxisLength"(a) and "OrbitYAxisLength"(b).


Task 2: Intercept on Ellipse

This was where the majority of the time went. Solving the target position was hard enough, and it turns out that what I did initially was completely wrong. The math that I went through is attached below (Figure 2). To summarize, I initially calculated the interception of an off-centered ellipse and the enemy's trajectory. Still, for some reason, the interception position is correct as long as the enemy's projectile is on the x-axis, but goes haywire when the enemy's projectile starts to have a y-axis component. I've debugged for so long, trying to figure out why, but it was to no avail. At last, I decided to offset the ellipse and the enemy's projectile trajectory to the center and remove the offset (Figure 3). Surprisingly this worked!


Figure 2. The math behind calculating the intercept between the ellipse and line intercept


Figure 3. The code that I wrote to calculate the position of the interception should happen.


Result

Finally! Let's see the result! It is done so well, we can change the ellipse however we want!


New Ship Building Mechanic: Replaceable Systems (6 hours)

After two months, I am finally back in the ship-building phase! It took a lot longer than expected because to implement the new system, I had to refactor many existing systems and redo some of the work due to merge conflicts. The task is to add a cancel purchase option, add indicators, and make the system replaceable.

Task 1: Cancel Purchase

To add the "cancel purchase" option, I have to add another state in the Ship Building State Machine. This state will transition back to the "InShop" state as soon as the player presses the cancel button. I also made a "cancel purchase" a ship-building event. This way, refunding a system becomes a general function that anyone can invoke by publishing a "Cancel Purchase Event." (Note: this refund is different from the refund of systems already placed on the ship)


Task 2: Add Indicators

Indicators are great for guidance. The design team wants to use room highlights to show room availability. For now, the only factor that makes a room unavailable is when the system type on the ship exceeds the max system type count. For now, we only allow 1 Medbay Type (Medbay), 1 Shield Type (Shield, Drone 1, and Drone 2), and 2 Weapon Type (Weapon1, 2, 3, and 4).


To achieve this, I built a type counting system in "ShipBuildingManager.cs." It records the number of each system type on the ship. Each shop button will then check if the system count was maxed. If it is the case, it will publish a "SystemTypeMaxedEvent" so that different parts of the systems can take action accordingly (Ex. rooms with different system type flag themselves as invalid). And of course, I also have to record system placements on the ship so each room knows which system type they currently hold.


Task 3: Make System Replaceable

Once the indicator is ready, we can guide the user to replace existing systems. This enables many indicator mechanics (system upgrades, quick system swaps ... etc.) For the system replace system, I need to add another state into the shipbuilding state machine. I cannot use the code that I had to place the system because, during system swap, I need to display a dialog and also refund the original system. Through lots of bug squishing, the replaceable system, and the feature is finally done.


Ship Building Phase Documentations (2 hours)


Blog Post (2 hours)

4 views0 comments

Recent Posts

See All

Comments


  • Instagram
  • LinkedIn

©2022 by haw-hwa-yang-portfolio. Proudly created with Wix.com

bottom of page