The communication in the example revolves around Inheritance + Interface - a potent combo, imho.
- the base class implements the interface (which children inherit)
- the widget uses the same interface - calls children receive can be propagated: Actor → Widget Component → Widget without casting or finding user widgets (this can be done in many ways, though)
- the player has a collision sphere and sends an interface call to overlapped actors as we approach:
Above, handling in the target shows / hides its widget component.
- the Look At - when the trace hits the actor, the message is propagated to its Widget Component’s widget:
Above, the widget updates its look after receiving a propagated interface message.
In short:
- proximity shows / hides the entire Widget Component
- tracing an actor affects how the underlaying 2d widget looks
The logic is set up in such a way that it does not Tick the whole thing, it sends a single message when needed:
This can be optimised further, ofc - Gate tracing to execute only if there is something in Proximity.
Project link: interactiveProximity.zip - Google Drive
Other notes:
- using a custom trace channel - everything blocks it (so we can’t look at things behind obstacles) but the player ignores it (so we can trace through their capsule). More flexible somewhere further down the line than mere Ignore Self [T]
- inheritance + Interface shines: everything can be LookedAt and Prodded, but only the pyramid can be equipped. A natural system for the generic
Press E to Use- what use means depends on the actor with the function implementation which can feed data back to the player.
what’s your approach to the text?
Noticed something uncanny, eh? It’s a Widget Component in Screen Space but the gimmick is that it’s attached with a Springarm with Absolute Rotation.
Reasoning : it makes it trivial to offset in Z (even when things tumble around) and a bit of interpolation the camera lag produces makes the text easier to read when the owning actor is on the move. Feels really easy for the (my) eyes to track. If I were serious about this, I’d probably just place the component at the end of a local vector rather than use the expensive springarm - but it’s more fun this way.
It also makes any sudden changes of velocity appear more impactful as there is now a better point of reference. It might as well be a love / hate thing tbh, or utterly useless - depends on the purpose. Not sure whether it’s of any use for serious stuff. Definitely gives off a whimsical-cartoony vibe.