top of page
  • yhawhwa

Project Light: QA Week 2 + Showcase [11/27 ~ 12/11]

Updated: Feb 5, 2023

Studio Meeting - Postmortem

  • Studio Meeting: For this meeting, we discussed multiple topics and gave opinions on how the studio did. Most comments are on how this studio cycle lacks communication between departments and wishes there were more in-person sessions.

  • Department Meeting: The department also reflected on how we felt about the project. We are all really happy with how it turned out. Most concerns are on the tough learning curve new members must go through because this is a 2-semester project. Other concerns revolve around the communications about departments (again).

Postmortem and Reflections

I felt the studio did a really good job making a very complex game come to real life. However, I feel there's so much more to be done, and I wish I could continue working on this game. If I were to continue to work on it, I would focus on the storyline and add a ton of encounters that branches out as a tree instead of just going in a straight line.


I also have some comments on the studio itself. I have to say, this studio experience wasn't what I expected. Before joining the studio, I imagined the studio to be something similar to EECS 494's final project, but on a more extended period. I loved the working atmosphere where everyone put in their maximum effort and moved quickly through the production cycle. However, this production cycle felt nothing like that. Although I can feel the leads pouring their hearts out to make them the game, some of the programmers I've worked with seem to be lacking behind. This is entirely understandable because WolverineSoft Studio, to many others, is just another extracurricular activity. I think this could be solved by more in-person meetings and assigning tasks to a squad (instead of individuals).


Despite my little complaints, I had a great experience producing a game with WolverineSoft Studio and will apply for another production cycle next semester. I'll also encourage everyone interested in game development to join the studio. I got so many valuable experiences out of it.


Bug Fixing + Optimization + Polish


Fixed Weapon's Position and Rotation

Initially, the weapons' position and rotation seemed to be randomly generated. (Yes, pointing at the player ship) This was understandable because we updated the ship's layout, so it went from only 5 rooms to more than 10 rooms and added new art assets to the game. To fix this bug, I changed the way the positions are calculated. Instead of calculating the positions in runtime (which proved hard and finicky), I added empty game objects as spawn points and ensured those spawn points were set correctly around each ship layout. To fix the rotation, I went through all the art assets and made sure all their rotation matched up (points to the right), redefining the center to account for small offset differences between each weapon's art, and rescaling each weapon, so they look roughly the same. After that, each weapon is perfectly lined-up and always faces the right way.


Added New Weapon Art

A lot of the weapon art was not implemented into the game then, and a lot of the weapon art in the game is just wrong. I checked each weapon individually and assigned the correct sprite for the weapon and its corresponding projectile.


Made "Buy in Cost" Persist Across Scenes

One of the programmers added a "save" feature for the crews in the game. This new feature, however, completely broke the refund system. The crew data is completely wiped out and replaced by new crew data. The new crew's data is reconstructed by gathering information from crew game objects. This is problematic because some crew data was not stored in the game object (and does not need to be), so some data are completely lost between scenes. I rewrote the save function to no longer wipe out the old data but update it.


Improved Tile Selection

Due to the new crew hit-box (new art), selecting tiles during the ship-building phase to place the crew became pretty tricky. This was caused by the crew detecting non-placable tiles. I constrained the detection algorithm only to detect valid tiles, which fixed the problem.


Playtests


Showcase


Blog Post


Timesheet

Task

Time Spent (hours)

Studio Meeting

2.5

Postmortem + Reflection

2

Bug Fixing

5.5

Playtests

2

Showcase

2

Blog Post

1


3 views0 comments

Comments


bottom of page