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.

11/14-11/28: Additional Polish and Next Semester

I’ve had a lot of progress over the past two weeks. Here are my updates:

Art Integration (1 hour)

I spent some time integrating the tower upgrade art into the game. I added the upgrade art for five towers (Axe, Magic, Spear, Support, and Explosive), so the sprites change when the tower is upgraded (an example is shown above). This wasn’t too hard of a task; the main challenge was coordinating getting the sprites and converting between different file formats. This made a difference to the final product, allowing players to easily identify which towers were upgraded and which weren’t.

Bug Fixes (2 hours)

I spent a bunch of time fixing various bugs in the game. Here is a list of what I worked on:

• Fixed a bug where gold text act strange if the gold was more than 10,000 (for instance, 10000 gold would read as 10,00). Surprisingly, this wasn’t a bug in the code; rather the gold text would overflow the text container, leading to a very strange display. Fixing this involved expanding the box.

• Fixed a bug where the explosive damage event would go off multiple times in a single second. The explosive damage script damages multiple enemies, and the event was invoked inside the for-loop. Fixing this bug involved tracking down the loop and moving the line of code.

• Fixed a bug where the tower can be dropped on a bunch of different buttons. Fixing his involved added a non-droppable rect onto the various buttons.

• Fixed a bug where the back button on the difficulty select screen takes you back to the level select screen, not the mode select screen on the campaign mode. Fixing this involved adding a branch in the code that controls the main menu.

• Fixed a bug where the tower screen enable button would not face in the correct direction. Fixing this involved creating a custom script to flip the button when it is pressed.

Balancing Changes (1 hour)

I made a bunch of balancing changes in response to feedback from the WolverineSoft Playtesting List. They are:

• Making the Axe tower slightly less powerful (50% decrease in fire rate)

• Making the Archer tower slightly more powerful (22% increase in fire rate)

• Added the lead ghosts in an earlier round to ease players into the game.

• Rebalanced Round 38 by increasing the time between enemies, increasing the time between waves, and reducing the number of enemies

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. Because the prototype was finished well in advance of the kickoff, I was able to spend preproduction (which we define as the time between the application decisions and the studio kickoff) making experimental tools, onboarding new programmers, and creating documentation. If I had to spend that time making the prototype, my time would have been split and I would have been less productive. We’re going to replicate this strategy for the next semester.

I spent a bunch of time in meetings this week trying to plan out the details of the next iteration of the studio. Here are the things we determined:

• We will be doing one project in Unity of about 25 people.

• We will be doing a case study of some kind

• We will bring back designers (we decided not to this semester because we believed we couldn’t give them tasks, but our lack of designers has proven to really hurt us).

• We have a concrete schedule for next semester’s production

• We have a list of 5 case studies to choose from for the next semester. We will be meeting with some people over the next two weeks to discuss which one we should pursue (including our friends at Arbor Iteractive)

Project Management (4 hours)

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. Many programmers said my method of making tasks with a HELPFUL LINKS section and a POSSIBLE IMPLEMENTATION section assisted them in their task (this is blatantly inspired by Austin Yarger’s teaching techniques, I’m sure he won’t mind). Upon further questioning, students said this helped reduce the time they spent lost in the codebase. I created their tasks with these sections (at least where applicable).

• Reviewing and merging pull requests. There was only one merge conflict and 20 pull requests, which wasn’t too hard to merge in.

• Checking in with members and assisting them with implementation. This mainly involves answering their questions about how the code works and directing them to the relevant parts of the codebase. Overall, it seems that students find the codebase easy to navigate, especially with the HELPFUL LINKS section of the JIRA tasks (it also helps that the codebase isn’t that big, I’d estimate around 5k lines of original code)

10/31-11/14: Preparing for Beta

I’ve had a lot of progress over the past two weeks. Here are my updates:

Tower Range Indicator (1.5 hours)

Many industry playtesters suggested that when a tower is selected, a tower range indicator is shown. This allows players to better strategize since they can actually see the range of the tower. I wanted the indicator to be placed under the tower so the tower art is the most prominent. This was actually a bit more challenging than I initially anticipated because the towers are all sprites but the current range display is a UI element. I created a new display that’s a sprite renderer rather than a UI element, and modified the event systems to allow me to do this.

