Intro
The Water Tester, in the context of VR, is part of a sequence of steps that must be taken to progress, alternatively called a puzzle:
- Take a Beaker from the top.
- Place it (upright) in the empty slot under the Water Sampler, indicated by the empty spot that seems to be whiter than the rest.
- Press the button above it to fill it up with water.
- Take the metal rod on the table with one hand.
- Optionally, take the beaker out with the other.
- Place the metal rod inside the beaker.
- On the Water Tester, press the start button, in this case, the left button, to start the calculations.
- Wait a few seconds. Have some information pop-up on the small display.
- On the Water Tester, press the print button, in this case, the right, to have more information be printed on the larger screen.
And this has to be repeated 2 times for 2 different water samples, produced by 2 Water Samplers, not visible on the picture.
To achieve all this – I thought about this for a while – and decided I should approach this as organically as possible, however, my sick brain deciding to do something probably very dumb. You’ll see why when you continue reading further down.
In our current build of the game, we have an Activatable/Electric Signal system that “activates” other objects that we can choose. However, at this point we only had the button send out these signals, but we also had Slots that you could slot objects into, think of the Slot as the keyhole for a key, that didn’t do anything currently.
So, I decided to expand it to allow for that functionality. Initially created by @revenaant, we discussed some possibilities. He agreed to allow me to expand it to suit my needs if I needed it.
Slots, Keys & Locks
Following the first few steps is easy enough, we already had grabbing, just needed to make the beakers interactable, which was easily done. Placing the beakers under the Water Sampled seemed tedious in testing, so I added a slot for them so that they would stay nicely in there, howeve, I realized something – they would be permanently locked in place and uninteractable during runtime – aka I wouldn’t be able to pick them up anymore.
I decided to update the code so that I would be able to slot items without locking them – I modified both the Slottable’s (to allow it to not lock) and the Slot’s code (to provide the interaction for not locking). This can be seen in the below pictures.
With that I managed to get the keys able to be taken out, however, due to some collision issues (later resolved) my VR avatar’s hand couldn’t pick up the key. I resolved to just push the key out of the slot bounds (with another key ironically), after which I was able to grab the original key.
While satisfied with my progress and the collisions issues resolved, I wanted to future-proof the Slots a bit – currently Keys were a Blueprint which consisted of an Unreal Actor, which held no special functionality but rather only an Actor Component, specifically the Slottable component, which was the one that held all Key-like functionality, such as the ability to slot & lock itself, which was in itself triggered by an external interaction, namely from the Slot. This did not make sense to me, and to be fair, me and my programming partner are pretty new to Unreal – I took the initiative, talked with him about it, and we decided to make Keys just Actors with the Slottable components as the components are the things in the level that will actually interact with the Slots. I did not delete the Keys – just merely changed the code to allow for multiple keys as Actors. (praise the eye-dropper tool in Unreal Engine)
The Buttons
The Beaker
The Slots Are Back With A Reckoning
Other Experiments
Key Patterns?
While toying around with various ideas, Unreal’s visual scripting interface and the slots, I mentioned I was unsatisfied with the way Keys initially – they were their own Actors with just a Slottable component. I looked into the Unreal Documentation to try and think of a method for more sophisticated ways to check for keys.
I thought about creating an interface to do it for more customizability, then to use a struct (in Unreal Blueprints called a User-Defined Structure), then in Unreal Objects. I wanted to have the struct inherit & implement the interface, however, Unreal Structs cannot inherit and they cannot have any functionality, as they merely served as data containers. For my goals I researched Unreal Objects as well, as online it was mentioned that they were often used as data containers with the benefit of functionality, however, and this is also another place UStructs failed me, I wanted them to be persistent objects I could access and reference anytime. That proved impossible because I could only create instances of them in code, not as assets or parts of a level. Mentioning levels, I briefly considered using Actors as key pattern holders, however, the whole process of defining a key would become way too tedious, so I settled on just having Actors.
If I had had any success with these data containers, I would have likely created a boilerplate object similar to Activators to hold keys. And that was very obviously a bad idea in hindsight.
SDG Escape Room 