I’m doing a sort of work-in-progress update here, because even though I haven’t added anything to the actual room, I made some progress on changing the code to do some extra bits.
I added a replacement for the Grabber component, to be a more generic Interact Component. I wanted to have a way to interact with all types of objects (not just the physics), so changed to use a different trace method:
GetWorld()->LineTraceSingleByChannel(
OUT HitResult,
GetReachLineStart(),
GetReachLineEnd(),
ECollisionChannel::ECC_Visibility);
With that I can test if it’s a physics body
if (ComponentToGrab->GetCollisionObjectType() == ECC_PhysicsBody)
and treat it the same if it is. If it’s not, I check if there is a switch component on the actor it returns. I get the switch component, like so:
auto MySwitchComponent = ActorHit->FindComponentByClass<USwitchComponent>();
What’s a switch component? A new Actor Component class I added that stores a boolean value, and can return it, set to true, set to false, or toggle, all through public methods while keeping the bool private.
If there’s a switch component found, the Interact function (aka, a slightly boosted Grab function) calls the Toggle for the switch component.
Elsewhere, there’s a means to set an actor as the activator on an OpenDoor component (the pressure plate functionality is still there, but this is in addition, as an bitwise OR.
All it takes to have an alternate to the pressure plate is to open the OpenDoor component on the door, pick an actor from the world to activate it, and add a switch component to the actor. The Switch can even be added to itself this way.
Separate to that, I made a horrible mess of the OpenableDoor_BP Blueprint, for a good cause.
First, the BeginPlay:
It’s setting some extra variables, with the notably new and outright peculiar ones being these Location Multiply and Rotation Multiply. I think that’s self-explanatory enough, but here’s the actual implementation. It would probably do better to move some of these back to the C++ class for OpenDoor, but it’s not too muddled just yet.
Okay, maybe a little on the “could use some refactoring side”. Yes, this will allow a door to rotate along any axis, or move along any axis. Technically it could even do multiple axes. To make it more extensible, I also adjusted the Timeline to work on a scale of 0-1, so that all the rest is handled by multipliers that can be set on individual instances of a blueprint.
And since the blueprint instances let you swap out the static mesh of the door for some other kind, you can make things like working cupboards, doors you knock down, or extending platforms.
Other than making the code all neater, and actually using it for a decent escape room game, the only other bit I’d like to add (which shouldn’t be hard) is a setting on the switch that makes it a single-fire. From here, I think I can probably make an interesting escape room, and hope to have progress to share on that front in the near future.