Various Bug Fixes (4 hours)

I spent a lot of time fixing bugs in Project Tower. Here is an overview of the bugs I fixed:

• Fixed a bug where the campaign refused to progress past the first cutscene

• Fixed a bug where red ghosts dealt 15 damage

• Added a radius to tower collision checking

• Fixed null reference exceptions in main menu

• Fixed the colliders in the monkey meadows clone level

• Fixed an additional bug where the campaign referenced a scene that got renamed.

• Added unique sorting layers to all the enemies

For most of them, I didn’t need to refactor systems. It was about finding which system controlled which element of the game and adjusting the data accordingly.

Additional Upgrades (2 hours)

There were a bunch more upgrades that needed to get in the game. The ones I implemented were:

• An upgrade that allows projectiles to stun enemies. I had the ability for enemies to be stunned.

• An upgrade increasing the radius of an explosive tower

• A projectile health upgrade that makes projectiles more durable

• A support tower upgrade that allows support towers to see camo ghosts.

Asset Integrations (0.5 hours)

I integrated two assets into the game. The first was the explosive projectile sound effect by Crystal (see below), which plays whenever an explosion goes off. I had to set up the event system on the explosion script to allow it to go off

The second asset is the sniper tower upgrade art by Zelin (see below). This was actually really easy because one of our programmers set up a way to do this. I just had to drag stuff into the inspector.

