Io

ABOUT

A long term project completed over the course of a semester by around 90 University of Michigan students, Io is a 2d action platformer with tense combat, high mobility, and difficult platforming and a final boss, all utillizing the unique teloportation mechanic.

DEVELOPMENT INFO

  • Developed by WolverineSoft Studio
  • 3 month development cycle (02/04/2020 - 5/04/2020)
  • 90 developers
  • Made using Unity Engine

CONTRIBUTIONS

  • Programmer

POST-MORTEM

WHAT WENT RIGHT

  • Developer tools creating using ScriptableObjects and Gizmos allowed for designers to design and implement attacks without having to directly code or work extensively alongside programmers
  • Division of boss implementation into State Machine, Attack, and Projectiles allowed for a modular system that allowed fast prototpying and creation, and the system was stable enough that it is being considered for future WolverineSoft Studio Projects
  • Usage of Confluence Collaboration Software allowed for designers, artists, and audio engineers to easily look up documentation for assets created by programmers, and prototype using them without the direction of a programmer



WHAT COULD BE IMPROVED

  • Because progress was far slower than initially anticipated, severe downscoping was required, with only 2 levels left of the original 6, and 1 boss instead of 2
  • Sprint deadlines were often not meant, with tasks being worked on days after they where due, and many tasks were pushed to the backlog and future sprints, causing work to pile up
  • Playtesting, while extensive, was not done enough, resulting in game-breaking bugs in implementation being discovered very late into prodcution, forcing programmers to work overtime to fix them



LESSONS LEARNED

  • Task assignment must be done with far more care, taking into consideration any unexpected circumstances that may cause them to take far more time, and sprint deadlines must be enforced more strictly to avoid work piling up
  • Extensive playtesting must be done for not only features and design, but also for any custom tools that were created for the projcet
  • While downscoping happens during the development process of almost every game, it should be taken in consideration during preproduction to prevent very large segments being removed after work has already been done

CONTRIBUTIONS

My major contribution to this project was the implementaiton of the ScriptableObject that stored the data of an indiviual type of boss attack, and the tool that allowed developers to easily create their own attack without touching code, through the Unity Inspector and Scene Editor. The boss system was initially divided into 3 parts, the State Machine, which controlled the behavior of the boss, the BossAttackScriptableObject, which stored the properties of the attack, such as the animations, and coordinates for the projectiles, and the Projectile prefab, which was the individual projectiles that would be instantiated by the BossAttackScriptableObject, which was in turn called on by the State Machine. The ScriptableObject stores a list of possible projectile prefabs, and coordinates and rotation, and prefab type for each projectile that is instantiated, and the animation that the boss will go through. The ScriptableObject itself has an Attack() function that instantiates all the selected prefabs, at the stored coordinates and rotations. I utilized a CustomEditor script to create the Editor interface from scratch. There is a empty ObjectField where a designer can drag in prefabs that will used in the attack, which are added to an internal List. A dropdown field of all the stored prefabs is underneath it, allowing each prefab to be removed from the list. Underneath that, is IntField to decide the number of projectiles that will be instantiated, and fields for the type of prefab, coordinates, and rotation of each projectile are automatically added or removed underneath this as the number of projectiles are changed. Up until this point was fairly simple, albeit time consuming to implement. The difficult part was the creation of a tool that allows the designers to easily create their own attacks. The method I used was having a Gizmo be rendered at the location of each projectile, and handles on the Gizmo that allow the coordinates and rotation to be changed by clicking and dragging on them, without having to input exact numbers in the Editor. However, I encountered many difficulties.
Unlike almost any kind of Object class in Unity, Gizmos do not have a Transform component, and their global location and rotation are stored in a Matrix4x4 format using Quaternions. Converting to and fro from Matrix4x4 to Vector3 is extremely tedious, but it is possible by creating a new one of either, and using Unity's conversion functions. The big problem was making the location and rotation of the Gizmo correspond to the transform data stored in the ScriptableObject when it is stored. I ended up using a very obtuse system that involves multiple conversions between data types, and how I did this and why I did so can be found in the Dev Blog for Io, linked below.
Another big problem that occured later was a bug that caused the data stored in the ScriptableObject to randomly be reset. After extensive research, I discovered that this was because, unlike any changes made to an Object that is in the currently open scene, a ScriptableObject is not automatically checked for changes, and is only checked in specific circumstances, such as the object itself being exited, or a save not having occured for a long time. So, any changes made in the Editor would not be saved to disk on ctrl+s, resulting in them reset whenever Unity was closed and opened again. This was fixed by manually marking any changes as dirty in the CustomEditor script.