What is SkyHook, and what was my role ?

SkyHook (check it out if you haven't already !) is a 3D aerial platformer toy we made in Unity over the course of one semester (3.5 months).
I was in charge of programming, some game design, and was also appointed as the project lead. We had the idea of the player interacting with an aerial, groundless environment from the start of the project, and the hook seemed like a fitting choice.

Project Lead

Let's dive in on what I've learned while trying to make this project work, what issues arose, and how they could have been handled better.

First, as it was my first time working as Project Lead on a team with multiple people having skills overlap, mostly due to having a 4 people team instead of 3.

This meant that, unlike in other projects like Elementaria, we could not simply have everyone work on their tasks autonomously and meet weekly to see where everyone was at, but we also needed to figure out who would be working on what. We did not realise it at first, and the work on the artistic side of the project started way later because of it, which impacted the quality of the project.

This was honestly a blunder, and could have been avoided easily if :
- At the start of the project, once we had the first proof of concept validated, we made a  (close to) comprehensive backlog of what we're expecting to be needed for the project. This would have given us at least an idea of how long we could afford spending on each task, which would have raised the alarm earlier.
- As soon as possible, we assigned roles / domains each of us would work on. We had ideas of what each of us would like to do for the project, but it was vague and never formalised until way too late.
- Also, since we are still learning and experimenting, we had everyone work on what they wanted to work on instead of what they were best at. This meant that we all improved in the domains we worked on, but also that the project could have been of better quality. While I would not make this choice again, I do not regret it whatsoever, because if we doesn't try new things while they are still a student, when will we ?

Second, I was too focused on my side as a Programmer instead of the Project Lead. I ran into issues (that I will develop later on on the technical aspect of the project) while working on the air movement, and I kept bashing my head against a wall that wouldn't budge, which contributed to the poor organisation at the start of the project. As I was stuck on my end, I pulled more ressources to help me with other aspects that would have normally been my job because I couldn't make progress. What I should have done here is : 
- Take a step back, and try to get a wider view of the project, not tunnel-vision on my role.
- Have better task priority : The air movement is actually not the first priority in SkyHook, because you spend 90~99% of your time hooked to objects, and use that to move around.
- Knowing that, I could have simply freezed the development of the air movement for a while, worked on other things that needed my attention (and have had my teammates work on things they should instead of pulling them to me), and came back on it later.

This point is actually my biggest regret and learning. If something doesn't work (and time constraints and dependencies allows), I think it's fine to work on your other tasks first, and then come back to it. As you'd have taken a step back, you'd get new perspectives and ideas, and maybe realise that what you were struggling with was not an issue at all.

However, we managed to get back on track, and once we realised those issues and fixed them, the last month and a half of development went pretty smoothly, and we delivered a project the entire team is proud of. Try it out (here), and let us know if it's any fun !

Game Programmer

As I mentionned previously, my personal role on the team (aside from overseeing the project) was programming. SkyHook is made in Unity 3D (so C# language), which was a first for me. I had already made some Unity projects, but never a full game (well, toy), and I learned a lot.

First and foremost was the importance of classes. When the player hits an object, we did not want an actual collision to occur (because that could kill momentum), so we made it so that the player script tells the object to get out of the way slightly before the collision would occur. However, we used the "SendMessage" method, which required us to manually enter the name of the function we wanted to call via string. The issues was that since we had different items, we had different method names, which would be a pain (and also not be efficient).  Instead, we used classes : essentially, instead of having the player tell each object either to be pushed, disappear etc, it instead tells the item "Hi, I hit you", and each item can translate that "Hi, I hit you" in "I should be pushed" or "I should disappear" accordingly.

Second was the clarity of tasks (though this is more on the Game Design side). We wanted the game to have air control (as mentionned earlier), but we weren't quite sure on how to do it. As SkyHook's fun comes from the speed you can build up, we couldn't just do as most games do, allowing you to move in any direction at your current speed even in the air. However, since this is how most 3D games with air control do, we could not envision any other way to do air control. The one alternative we found, having the player in the gain speed while in the air felt unnatural. It took a while for us to take a step back and realise we were trying to do the former while also not doing it. We ended up settling on being able to slightly influence the movement but not in the direction you are already moving. However, now that the project is over and I've had some time to think, I think there were different, more elegant solutions, such as granting you complete air control at low speed and restricted air control (influencing the movement) at higher speeds, which would have felt nicer.

Finally, I learnt a lot about instances of objects. The best example is for materials and shaders. For the object that vanishes periodically, we wanted to use a shader (and a material) that conveys how long is left until they disappear. However, if we were to modify the material's parameters directly, it would change the appearance of all the objects with that material. What we did instead is that each object that uses this material creates its own copy (instance) of it, and applies it to itself, allowing each object to be independant.

Conclusion

Thank you very much for sticking with me until the end. Don't hesitate to check the project page, the rest of my page, as well as our lead game designer and our lead artist / sound designer.