Project Management (4 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. Many programmers said my method of making tasks with a HELPFUL LINKS section and a POSSIBLE IMPLEMENTATION section assisted them in their task (this is blatantly inspired by Austin Yarger’s teaching techniques, I’m sure he won’t mind). Upon further questioning, students said this helped reduce the time they spent lost in the codebase. I created their tasks with these sections (at least where applicable).

• Reviewing and merging pull requests. Surprisingly, there weren’t any merge conflicts this time (which is very odd). However, we got 30 pull request in those two weeks, and I always double check to make sure no files were accidentally broken.

• Checking in with members and assisting them with implementation. This mainly involves answering their questions about how the code works.

10/17-10/31: Keeping Momentum

I’ve had a lot of progress over the past two weeks. Here are my updates:

Narrative System & Integration (4 hours)

I spent a lot of time working on the narrative section of the game. Our game is one of the only tower defense games with an actual story, which is conveyed through a visual novel system. I created a system that allows a visual novel cutscene to play out. In addition, I integrated the opening cutscene into the game using my system. By doing this, I realized my system was really clunky and requires far more effort than it actually needed to. I think in the future I might create a better editor for this visual novel system, such as a dialogue graph.

Tower Upgrades (3 hours)

In addition, I spent time creating a system for tower upgrades. Each upgrade class inherits from TowerUpgrade, and does a specific thing to the tower GameObject. This makes making an upgrade simply a few lines. I made 6 different upgrade classes, including:

• DamageUpgrade for upgrading the damage of projectiles

• FireRateUpgrade for shooting towers

• NumShotsUpgrade for the Area tower

• ProjectileSpeedUpgrade for upgrading the speed of projectiles

• RangeUpgrade for upgrading the range of towers

• SeeHiddenEnemiesUpgrade for allowing towers to see hidden enemies

However, Unity (to my knowledge) cannot properly serialize polymorphic classes to the inspector (and to be fair, neither can my custom engine), so I had to make an editor script in order to edit them in the inspector. In the end, the tower upgrades could be edited and adjusted in the inspector.

Support Tower (1.5 hours)

I also spent some time implementing the support tower, the final tower of the game. This tower applies specific upgrades to all towers in range, both when it is placed and when other towers are placed around it. Currently, it just applies a SeeHiddenEnemiesUpgrade to the towers in range, but it will apply more in the future.

Project Management (3.5 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. Many programmers said my method of making tasks with a HELPFUL LINKS section and a POSSIBLE IMPLEMENTATION section assisted them in their task (this is blatantly inspired by Austin Yarger’s teaching techniques, I’m sure he won’t mind). I created their tasks with these sections (at least where applicable).

• Reviewing and merging pull requests. This can be time consuming because we’ve had some bad merge conflicts due to poor coordination. Using techniques that previous programming leads have taught me, I was able to navigate them and find ways to merge them in while keeping most of their work.

• Checking in with members and assisting them with implementation. This mainly involves answering their questions about how the code works.

10/3 - 10/17: Setting Up The Project

I’ve had a lot of progress over the past two weeks. Here are my updates:

Various Bug Fixes (2 hours)

Our recent playtests with industry advisors, including Austin Yarger, Jordan Ajlouni, and Matt Rader, have been playtesting the latest builds of our games. This has actually uncovered some bugs early on (which I’d argue is a good thing), which I could fix.

Some of the bugs I fixed include:

• Prevented Towers from being dropped on UI: This involved creating “Non-Droppable Rects” on UI elements so that the towers can’t be dropped on certain regions of the game

• AOE Tower Colliders: This is because the range of a tower can be set in the Tower scriptable object, which is then set on the tower’s aggro collider. However, it did this by using “GetComponentInChildren<CircleCollider2D>()”, which wasn’t great because towers may have two or more circle colliders. I changed it so does “GetComponentInChildren<TowerAggro>” which returns a GameObject that has the correct circle collider.

• Prevent Towers from being placed on other towers: This involved changed a layermask. It wasn’t that interesting.

Area of Effect Tower (1 hour)

I created a new tower, the “Area of Effect” tower. This is essentially the Tack Shooter, which shoots in all directions rather than one. The main challenge was figuring out how to make my component in a modular way such that creating a new tower would only involve swapping one component for another. This is a great benefit of the tower architecture that new towers only need a single new component rather than coding it from scratch. Below is a video of the Area of Effect tower.

Documentation (3 hours)

I spent a lot of time this week was spent creating documentation on Confluence for my team members to use. Here are some of the most important pages:

• Enemy Components: A list of components for an enemy. These are used to encourage a more modular architecture for enemies

• How Do I (Level Design) … : A guide on a bunch of level design things, including creating new levels, paths, obstacles, and testing levels

• Tower Components: A list of components for a tower. These are used to encourage a more modular architecture for towers.

• Tower Creation Guide: A guide on creating new towers.

WWise Integration (2 hours)

I integrated WWise, our audio middleware, into our Unity project and enable the WolverineSoft WWise-specific parts of the codebase. This was complicated by the fact that we had a few different assemblies in our project, which caused a bunch of compilation errors. This was fixed by finding and fixing each missing references and experimenting with preprocessor directives.

Following that, my next task was to integrate the first sound effect, the enemy death sound, into our game with Crystal Lee, our audio coordinator. This involved teaching her about the audio events systems, which allow audio members to work independently of the programmers by letting them integrate using UnityEvents. Teaching them this allows them to integrate sound effects and music themselves rather than rely on programmers (which allows them to focus on other tasks)

Cheat Codes (2 hours)

An image of the console

I also created cheat codes for our game. Previous WolverineSoft Studio projects, including Circuitry, had cheat codes using a command console. I spent some time integrating their console into our game (which was complicated by assembly reference issues). Many commands, such as InfiniteAmmo and IsInvincible, had to be stripped because they were specific to different projects, so only a few generic commands (such as ChangeScene) actually work. In the future, I may consider adding more generic console commands.

Because Bloons can be up to 200 rounds, I created a couple cheat codes to help developers.

• SetGold, which sets the gold to be a certain amount

• GoToRound, which skips to a certain round

Project Management (2 hours)

I also spent a significant amount of time creating JIRA tasks for programmers, merging in pull requests, hosting meetings, and helping members with their tasks.

An example JIRA task

One of the new things I’m doing this time is adding a “HELPFUL LINKS” section to each task (this idea was inspired by the Hints documents in EECS 494). A major problem in previous semesters was that members often struggled with figuring out how to implement their tasks, and often were directionless when facing new tasks. To combat this, I created this sections to guide programmers on where to find relevant information (this has the added bonus of familiarizing them with our resources). It might include links to Unity documentation, scripts in the repo, or the Bloons wiki. 75% of my programmers used at least one of the links in these sections, meaning this had the intended effect of making their lives a bit easier.