Archive:

Subscribe:Atom Feed

"Lumo Journal: Week 50"

Posted: 07 May, 2024

Lumo Journal

07.05.2024

Finished off the Portals in Sandy Whites (so you can move between rooms), and blocked out a little test-space as the second room.

I want to get the player to use the right stick to unscrew things, or spin them around, as a warm-up to when I unlock the camera and give them full rotational control. This threw up a couple of brain scratchers:

  1. What’s the best way to bind to an Enhanced Input Action and get its value, every frame?
  2. How do you actually work out how many degrees the right stick’srotated?

Point 1 took me while, but eventually I found FEnhancedInputActionValueBinding, which can be setup in the PlayerController, along with a getter, to return an FVector2D of the current stick value. (I veeeery nearly used the Gameplay Messaging Runtime… :D)

Point 2 required the judicious use of atan2, which is about the limit of my trigonometry. It took some doodling on paper, but I’m able to track 360 degree rotations. Tomorrow, I’ll extend it to handle wrapping past 360…

Stupid maths.

The UI’s appearing, but not yet animating when you move the stick…

08.05.2024

My Screws are slowly shaping up into a nicely re-usable thing. I can track an arbitrary number of degrees rotation of the right stick, and “complete” when the screw’s been rotated by the correct amount. If the player walks away before then, the screw unwinds, back to zero. Each update, the rotational delta is shouted out as a Gameplay Message.

The UI’s animating, which looks cool, and I’ve made a base class for actors that want to respond to Screws. Screw Responders can pick which screw they care about (by UID, that forms part of the payload of the Gameplay Message), and set an internal scalar to apply to the received deltas, allowing them to rotate in any direction, by any amount. The first instance is an actor that rotates a Static Mesh.

09.05.2024

Megan Fox’s blog post – the one that inspired me to check out the Gameplay Message Runtime – was actually describing how they’ve implemented generic Switch and Switch-Twiddler interfaces. I have switches and buttons (along with event responders) but my focus was on the behaviour of the physical actors in the level, not a generic solution, such as the one they described. And I like the sound of Megan’s, so I spent the day doing my own version; FoxySwitches and FoxyTwiddlers.

To paraphrase the original blog post [https://www.patreon.com/posts/switch-systems-99406783] - Switches have no real logic, just SwitchOn & SwitchOff events. Twiddlers do have logic, and it’s this that turns the switch on or off.

Above that, I’ve implemented

So basically, the set as Megan described.

The above shows a TwiddlerMessengerListener that waits for a message from the Screw I implemented yesterday. It’s linked to a Twiddler, that’s linked to a TwiddlerSequence, that’s linked to a TwiddlerChain, that has four FoxySwitches. The switches spawn a pickup. The timer in the chain makes them appear one-by-one, rather than all at once.

This is a cool system, and having now messed about with it, testing my implementation, I can see why Megan’s ended up sticking with it through so many games.

Previous Post: "Lumo Journal: Week 49" Next Post: "Lumo Journal: Week 51"

Friends:

If you like any of my work, please consider checking out some of the fantastic games made by the following super talented people: