The Long Shadow of the Gameplay Ability System

This week I came dangerously close to completely abandoning my vision for the Shooter Sandbox as Blueprint-only project and embracing the possibilities inherent to working with the Gameplay Ability System and C++.

It’s been a decision I’ve agonized over for the better part of three days as its impact fundamentally changes not just the Sandbox but a number of my other ongoing projects as well.

It’s been a bit of a rough week.

Why the Gameplay Ability System?

Over the last few months I’ve been chipping away at developing an action-based multiplayer foundation from which to build features for the Shooter Sandbox, and I’ve been doing a lot of research and experimentation, learning a lot, and making a whole bunch of interesting mistakes.

It’s been fun, but again and again I find myself running into roadblocks that require C++ to overcome. Sometimes just a few lines of code copy/pasted from the net is the difference between using an inbuilt feature or having to painfully recreate an inferior stand-in with Blueprint.

This is never more true than with the many features of the Gameplay Ability System.

There are already a bunch of comprehensive guides that explain what GAS is and why it’s so useful, and I wouldn’t be able to do any of them justice here so I won’t go into much detail. I’ll drop some links at the bottom of this section if you’d like to learn more.

Suffice to say making a game is hard, making a multiplayer game is much, much, harder, and the Gameplay Ability System does a lot of the heavy lifting right out of the box. It’s not the easiest thing in the world to learn and took me a while to get my head around, but once it’s up and running it makes adding a large volume of gameplay content much easier.

This is especially true with the efficient network replication of character actions/attributes, which GAS does using black-box-engine-code-magic that no one I’ve spoken to seems to fully understand.

If you’d like to learn more about GAS here are the resources I found useful when unpacking it for myself:

• GAS Documentation by tranek
• Gameplay Ability System Basics by Umbral Studios uses tranek’s documentation to guide you through the set up process step by step.
• The truth of the Gameplay Ability System by Alvaro Jover-Alverez
• Multiplayer Network Compendium by Cedric Neukirchen (not strictly related to GAS, but a must-read to understand how multiplayer works in the Unreal Engine)

Why is this decision so difficult?

Most of my work thus far on the Shooter Sandbox has been to develop a solid multiplayer framework from which to start adding gameplay features, and it’s becoming increasingly obvious just how well suited GAS is to this purpose. Reinventing the wheel isn’t fun or interesting so it’s become difficult to justify not using it.

On the other hand, since its inception my vision for the Sandbox was always to be a Blueprint-only learning tool, allowing others to unpack a range of different features and making it as painless as possible to pull specific parts out for experimentation/use in their own projects. Using GAS would throw up a bunch of additional hurdles and would make the whole concept less attractive.

Here are the pros and cons I landed on for introducing the Gameplay Ability System.

Advantages

• It features highly optimized data replication that was originally created by wizards at Epic for their Paragon project. The Shooter Sandbox would have more efficient netcode with GAS.
• GAS has fast become the go-to tool for multiplayer action games and its popularity continues to grow. It’s important for the Sandbox to use the latest technology so it’s as useful as possible for people hoping to use it as a springboard for their own projects.
• The Lyra sample project provides a fantastic (if not also hugely complex) example of how this technology can be applied and learned from.

Disadvantages

• GAS has a significantly more intimidating learning curve, which reduces the Shooter Sandbox’s viability as a learning tool.
• I am not super comfortable working in C++, which limits my capability to modify/adapt GAS. I would likely be at the mercy of third-party plugins.
• There are already a large number of first and third-person shooter templates that lean on GAS, which makes my Sandbox less useful to everyone. It would be nice to make something that fills a unique gap. If you want to make a shooter with GAS, Lyra already exists.

My Options

1) Stay the course

Stick with what I know and what I’m confident I can achieve. This would require the recreation of certain aspects of the Gameplay Ability System in Blueprint, and to accept that they may never be as efficient.

Among the benefits of this would be that I would have total control over the system and its implementation, and I can ensure it’s easy to digest and adaptable to your own projects.

2) Take the leap into C++

Bite the bullet and implement the Gameplay Ability System into the Shooter Sandbox. This would necessitate abandoning the Blueprint-only vision of the project and bring it more into line with the expected industry practice for a competitive multiplayer game made in Unreal.

This may also include the use of third-party plugins like GAS Associate, which expose C++-only features to Blueprint.

3) Stall for time

As the Gameplay Ability System continues to develop and more games utilizing the system are released there is a chance that currently code-only features will be eventually exposed to Blueprint, allowing us to use GAS in a Blueprint-only project.

We might just need to wait this out and make a decision when there is more support available.

Mountains & Molehills

I won’t deny that this whole process took the wind out of my sails. For a brief while it was a significant drain on my motivation to continue development, and it had brought all progress to a screeching halt while I was forced to question the merits of the project.

I started this dev log primarily to share my progress with you all, but I feel like these kinds of internal discussions are also important to share. I hope you’ve found it illuminating.

As for what I’m going to do next, you might already have figured out that in the process of breaking all of this down I have come to my decision. I’ve determined to stay the course, stick with my original plan, and do my best to make this Blueprint-only project as useful/approachable as possible. I think the journey itself will be worth it, irrespective of outcome.

Thanks for reading. It’s time I got back to work!