Archive:
Fixed the problem with FOV on Ultrawide Monitors. Turns out the maths to calculate FOV from viewport dimensions isn't too tricky. Which is fortunate because I discovered -- after much doodling and scratchy maths -- that there's an option to keep Y FOV built into the engine... facepalm.
Started on the Wand encumbered versions of the Walk/Jump/Idle animations and made the Wand an optional collectable that the Animation Blueprints check the status of.
While I was testing all that, I started to think it'd be worth implementing a Double Jump. It would definitely suit the change in scale of the player character, and would make it easier for certain things to be achieved. Especially now that there's a Jump Cancel.
Finished off the Wand encumbered animations, then went back into the Animation Blueprint and tried out the new State Aliases. Woah... they’re a massive help!
They allow states that have the same transition rules to exit from an alias, which removes a LOT of criss-crossing transition lines. Or, to put it another way, you can relax with the layout OCD. A massive time saver.
Got a call from the Solicitor: our house purchase has gone through... Exciting, except I've suddenly got a lot of boring things to do.
Decided to implement UE5's Gameplay Ability System on the player character. Started off by converting the Wand over. Mostly this went OK; got the Gameplay Ability Component setup, added various attributes, defined some abilities, and was able to trigger them.
What I couldn't get going:
Gameplay Cue for Wand activation -- a light and a particle effect -- wouldn't attach to a socket in the player character's mesh without a super nasty hack.So I've reverted everything.
I don't need GAS. I would have liked to take advantage of the stacking and especially the way it's coupled to the animation system, but I'm not au fait with it, which is going to cost me time. It was worth spending the day to check it out and come to a decision, though.
Woke up this morning wondering if I could nick the bits from GAS that I liked. Or at least, roll my own (very skinny) version, without all the network replication?
I already use Gameplay Tags in my UtilityAI. It's a fast and convenient way to poll / ask questions, so that's a no-brainer: the Player State should allow queries via Tag Sets. I've implemented the interface and written a small set of helper functions that I also added to the Blueprint Function Library.
What about Gameplay Effects? A decent first pass would be the Wand charge. It’s a trivial effect: add a value, applied to an attribute: wand-charge, over time. So I added an Attribute Set to the Player's State. But... I need something in the world I can collect.
The rest of the day was spent writing the Pickup Object interface, base class and base Blueprint. My current test object is the Wand Collectable. I'll get back to the Wand Charge, tomorrow.
Continued rolling my own skinny wrapper for Attribute Effects. I've now got effects (instant and timed) that can alter Player State, be blocked or killed by the Player's active Gameplay Tags, and as a Brucey Bonus, I get the Editor UI for attribute selection for free, via FGameplayAttribute. It works like a charm.
I think the only extras I may need to add are: effects that apply Gameplay Tags over a duration, and the possibility that effects could spawn other actors (Gameplay Cues-lite).
This is player focused atm, but if it works, I'll split it out to a plugin. The only bit of data-coupling happens in the editor -- selecting the Attribute -- so it should "just work" on any Attribute, in any Set. Maybe.
Friends:
If you like any of my work, please consider checking out some of the fantastic games made by the following super talented people:
