This post will show the development of my hand selector system.
Initially, as shown by my previous post, I had ideas of making the selection of hands radial based. However this seemed a bit too generic and didn’t fit with my design philosophy of augmenting hands into a gameplay feature. With that in mind, I gave it some thought, and eventually came up with an idea for the player to build their hands using blocks, with different outcomes depending on the combinations.
I did some digging for features that could make this system work. I was briefly playing with the idea of using arrays and collision enter functions, but eventually I found some decent documentation on XR Socket Interactors, and I made my system using them. The hand would initially start off as a simple base, with sockets to place different building pieces as shown below. I wanted to keep the sockets to a minimum to make the concept easier to follow, as well as code, so I based it around 4 main sockets.
The player would then build up their hands into certain structures, and when the parts were in place, they would function as the built hand should.
My first documented issue implementing this is that when pieces were slotted into the hand itself, the collisions would launch the player back at rapid speeds, pushing them away from the designated area they were building their hands. It took some time troubleshooting, but eventually it turned out to be an issue with the XR collision radius.
With the system now working in testing without issue, I designed a simple sheet to show the player their options in what they could build with the pieces, showing them the process of making their hands, swords, or claws.
The reset button below simply reset the scene in case the player incorrectly built their hands at any point.
With the design concepts out of the way, it’s time to talk more about the code that makes this work. There are two/three main scripts in play that I designed to be used to create the hands here.
The first we can call the Hand Selector. This was the primary script called in the other two, and was the one swapping the hands out correctly once built.
To start, I had to use multiple bool values for this system to work correctly. There needed to be separate ones used for the hands, as well as the tools. Above all the bools, I also made sure the call a few game objects to swap between or toggle active where needed.
The screenshot above is the core code, using if statements in the update function to determine what hand to swap to, when to hide the base hand, and when to hide the game object of the fingers to create the illusion that the hand was built.
The next scripts are the Hand/Tool selectors. They share many similarities, but are used for different processes.
For my system to work, I needed to limit the places where certain pieces could go. To do this, I made a function that a socket piece could only be slotted in if it shared the correct tag chosen in the selector. This worked well to limit the options present but still allow the player enough freedom to build.
Calling the bools present in the Hand Selector script, these if statements set certain values to true depending on the tagged part that was socketed correctly. In tangent with the Hand Selector script, this meant that once the correct combo of bools were true, the hand would be made successfully.
The tool building script is a carbon copy of the hand building one, with only a slight change to the specific bools it would change. This is due to this script being present only on the child sockets attached to certain pieces that are used to create the claw of sword, meanwhile, the hand builder is solely used for building the hands. This was made this way to get around an issue I was having where certain bool values were overlapping each other, causing problems when trying to build anything.
Here’s how it looks with all the code in play. The sockets pick up only pieces with the correct tags for them, and when they do they set their assigned bools to true. With enough bools set to true, the pieces are hidden away, the base is deactivated, and the claws are put in its place, ready to use. From here, certain functions will be based around certain hands being active, giving the idea that players need to create certain tools to solve certain problems.