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)

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.

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.