Io Dev Blog 5

April 7th, 2020 ~ April 20th, 2020

Bug Fixing and Boss Trigger Implementation

Boss Attack Scriptable Object Debugging

During the final stages of the final boss implementation, a severe bug was discovered that completely halted the progress of development. When the custom editor was used to design and implement an attack, it would sometimes not save to disk, completely resetting the data of the asset file, undoing all of the work done to implement it. It took a significant amount of research and testing to figure out what had been causing the bug, and even more time to fix it. The problem originated with the method in which Unity handles saving changes made to files with the .asset format. Whenever you press ctrl+s in Unity to save any changes you have made, Unity goes through a list of files that it has marked as 'dirty', and saves only those files. Normally any changes made in the scene are automatically marked as dirty. However this only applies to changes in the scene. While the custom editor I developed uses Gizmos in the Scene to modify the data of the asset file of that specific scriptableobject, The asset file itself is not in the scene, so it is not automatically marked as dirty. Unity only checks if asset files outside of the scene have been changed every couple of minutes, or other specifc circumstances such as exiting the scene itself. After much research on Unity's handling of asset files and scriptable objects, I implemented a fix that used the EditorGUI.StartChangeCheck function and EditorGUI.EndChangeCheck functions to manually check for any changed data in the asset file itself for every render of the custom editor, and if any changes were found, the asset file would be set dirty using the EditorUtility.SetDirty function to manually mark the file as dirty so it would be saved whenever ctrl+s is pressed or Unity auto-saves changes. This process took around 12 hours in total.

Playtesting

As the game was entering the last stages of development, extensive playtesting was required to find and fix any bugs that had gone unnoticed or had been caused by integrating systems together. I participated in multiple playtests, and several that were proctored and recorded by designers. I was part of the playtest that was used to decide the keyboard controls for the windmills. I played through multiple builds, each using a different button to cling onto the windmills, and I gave feedback on how each option felt, and which was my most preferred option. I playtested for approximately a total of 5 hours.

Boss Trigger Implementaion

As the sprint was coming to an end, another bug with the boss was discovered. The boss was activating itself when the scene was loaded, and prematurely going through its states and attacks. I fixed this bug by implementing a trigger that activated the boss at the appropriate moment. This was done by using the OnTriggerEnter2D function. Whenever the a GameObject with the tag 'Player' collided with the transparent Trigger GameObject, it would activate the Boss, and the trigger was placed at the location where the player begins to fall into the boss arena. This process took around 1 hour.

Limitations and Future Tasks

One feature that could not be added to the BossAttackScriptableObject due to time constraints was the abilities to invoke events during the attack. This would allow the Attack function to invoke any event, including Wwise audio events, allowing the scriptable object to be used for many other things aside from boss attacks. I will be working to implement these features to the BossAttackScriptableObject, alongside expanding it to allow for use in 3D projects as part of the preproduction for WolverineSoft Studio's Summer Project.

WolverineSoft Labs

For the WolverineSoft Labs, the remaining team, untitled-bug-game finished their game, delivering a gold build, complete with a main menu and game loop. The final build will be uploaded to WolverineSoft Studio's itch.io page, alongside the main studio game.