Studio Meeting (2 hours)
This week's meeting is the studio's first production meeting.
Studio Meeting: Quickly went through logistics. Answered some FAQs and went through a tutorial on how to use Jira.
Project Meeting: Introduced a new design decision: change the player's view from top-down to sideways. This new design allows us to have ladders and doors and also helps with messaging (flooding). Went through the production timeline and assigned squads. I was assigned to "Menus and Messaging." We are also introduced to TBIQs, an excellent way for task breakdown. Here are the 4 components of TBIQs: design walkthrough, what we have, what we do not have, and future considerations.
Squad Meeting: Squad meeting follows TBIQs. The design team first walked through what they were looking for in menus and messaging. The main things that we need are a good tooltip system and in-game indicators. Then each department goes through what we have and don't have. Ultimately, we concluded that the design and art teams must work together to create a specific task for sound and programming. While the design team does that, the programming team will work on enhancing the tooltip system.
Bug Fix - Tooltip Overflow (3 hours)
I need to fix the tooltip overflow (described below) for this task. Most of my time went into getting the tooltip's border, getting the canvas's border, and coming up with a logic that forces the tooltip to stay within the canvas's border.
Problem - The tooltip system from WolverineSoft General Library does not ensure the tooltip dialog stays on the screen. An example is attached below (figure 1).
Solution - I came up with the idea of calculating the tooltip's border and the canvas's border and making sure the top border of the tooltip is within the canvas's top border, the right border is within the canvas's right border ... etc. If the tooltip's border is not within the canvas's border, an offset is added to the tooltip's spawn position to force it back into the screen. The code (figure 2) and result (figure 3) are presented below.
Figure 1. Tooltip dialog overflowing off of the screen
Figure 2. Code that fixed this problem
Figure 3. Gif that showcases the result; there's no more overflow
Drone System (6 hours)
Task Description
Drone System is a modified version of the shield. The drone room can be manned, and once it is fully charged, a drone will spawn—different types of drone target different enemy projectiles and tries to snipe down enemy projectiles with one shot. If the drone room is damaged while charging, charging progress is set back to zero.
Drone 1: target shield-piercing weapons
Can only target one weapon at a time
Manning speed: moderate
Target weapon automatically once manned
Will only shoot down weapon if entered pass shield layer position
Drone 2: target non-shield piercing weapons
Can only target one weapon at a time
Manning speed: moderate
Target weapon automatically once manned
Will priority the non-shield piercing weapon that is closest to ship
Will only shoot down weapon if entered pass shield layer position
Task Breakdown
Step 1: Drone Projectile
Projectiles are easy to code. Projectile simply flies forward and destroys enemy projectile when it collides with it. I only write a single script, "DroneProjectile.cs," for both projectiles that target shield penetrating weapons and non-shield penetrating weapons then setting the target type in the projectile's prefab. In the end, I added a destroy time variable to destroy the drone projectile after a little while, so it does not fly endlessly into the void.
Step 2: Drone
Drones are much more complex than Drone Projectile. It has to orbit the ship, detect a specific enemy projectile and shoot it down in one shot (this part was the worst).
I focus on the orbiting movement first. I achieved the orbiting movement by continuously updating an angle variable and calculating the drone's position by adding the ship's position to the x and y component offset I get from the angle variable and the radius of the orbit (x = sin(angle) * Radius, y = cos(angle) * Radius) (figure 4). Although it seemed simple when I wrote it out, it took a while for me to come up with this.
To detect the type of enemy projectile, I use a trigger and add a boolean variable in "ProjectileController" that returns whether the projectile is shield penetrating or not. The drone can then get the type of enemy projectile as soon as it enters the trigger.
Last but not least, the drone has to shoot down the enemy projectile with a single shot. This turns out to be hard to get. I tried many methods: adding a predicting constant, so the drone shoots a little forward, spraying a bullet, making the bullet go extremely fast..., but none of it makes me feel good about the implementation. So, I decided to work on other parts and return to fix this later (next part).
Figure 4. My code implementation for the orbital movement
Step 3: Drone Room SO + Drone Room Manager
Drone Room Scriptable Object is for storing data (Important to override methods for the UI to work!), and the Done Room Manager manages the manning process of the room and, of course, drone spawning. There's not much to talk about here since all of these are identical to other systems. The only thing that I had to add is when the room is damaged, I need to set the charged % to 0.
Step 4: Put Everything Together
To put everything together, I have to create "Drone1SO" and "Drone2SO," which represent the drone 1 system and drone 2 system and add them to the default ship layout. It was pretty easy because the "ShipBuilder.cs" (I built that) and architecture for a system to connect to a room are so great!
Step 5: Put Drone System in Shop
For the last step, I had to create new icons and shop buttons for the new systems. I tested it, and everything worked out perfectly. It DEFINITELY did not take 10 tries because I kept forgetting about all the little configurations I had to do.
Drone System Optimization (2 hours)
As mentioned above, the drone's shooting system is not the easiest to implement. After 2 hours of thinking and trying out different things (keep in mind, the drone is also moving), this is what I figured out (figure 5, 6):
Calculate the enemy projectile's trajectory.
Get the target position where the trajectory has to be shut down (it has to be within the shield range)
Calculate the speed of the drone's projectile by dividing the distance between the spawning position and the target position by the time the enemy projectile is going to take to travel to the target position.
Repeat the above process until the estimated drone projectile's speed reaches the minimum velocity.
Face the target position and shoot.
Figure 5. My code implementation of the speed estimating process
Figure 6. My code implementation of the 100% accuracy shot
In the middle of implementation, I had a lot of trouble getting the velocity to match up since the enemy projectile was moved by position, and the drone projectile was moved by velocity. At last, to sync up, I changed the movement of the drone projectile to be moved by position. At last. Finally. It can shoot down enemy projectiles with 100% accuracy! (figure 7)
Figure 7. Perfect Drone Shots
Comments