Io Dev Blog 3

March 1st, 2020 ~ March 23rd, 2020

Fixing bugs in custom editor tools and prototyping boss attacks

Boss Attack Editor and Boss Projectile Editor Bug Fixing

After extensive testing, a bug was discovered in the Boss Attack Editor that I had created in the previous sprint. If a prefab in the Projectile list was deleted, the CustomEditor would crash, and it would be no longer possible to add or remove projectile prefabs. After several attempts, this was fixed by checking if each prefab was null, and removing it from the list if it was. This took around 3 hours.

When I began prototyping the crystal slam attack, I quickly found a bug in the Boss Projectile Editor that another Boss Pod member had made in the previous sprint. The custom editor worked in a similar method to the one that I had designed, having an expanding list of 'stages' that the projectile could go through. I found that if I increased the number of stages beyond 1, if I would click out of the editor or go to a different window, the stages would disappear, leaving only the first one. The data of the first stage would be preserved, but the number of stages would be reset, and the other stages in the editor would disapper. After some research, I discovered that this was happening because the ListSize variable was being declared inside the CustomEditor script, and initialized to 1. If the variable was declared in the MonoBehavior part of the script, the intial value itself would be overriden by changes made in the inspector automatically. However, since it was in the CustomEditor, every time the Editor was reloaded, it would initialize to 1, effectively removing access to the rest of the stages. The data of the stages was still in the list, but the ListSize, which was used to count the number of stages to display, was reset to 1, so they were not shown. This was fixed by adding a line of code in OnAwake() to set ListSize to the actual size of the stage list itself. This took around 5 hours.

Crystal Slam Attack Prototyping

The Crystal Slam attack is a attack for the final boss of the game, in which the boss rises high into the air, and slams down, sending spikes of crystal out of the floor, forcing the player to jump of teleport above the ground in order to avoid being damaged. It was designed by a designer in the Boss Pod. The attack will grow more complex with each stage, with the boss eventually firing projectiles while in the air, and those projectiles eventually becoming homing projectiles. For this sprint, I prototyped the most basic version, with only the spikes on the floor, mostly to check if the BossAttackScriptableObject and the TemplateBossProjectile would work together properly. I added 20 projectiles just under the ground, and gave each two stages. During the first stage, which lasts 0.2 seconds, the spikes(projectiles) would rapidly rise up from underneath the ground, covering the ground. In the second stage, which lasts 5 seconds, they would simply stay still, and then delete themselves. The net effect would be the spikes sprouting out the ground, staying for a few seconds and disappearing. The prototyping of the attack took around 4 hours to complete.

Limitations and Future Tasks

Unfortunately, due to the state machine still having several bugs and not working properly, I was unable to add the BossAttackScriptableObject to the state machine and implement the logic for the boss to attack. This should be taken care of in the next sprint. Another limitation is that the BossProjectiles must all be instantiated at the same time. A feature that is currently being debated upon is adding the ability to deactivate or reactivate the MeshRenderer for each stage of the projectile. This would be and easy solution that does not require adding another (time) variable to the already complex BossAttackScriptableObject.

WolverineSoft Labs

Unfortunately due to COVID-19, the WolverineSoft Labs were not able to make much progress, as many students were self-isolating and moving back their hometowns or home countries.