XR Summary

What have we learned? Through the XR toolkit example, we are able to simulate real XR devices. In this case, we demonstrated the MetaQuest 2 and controllers and how we can do a recording and use that for a replay. We can also simulate gamepads bespoke devices using any sort of layout that is recognized by the Unity editor, just by exporting that layout of the JSON and loading that up within our test script. We can record gameplay as a starting point. This is an important piece. If we were to handcraft that test, which is possible by the way and was one of our methods of doing so prior to the introduction of the recorder. It was very difficult and it was very time-consuming where we would probably teleport around the room and perform the same sort of actions, but in a much less sort of granular manner. Discovering those positions can be tricky. So you would have to physically move to a position in a scene. Check the project as it's running to see where am I in the scene, capturing those values precisely. And then using that in your tests for replay. It can be a little trickier. The initial position, which I didn't talk about during the recording, is key though. So that initial positioning, I talked about my height, but also it's important to know where I was in the scene at the start of that scene. If you go back here in the XR origin, which is the container of the camera and the left hand, right hand main camera, and this is going to be consistent pretty much across projects, you see XR rig or XR origin or something similar to that being used, which contains all of the sort of player or user behavior as camera behaviors, tracking, etc. The initial position of this is very, very important. Let's say if I look at the position here, which is -1.8, -1.2. If I were to adjust this in any way, if I was to start the replay from a different position in the room and then start the recording or start the replay of that recording, it's going to perform all of those actions as if I'm starting in the wrong place. So we're either setting this as part of the start of the test or we're making sure that this starting point is consistent from our recording to our replay. It very important. And then we want to validate features and then gameplay. Now this is something I've mentioned a few times during the course of this recording is that we want to validate features separate from gameplay because features that can get in the way of gameplay. We want to make sure that if a test fails we're able to determine was it a feature or was it part of the gameplay, was it, the weapon that I couldn't capture that didn't go in or didn't enable attacks on the character or did the test fail with the chompers because I was moving around the scene and hitting things and nothing was dying. So it's important to understand that those things are distinct. We want to test the feature of getting the weapon and that it enables attack separate from using that weapon to perform actions. And the same applies here in the XR example. For example, we could put assertions into the test to say, when I put the key into the lock, does the drawer open? Does it enable me to open the drawer? which we didn't get into here because of the amount of time involved in doing so. But each of those steps is separate from the gameplay itself. So checking that the lock opens the drawer, the drawer that contains the book, the book goes on to the pedestal, and the pedestal in turn actually enables teleportation, as you can see in the screenshot here, which would be another distinct part of the test. And then if there's a subsequent test that requires teleportation around the room, which is what would be necessary if we were to complete testing this project, we would want to separate that from the initial test. We would probably do the tests that I demonstrated, but then create another one that doesn't depend on that passing, doesn't depend on the book on the pedestal, but just enables teleportation around the room and then does so.