I’m working on a realistic first person shooter in Unreal Engine 5, and I’m considering using the Gameplay Ability System (GAS). From what I’ve seen, GAS is mainly used for RPGs and hero shooters since those genres have complex ability systems. My game is more straightforward, with the main inputs being shooting and zooming. Also, I’m developing the game in C++, not Blueprints.
Does anyone have experience using GAS in a minimalistic, non ability focused game with C++? Is it overkill for a simple FPS, or can it still be beneficial for managing actions like shooting, zooming, and other potential mechanics down the line?
For a bare bones FPS, without reloading or animated actions that need to be synchronised between clients, yes.
For anything beyond that, no.
GAS will take care of montage replication for you, even compensating for latency as best it can.
It’ll also handle actions blocking or cancelling others, such as sprinting being cancelled by a reload.
And way more.
The gameplay tags alone are extremely useful.
The GASShooter repo on github is a good resource for FPS/TPS using GAS:
Are we able to set this up explicitly in BluePrint or do I need to go back and forth between C++ and the editor. All tutorials are old and I don’t know if that still applies or if there were updates exposing GAS to BP’s?
I am not fully up to date with UE5’s version of GAS, but if UE4’s is anything to go by, you will need at least some work done on the C++ side to be able to work with it.
Yes, you’re going to be doing some C++ programming. There are a ton of videos that help get your feet wet, or just get the basics up and running (example here). For convenience, here is a quick link to a YouTube search.
As Kris stated, there are a lot of benefits with GAS, even if you don’t intend to fully utilize all the features it has to offer. What I’ve seen some do, is get the desired MVP (minimum viable product) features of their project going, and then identify if moving those into a framework such as GAS would be beneficial. If not, don’t do it. Simple as that.
I’ve seen shipped projects that included a huge library of assets, because the team didn’t sit down and identify what they did or didn’t need, and instead just sent the whole pack out (in this example, 2 field grass assets were used, ~9mb of data… they shipped a whole forest pack instead of culling unused assets, ~1.2gb).
Moral of the story? You know what you need or what you don’t. If you can’t identify those items, you need to research and learn what does what and why. It’s a boring part of development, but unless you want to get stuck in a loop of throwing mud at the wall and never getting better, it’s a necessary skill to obtain. Unless you’re the person with the clipboard. Then just tell some other poor sap to handle audits!