11/28-12/12: Bug Fixes and Next Semester
I’ve had a lot of progress over the past two weeks. Here are my updates:
Tooltip System (1 hour)
After receiving playtesting data, the team realized that people were confused about what tower upgrades did because there were no descriptions. The UI layout didn’t have any space to put this information, so we decided to communicate them through a tooltip. According to the first result on google, a tooltip is a brief, informative message that appears when a user interacts with an element in a graphical user interface. When mousing over tower upgrades, a tooltip with the name and description of the tooltip. This is technology I ported over from Caduceus, so the task was really quick. From there, it was simply about making the tower upgrades set the tooltip when they are hovered over.
Bug Fixes (1 hour)
I spent some time investigating and fixing a very strange bug with the support tower. Basically, the tower placement mechanics work by doing a circle cast at the mouse position with a certain radius specified by the tower. If the cast returns false, the tower can be placed there. The issue is that the cast places the tower at the center of the prefab, not the center of the sprite (you can see a visualization above). This essentially means that the support tower can be placed on top of the path (or at the very least appear to be placed on top of the path). I made the circle cast be at an offset to the spawn point, making the tower placement more accurate to the visuals. This took a long time to actually figure out, but solving it wasn’t too complicated.
Design Changes (2 hours)
I made a few design changes in response to feedback from designers:
Split the third level enemies between the different paths. Levels work by using something called an level config, which specifies which enemies go on which rounds. During preproduction, my team and I created a couple tools to help us deal with level configs. The first is a Level Config Builder, which allows you to build level configs from other level configs and from configurable presets (see below). The second is a Level Config Editor, which allows you a better interface to understand how the level operates and flows.
Added functionality for in-game dialogue before the first round. When the game started, a character would be able to tell something to the player. This wasn’t a difficult change, simply a few lines of code and some extra variables to enable this.
Added a win screen in the final cutscene. This did involve a bit of a refactor to make the visual novel system a bit more generic (i.e. have a unity event on the end, don’t just skip to the next scene), but it wasn’t too difficult.
Project Management (2 hours)
A lot of my time was spent on managing the programmers and the project. These responsibilities include:
Make JIRA tasks for programmers and designers based on playtesting feedback. These were really simple because all we had were tweaks and bug fixes. Because the programmers were much more familiar with the codebase, I didn’t feel it was important to make a HELPFUL LINKS section.
Reviewing and merging pull requests. There were 27 pull requests and zero merge conflicts (surprisingly), although we did have a dangling meta file (which was very odd).
Postmortem and Reflection (1 hour)
For as long as I’ve been a part of the WolverineSoft Studio, I’ve struggled a lot with how to be a good leader. So I felt it was important to take a chunk of time to talk to all my programmers and designers and get some feedback. Here is some of the positives:
Overall, the semester went very well. There were no scope cuts and the vast majority of things got done on or ahead of schedule (only a single programming task was behind schedule). Because we weren’t being delayed, the team had a lot of morale and this led to even more productivity.
I think I architected code pretty well. Each class is pretty small and the responsibilities are divided between them somewhat well. This led to pretty minimal spaghetti, allowing the team to have increased productivity.
Programmers didn’t waste much time trying to navigate the codebase, in part because the codebase isn’t that big and in part because all the JIRA tasks at the beginning have a HELPFUL LINKS and a POSSIBLE IMPLEMENTATION section (where applicable). Austin Yarger’s project management techniques worked very well, and I hope to ask him for more in the future.
People generally say they were well supported by me. I’ve struggled with giving too much guidance (which can be very handholdy) vs. not giving enough guidance (which leads to people feeling lost). I think giving my teammates a set of helpful links and some ideas on how to get started while letting them venture outside my ideas if they wanted to stroke a good balance.
However, there are a few things that could be improved (pretty minor though):
I made sure to make lots of documentation, but the major thing that slipped through is documenting how and why systems are architected. For instance, the data about the tower isn’t on the scriptable object, it’s stored in components on the prefab. This is because every tower needs different things (for instance, most towers need to shoot at a target, but the Support tower doesn’t), so towers are composed of components. However, this lead to confusion with other people, who expected it to be on the scriptable object. I think documenting how and why these decisions are made would really help.
Ensuring clear project goals from the start of preproduction, not the start of production. I spent the prototyping stage thinking I was developing a case study of Bloons TD 5, not Bloons TD 6 (which was what we eventually changed it to). This meant that things like the tower upgrades menu was implemented with poor code quality. Making these expectations clear from the start would have helped a lot.
I could have done important stuff a bit earlier rather than waiting for a while. For instance, I should have implemented WWise before production, and not during so audio wouldn’t waste its time with complicated technical problems.
Next Semester Planning (4 hours)
I spent a lot of time this week planning for the Winter 2022 semester studio. We' decided to start planning well in advance of the next semester in order to give ourselves more time to prepare. This is a strategy that proved itself well this semester. I spent these two weeks attempting to narrow down the case studies from 5 to 1. The main thing I wanted to figure out for each game was “what does the development of this game look like?” Doing these thought exercises would help me better anticipate potential problems and give me a more clear picture of each game. The main things I did were:
Try to experience the game in some way. I already had one (The Binding of Isaac) and I was able to go to the CVGA to experience one (Teenage Mutant Ninja Turtles). For the other three, I had to carefully watch walkthroughs of each game (I can’t believe the CVGA doesn’t have Hyper Light Drifter).
Look at the WolverineSoft General Library and see what each game would start with. All games could use the basics of the library but there were some that could use special scripts (like Inventory for Binding of Isaac and Parallax for Starfy).
Come up with a task list for each game. Here is an example of one for Teenage Mutant Ninja Turtles:
In the end, we chose our case study for next semester: CONFIDENTIAL
Final Build (1 hour)
I did a check of the build for the final submission to our itch.io page. I played through and beat the game, thus making sure there were no issues (there were a few balancing I would have wanted, however, but that’s inconsequential). I then made the final build for Windows and submitted it to Amber Renton for the itch page. This marked the end of development, and I couldn’t be prouder of the team and the overall final product.
