— Final Planet —
4 player twin stick shooter - School project
Final planet is this fast paced shooter where you progress trough a swarm of bugs using an array of skills and weapons. It's an arcade style frenzy of a game made in Unreal engine using only blueprints.
It was the last big school project of the program — meant to simulate a work environment and get us ready for the industry. We were 25 students of various specialties and had 8 weeks to go from a shaky prototype to a playable product.
I joined the project mid-production, and became in charge of nearly all the scripting related to gameplay - from character controls to weapon systems and pretty much the whole UI.
experience with the project
This project gave me very rare and valuable experience working on a game too complex to be carried trough my own sheer will. I had to learn to delegate effectively, and constantly prioritize between developing critical features and offering much needed technical advice to those who struggled with the engine.
I learned to work without headphones, constantly switching from being available to my peers and focusing on tasks.
scrum-mastery
I had a team of 8 to orchestrate on a daily basis, all of them programmers like me or vfx artists. I used Hansoft to track progress, assign task, and receive bug notifications. I am not a natural in team management, and I've learned a lot on just how critical smart communication can be in larger teams. We worked close by, and I had to constantly be on the look-out for moments when my input was necessary for someone to be fully productive. I now understand the time-saving nature of pipeline software in ways that smaller project couldn't show me.
Technical lead
As lead of the technical team, I also oversaw communications between the teams on matters of engine integrations and version management. I ended up teaching the animation teams how to integrate their work into state machines and showing the level designer how to use the tools I had made to spawn enemies. This proved a challenge as I had to redo the enemy spawning logic multiple times to make it usable, as I will demonstrate in a moment.
Wwise integration
Another technical task I had to take care off was the integration of sounds. We had a partnership with another university (UDEM) where they would compose music and sounds and create a Wwise soundbank with the necessary settings.
However, there was many difficulties getting the plugin to work in spite of our sub-versioning program (Perforce) refusing to cooperate and having very limited and outdated documentation on the Wwise plugin to work with. Many hours were spent on the phone, getting accustomed to a new interface (sound design is something I had barely touched before) and troubleshooting my way trough Perforce's quirks.
We faced the possibility that no sounds would end up in the game, as the project management was starting to get nervous that I didn't spend all that time squashing bugs before the release.
Me and the sound design team did find a solution, and it really bolstered the user experience, making me glad I took the risk. It was a real test of my autonomy and a stretch of my comfort zone that makes me confident I can handle issues coming from unexpected angles in future projects.
Another thing I learned early on was how critical it was to filter out frustration, either coming from a teammate desperation or a tenacious hurdle. By being purposefully positive and accepting of others needs, I found that I could neutralize a lot of the pressure in the air, and brighten the "crunchier" days significantly for my whole team. I know the world of game development is one of tight deadlines, imperfect decisions and stressed individuals... yet it is crucial for me to stay mindful and connected to the fun part of creating games together, no matter the circumstances. This project was as much a test of skills as a test of professional maturity, at least I made it so by refusing to slip in a negative state.
blueprints and scripting accomplishments
Repairing the prototype
One of my first task when I joined the team was to, quite simply, scrap the code and start from scratch. Trough no fault of theirs, the previous scripting team was made of level designers and technical artist that had some experience in blueprint, but had coded themselves into a corner.
The character blueprint, for example, was so large and inefficient that it would freeze the engine upon any modification. The culprit was a customization system that wasn't using functions and structures to streamline the process of giving each character a helmet and assigning the glowing material to the correct IDs. By using functions, dictionaries and structures, I was able to shrink the code to a manageable 1/30th of its previous size.
(I estimate it was at least 3000% more efficient than a frozen screen and a reboot)
After making weapons and ability child-actors, using inheritance and common parameters to take care of special abilities and better separating the player controller from the character blueprint, everything became much more tidy and fit for the content that was coming with 20 more students joining the project.
A.I squirming behavior
The A.I needed to be remade too. We wanted swarms of creatures, and their movement had to be more convincing than a simple "move toward player on sight" logic. Me and a teammate figured out behavior trees to build up a simple AI that still allowed for some scripted encounters to happen. It included ranged opponent moving away and melee creatures sticking to a chosen target (in ambiguous situations where multiple players all stayed at similar distances). This made "outsmarting" the A.I possible, but not as trivial as changing which player was the closest every second.
I also scripted knock-back propagation behavior that allowed creatures to slide off one-another when the player pushed trough them, a necessary behavior as the player would often be stuck in waves of enemies otherwise, and lose a lot of agency quickly in most fights. (We wanted the creatures to have a physical presence, but not bully the player into immobility!) This also had the unintended effect of making bugs bounce off one another when swarming around you, adding an unpredictable element to the movements of the enemies. They wouldn't form straight "waiting lines" anymore when following a player and often made subtle change in direction as they adjusted to each other recursively.
The problem with the spawners
One of the biggest change between the prototype and the final product was the decision to add a layer of procedural generation to the levels. There was three sections, from easy to hard, with a selection of possible room to be picked and ordered at random.
Our "room" sub-levels ended up being blueprints of their own that where instanced by a level manager a colleague devised. This had many advantages, but also made these chunk of level-design into something else than levels... and one limitation that came with that was the impossibility of using unreal "picker" tool to create references manually between what had become child-actors.
This created real problems when level designer needed an enemy wave manager:
— It wasn't possible for them to reference spawn locations from the triggering box.
— Absolute coordinates didn't work inside an actor, and local coordinate proved unreliable and unwieldy.
— At this point, working on the sub-level was slow and anything that made the construction script update often made the whole engine very demotivating to work with.
After many trial, I ended up separating the spawn locations, the spawning-manager and the trigger-boxes, and using event-dispatcher firing trough the game-state and communicating trough IDs, (along with a logic that checked for a shared sub-level parent). After implementing a Ui for the designer to see the IDs that would be activated by a given spawner, the whole system became much more easy to handle, and they became able to troubleshoot spawning problems much more easily without assistance.
I would not use blueprint as levels anymore, but I no longer hesitate to use dispatchers and similar system to avoid the need for direct references.
Final planet couldn't be bug-fixed as much as we would have loved, given that a lot of features still had to be remade well after the prototype was approved. Yet I am proud of the team and how much was achieved in mere weeks!
Consider downloading it freely on itch.io and giving it a try!
