top of page
yhawhwa

Project Light: Sprint 3 Week 1&2 [10/30 ~ 11/13]

Studio Meeting - Sprint 3 Week 2

  • Studio Meeting: Studio-wide announcements.

  • Project Meeting: Went through what the team had done for the past week and assigned new tasks for the next.

Studio Meeting - Sprint 4 Week 1

  • Studio Meeting:

    • Matt Radar - 11/13 5:00 pm

    • Winter Project Pitches Due: Nov 18th

    • Winter Cycle Applications

    • Work Session 11/18 6-10 pm in BBB1690

  • Project Meeting:

    • Playtested the game. It was very buggy because we added a bunch of features this week. The team quickly went through what the team had done for the past week and assigned new tasks for the next.

Tooltip System

The tooltip system took up most of my time for the two-week production period. It took so long because I had to build two trigger systems connecting to WoverineSoft's tooltip system. One trigger is for game objects, and the other is for UI elements. Furthermore, I had to refactor WolverineSoft's tooltip system to support a delayed trigger system and a more customizable display that can house different images, text, sliders, and even buttons. The last bit of the work is to follow the design's documentation and implement various tooltip displays.

Task 1: Game Object + UI Trigger System

The original implementation of WolverineSoft's UI is insufficient for our game because it uses the IPointerEnterHandler and IPointerExitHandler, which does not work on a game object. At the same time, the design team's documentation also required game objects to be triggers for tooltips.

To solve this problem, I first had to build a "Pointer Enter" and "Pointer Exit" detection system for game objects. I used a "virtual mouse" game object with a collider component attached to it. The virtual mouse will store everything within its collider into a list of game objects. The virtual mouse will then broadcast a "Hover Event." Every game object subscribed to this event can determine its action by checking the gameobject list. "IPointerEnterHandler" is called if that game object is within the list, and "IPointerExitHandler" is called if that game object is not in the list. I attached the code snippets down below to better showcase this functionality.

With the completion of the game object trigger system, I moved on to unifying the trigger system. I made a single event broadcaster component that takes in UI trigger and game object trigger as inputs, and a trigger manager wakes up and manages the tooltip display and motion.

Figure 1. This is the virtual cursor on the scene. It has a tiny collider.

Figure 2. This code snippet keeps track of what game objects the virtual cursor is hovered on. A "HoverOnObject" event is published to send subscribers the list of "contacting objects."

Figure 3. An example of a subscriber script. If the subscriber is within the "contact object" list, the cursor hovers over it. If the subscriber is not on the list, then the cursor is no longer on it.

Figures 4 and 5. The subscriber will publish a "TooltipTriggerEvent" if the cursor is detected hovering above it (from previous logic). "HandleAction" in Tooltip.cs will get a reference of the tooltip game object and gain access to it.


Task 2: Delayed Trigger

The design team requested the delayed trigger functionality, so the player can decide whether to see the tooltip by hovering over an icon or game object for some time. The delayed trigger is built into the subscriber's class. The subscriber does not publish a tooltip trigger event immediately, it sets a flag. The update function will then be responsible for keeping track of time and calling the tooltip trigger event once the time is up.

Figure 6. The update function in the tooltip trigger script.

Task 3: Customizable Display

We arrived at the last step before the tooltip system was completed. The original WolverinSoft tooltip system only supports a title and text. However, the design and art team concluded to use icons in the tooltip system to convey a more vital message. This was not an easy task since I had to throw away most of our things and build a brand new one. It took two iterations until I landed on the final system.

In the first iteration, I turned to Unity's UI Toolkit, which allowed programmers to build a UI template that could be configured in the inspector. Although the solution was very elegant, it had two problems. First, this is new to me, and I could not change the UI's position during runtime. Secondly, adding a new system may confuse the other subteams since they are also used to the old UI system. After careful consideration, I concluded discarding hours of work to save myself and the team more hours of work.

The second and final iteration uses a much less elegant solution than the first one. Programmers have to create a template for the tooltip alongside a component that initializes its values of it in every tooltip trigger. When a tooltip trigger event happens, it is responsible for passing the template object to the trigger manager and allowing the trigger manager to display it. After trying this method on "weapons." I created a template for every system in the game. (That took a while...)

Figure 7. Example of tooltip trigger + tooltip template

Result



Playtest

Industry Playtests

In these two weeks, there is a couple of industry playtests! Through the playtests, we can better understand what we must work on to improve our game. Below is a summary of the feedback we got from the industry playtests:

  • Before Feature Add

    • A couple of misspelled words in the tutorial.

    • They liked the crew icon

    • Ship Upgrades is broken (unfunctional)

    • The inventory was a bit confusing. It is tricky because inventory is functional but not so useful.

    • The highlight was not clear enough

    • Confused about the black bars ("doors").

    • Moving crew members is confusing with paused screen up

    • Death crew is magically revived in the next shop

    • The tutorial is a lot upfront

  • After Feature Add

    • UI is overlapping

    • Permanent Text in the description window

    • Liked the filter

    • Shop's highlight does not change

    • Hard to tell the "bounds" of the room (highlight placeable tiles)

    • The settings button was not apparent

    • Liked the tooltip

    • Lost when in combat. Felt like just clicking buttons and then winning or losing the game. Sonar helps with this. (have to bring it in as a part of the tutorial system)

    • Confused about the "hit or miss" chances.


Bug Fixing


Blog Post


Timesheet

Task

Time Spent (hours)

Studio Meeting

4

Tooltip System

12

Playtests

4

Bug Fixing

6

Blog Post

4


7 views0 comments

Comentários


bottom of page