Archive:
Added code to transition between maps [levels], and hooked it up so you can walk through the teleporter in the Hub, appear in the Moonbase, then teleport back to the HUB.
I’ve got a couple of cutscenes in the game, but no top/bottom border bars to indicate that I’ve taken control away from the player. Made the UI widget for them, and knocked up a quick transition animation. Then I had a crazy idea about how to trigger them… Rather than calling an event in the Hud, what if the Hud bound itself to the Player State’s Gameplay Tags, via delegates? Every time a tag is added (or removed) the Hud would see, and could make some choices about showing and hiding the appropriate UI elements.
And it worked, perfectly!
Man, I love Gameplay Tags, they’re bog simple and stupidly useful.
Had a look at adding double jump, which ended up being a few lines of code… implemented via… Gameplay Tags. :D
Implemented height-based textures, so now I can have things at the top of the room that the player won’t see until they get high enough. Well, unless they know what to look for in Lumen and the ray traced Ambient Occlusion…
These work in two ways: via grounded height, so jumping won’t expose them, or via Gameplay Tags, so floating down from on-high, will.
Modelled some walkways at the top of the Main Deck as a test, and made some new anodized metal materials. Gotta be careful with metal in this environment; the Sky Light is super bright, and there’re no directional lights. Things white-out very quickly.
Sketched out a code interface for Force Based Interactive Actors – fans, springs, hoovers, conveyors – and began working on the springs that’ll throw the player up.
I thought the spring thing would be easy, but it was a lot more subtle than I expected. I ended up in a good place, though.
The plugin defines a set of Gameplay Tags that identify if a force is constant, or one-time. This is my first foray into C++ Native Gameplay Tags, so there was a lot of digging involved; it wasn’t clear how to expose them to the game module, from the plugin, and then use them, but I got there.
The plugin also defines a code interface that anything (but specifically the Player Character) can implement if they want to respond to “forces”. Through this, and the tags, I was able to make a spring (encapsulated entirely within the plugin) that caused the player character to bounce. That’s a bigger deal than it sounds (at least to me) as it unlocks something kinda powerful. I’ve got a new tool in my box.
Anyway, it caused some subtle bugs in the animations, and how the character transitions from a jump’s apex into a float. Which in turn uncovered an edge case in the things yesterday’s height-based materials were tracking.
But I fixed everything, and in the end, very little code changed. It’s damn time-consuming stepping through multiple Finite State Machines to see what is happening, though.
Lots of plussing, today:
The last one is pretty cool. I added an Actor Component to the player character, that listens for Gameplay Tags being added to the Player State. If a Tag maps, the new component spawns audio and vfx at the player’s current location.
It’d be nice to reserve Fridays for plussing. The build’s feeling a lot better, which is always a nice way to cruise into the weekend.
Friends:
If you like any of my work, please consider checking out some of the fantastic games made by the following super talented people:
