Tag: year 2

Well…my project is done.

As of writing this, it is currently 4 am. I am finishing up any simple tweaks to the project, and cleaning it up to submit in a few hours.

This project was the first time I had full reign to design and create whatever I truly wanted in VR. The creative freedom was initially quite daunting, but over time, I understood how exhilarating it was creating my own concept and seeing it come to life over the months.

So, did I make hands into a game mechanic? Yes, I think I did.

Doing some research, I couldn’t find any other VR titles with a feature similar to mine, which I am very happy about. I was able to create a way players could take their hands – the core way they are represented in VR – and change it to suit their own needs.

I will admit the system ended up being a bit more limited than I had hoped. Initially, I wanted the player to be able to remove and reattach their fingers whenever they wanted, not needing to hit a reset button. Although, as of typing this, I already can think of OnCollision functions that could possibly allow this effect, so for now I will just chalk it up to lack of experience and time.

Coding was a bit challenge for me in this project. In the first year of the course, I figured out quickly I enjoyed 3D modeling more than other areas, and tried to focus my efforts on that primarily. However, if I ever want to get further into the industry, an understanding of other areas would always be beneficial. And so I decided I’d dedicate my time to coding more for this project.

Now don’t get me wrong, there were plenty of times I regretted doing this. A few errors that made me pull my hair out usually ended up being a capital letter missing, or an !. However, at the end of the day, I find myself much more confident in C#, and know I have the knowledge to work in it to make what I need.

And after all the hard work, the project works. The code is ugly, and the physics questionable, and many more issues I could find if I looked hard enough…but it works, and that means everything to me as someone who can rarely say they have accomplished anything as big as this.

I want to actively develop this system more. I say that about a lot of my projects, but I think I honestly mean it this time. I want to make it so you can reattach fingers on the go, I want to add different combo’s for new tools, and I want to make a full fledged VR experience out of this.

I’m not sure how busy my summer will be, but if its open, I might hop into Unity and keep working on tweaking the system to perfection. Heck, maybe I can make the full game my project for my final year.

I loved making Hybrid Hands

This post will talk about how I developed the final function of my climbing claws.

This video was my primary resource for making this system work, and came out right at the time where I was considering scrapping the feature altogether.

A lot of the videos I could find detailing how to make this system worked struggled to be applied to the latest versions of XR in Unity, but as my luck would have it, this youtube – whom I followed – put out a video on how to get it working in the most recent versions.

Velocity based building functions are something I still am very new to understanding, and I’ll be honest and say a lot of the development of this system was simply following that video directly, but as expected, there were a few elements that required tweaks to work with the systems I had in place, as well as a few errors that stemmed from the smallest things like a ! in the incorrect place (that’s coding for ya!) but eventually, I got it all working.

This is the climbing provider script, which is attached to the locomotion system of the XR Rig. The primary functions are used to determine when the system should be registering and adding velocity values for climbing, and when it shouldn’t. The technique of using an if statement to register whether the correct hands are active also returns here.

This script above found in the climbing provider is the one that alters the players position based on calculations of the velocity of the player. A VelocityContainer script is called here, which is used to register the velocity of the selected XR controller when the XRI settings are edited correctly.

The climbing anchor script above is shown here, and is applied to the climbing wall objects. This function calls the ones used in the provider, and links them to when the wall is grabbed by the player. With these two scripts running together, when the wall is gripped, the climbing provider begins registering the velocity of the controllers, and then uses that to elevate the player.

Besides these two scripts, there are a few miscellaneous ones used to make sure the gravity of the player functions correctly.

I definitely think I need to learn more about systems like these. Climbing in VR is an interesting mechanic in any experience, and the more I know about implementing it correctly, the more experiences I can apply it to in the future.

To begin this blog post, I will outline a few tweaks given to the sword system.

As stated in my previous post, I found a way to limit this feature only to when the sword hands are present.

This if statement also shows my solution to a few other emerging issues with the system. The collisionDetect bool was created due to the cutting crashing my computer, as too many cuts would occur if the blade stayed in the middle of any object for too long.

With this code, the cutting is reliant on the bool being false. Whenever a cut is made, the bool is set to true, and only made false again when it is no longer making collision with an object. This means it can only make one cut at a time.

The gameObject tag area of the if statement sorts one final issue where the swords were cutting objects they shouldn’t, such as pieces of the hands, or blocks for other mechanics. Having it so it can only cut tagged objects is a simple fix.

One last change was I added this line to solve a problem I was having with cut pieces falling through the floor. This adds a box collider to new pieces so they no longer do this, however it can cause some issues with collisions, as the newly generated box colliders can sometimes be too large. Perhaps I can look into a way to make the colliders more accurate to cut pieces.

So that’s the alteration to the sword out of the way, the next topic of discussion is the development of my scene.

Initially, my scene was very basic, with the UI hand selector, a box to cut, and a wall for eventual climbing. And while my project is primarily a system demo over a full game, Herman gave me some advice to develop my scene.

I started off initially by browsing some of the asset packs I had previously purchased here and there on the Unity asset store, eventually creating a simple scene out of some voxel based buildings and roads that matched the look of the hands.

I also added a skybox to just give the scene a better overall look, but it was definitely an improvement and wasn’t too complicated to draw away from my systems.

Next came the organization of the mechanic areas. I wanted to separate out different areas for each hand to be tested, setting up small obstacles for the player to test out trying to get past. A suggestion from Herman came later to make these zones color-coordinated, to make it even easier for the player to know where to go.

A small thing related to the scene development also relates to the function of the hands. Initially I was having trouble finding a way to code it that only the hands could push the green boxes, trying to use IgnoreCollision functions. However, I learnt that I could achieve the effect I wanted a lot easier using the built-in layer collision matrix in Unity. This system allows you to limit which layers interact with each other.

After all these changes, the scene looked and functioned a lot better.

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.