T-Minus Zero (a retrospective)

A work-in-progress retrospective for my time working at T-Minus Zero…

Introduction

  • My situation
  • The studio
  • The project

Technology

UE5, Lyra, and GAS

For this project, we opted to use UE5, specifically building on top of Lyra. Personally, I found this decision to be appealing. I’ve long been interested in really leaning hard into using the Gameplay Ability System (GAS).

In the past, I’ve met some resistance from designers on adopting this system. I’m sympathetic to the feedback. It does have a steep learning curve, especially for those who are used to things working a certain way in Unreal. Its design patterns can be rigid and strange; though, I find an appeal to that once the systems and patterns are well understood. However, having an established code base built on GAS (as part of Lyra) provided examples of these design patterns for the team to learn, adopt, and extend. Also, we had the luxury of selecting a team of designers who were comfortable working with GAS.

In my opinion, using GAS for our team was a net positive. The modern GAS model employed by Lyra empowers abilities to be crafted in Blueprint. Of course, it’s up to the engineering team to support that approach. This is often done by building Ability Tasks and Attributes, as well as setting up prototype implementations. But once that is done, networking “just works” and the abilities, effects, etc can be handed off to design to refine and expand.

Prototyping vs Foundation

As with any new product, we had to balance quick & dirty prototyping against creating foundational technology. Though this was often a (small) source of tension with my tech director, I felt that we struck a good balance overall. Too often in the past, I’ve seen engineering teams get so focused on building for scale before core concepts have been proven out. This leads to a poor showing when it comes to providing a demo for the publishers who are funding the project.

For us, this meant that often our gameplay engineers were working in Blueprint. In doing so, we were often able to identify shortcomings of the scripting system. Then we could pivot to doing the heavy lifting in C++. This often meant creating MVPs of key systems with strong scripting hooks.

My favorite example of this was systematizing explosions. This wound up being a common pattern that would often be reimplemented, running into some predictable shortcomings. What I did was create a library function called Perform Explosion which would take a Data Asset. Together, they would describe the VFX / SFX / etc via a Gameplay Cue, apply damage to nearby targets (with fall-off if desired), and handle obstructions. An insightful anecdote about this system: long after deployment, I found an instance where a designer had reimplemented their own explosion script, opting not to use my system. It took me too long to see this as a failure of my system to work correctly in all cases. Indeed, there was a bug lurking in the code that caused an obstruction to prevent damage from being dealt in situations where it was appropriate. Of course, once that was addressed, all instances of explosions using that tech became more robust. That’s the power of building systems.

Leverage Existing Solutions

Where possible, I advocated to leverage existing solutions rather than reinvent the wheel. The biggest example of course is using GAS & Lyra as the starting point for a multiplayer shooter title. When the need arose for a new system, I would make sure to check out Unreal Marketplace to see if there was something that would potentially slot in nicely with our technology. Oftentimes, there were solutions available, but they weren’t built to easily drop into GAS or appeared to lack in quality.

The best example of a success story that comes to mind for me is the integration of VaultIt! as a solution for mantling for our player package. Due to its architecture, it was easily integrated into our player package fairly seamlessly. This did however require some refactoring to fit in with the modular construction of Lyra characters. What was setup in the plugin as an interface to be implemented on the player class was moved into a component which handled all the heavy lifting. The decision to use this plugin was not without controversy. Some stakeholders initially felt left out of the decision making process, and this led to some conflict. However, after spending time putting together more thorough documentation, presenting the approach to the team, and being responsive to feedback, I felt that the most pressing concerns were addressed.

Of course there were missteps and setbacks from some marketplace content as well. The particle systems we had integrated for use before we had a VFX team didn’t always perform well, and often required us to make tweaks to work property for our use cases. Rigs for characters often had quirks that prevented them from integrating well with our tools. As the project moved farther forward, the challenges with integrating more content grew and the need for the leg up decreased. Still, I believe leveraging existing solutions is key for a small team doing rapid prototyping.

Management

  • Fully remote
  • Documentation & communication
  • Presenting to the team

Outcome

  • Situation with NetEase
  • Demo effort
  • Closing thoughts