Preparing for analytics

The analytics we are planning to gather from this playtest are a few things. We are collecting the positions of the controllers and the head every 5 seconds, the objects that are picked up and when they are picked up. We also want to record when the player interacts with the object to see when they need to read clearer text rather than the handwritten text. However, the ui is not yet functioning fully, so that is yet to be implemented and may be removed in the end. The reason we want to record these things is to know more about the players movements and what they interacted with. Because the game is about finding hidden secrets, it’s important to know what they found and how much they paid attention to it.  It is also nice to know where the player went to see if they went to the space of a secret but never found it. For example, one major secret requires a few steps to gain access to it. First you have to find one of the three places in the room that a 3 number code can be found, these being on a sticky note and on t. They the have to two pieces of paper (the sticky note having it underlined and the papers being part of a 6 number code they then have to take that three number code and put it into the lock on the chest, something that should not be hard to find. They then need to open the chest and pick up the objects inside. This process could have hiccups, so we need to know what they interacted with and when to see what told them the code and whether they recognised it when they saw it. Looking at what Nic Lyness experienced from his analytics it seems that he was only able to gather information about position and guidance rather than writing through his analytics. He was able to use a survey to figure out whether or not his writing was insensitive or missing the mark. So, I think that it may be difficult to get the right information about people’s thoughts without a questionnaire, but that will just be a limitation set upon me that I’ll need to work around. You can read about his experience here 

I hope to use the information that I can gather to better position or signpost secrets depending on their level of importance. But only time will tell what I can change.


Management plans

With this new project, it is clearly a good idea to try and get our project management sorted out. Looking back at our previous game, we had some pretty decent project management. Izzy was our project manager and he did quite well at keeping in touch with all of our team, including our collaborators. However, I often was unsure about what to do next, and decided to go forward and do what I thought needed to be done. However, while this was an issue, the project was still delivered on time and was working full. The only things that could have been done would have been further extensions of the game, rather than features or polish. For project 4 I would like to take this level of communication with our collaborators if I can. Because it constantly felt as though they knew what was going on and I felt like I was aware of their progress at all times. I would also like to improve the work list so I and my team can better know what is needed to be done. To do this, it is important to have a larger list of what needs to be done, and also an order of priority. This should let us create lists of what needs to be done in each day and should let us move on to more work if we run out and find ourselves needing more to do. This could be difficult though because it will require us to think about our project in a great amount of detail before it comes time to implement it. Because it is almost impossible to know all of the needed elements at the start of working, we’ll need to be able to update this list as we go. This could bring about issues because it may result in feature creep. I am a little concerned with how I will be able to implement this because I will be the sole designer on this project, so taking on that role as well as being the project manager will almost definitely be too much for me. So it will be best for another member of the team to be the project manager. This will probably result in slightly different methods of project management, but for the sake of my sanity, it will need to be done. Being the vision holder I would not do well being the project manager, because the game would definitely be wrought with feature creep. But, even with all this preparation and consideration, we will clearly run into more problems and so can only be so prepared.

Demoing VR

So, in the coming weeks I will have to demo my VR game to a public audience. What does this mean? Well, other than the sudden rush of anxiety, it means I have to introduce a lot of people to VR and set them up with the headset so they can experience the game in the best way possible. This can be more complex than it appears. Most people haven’t even experienced VR yet, so playing this game will be the first time they’ve ever experienced it. Because of this, it’s important to teach them proper care for the headset, and to overcome their urge to put the everything on at once, especially with the vive. There is a specific order to putting on and and taking off the vive headset so you can get the most comfortable experience. Often this means having someone else to help. The first step is to put on the headset, but because everyone’s head is differently shaped, it needs to be almost fully loosened, then placed eyes first with the straps loosely over the head, allowing the person wearing it to hold the headset at a comfortable position, and then tighten the straps on their own or with help. For demoing, I, or a member of my team, will need to be the person helping. So once the headset is on, the person needs to have their controllers. For anyone waiting outside the headset, it is best to hand the player their controllers by holding them upright by the base. So that the person inside the headset can easily take a hold of them without interference from the person outside. But it is important to make the player take a step toward the controllers to get their mind into the room scale experience rather than standing still for the whole time they have the headset on. Since I am going to be using someone else’s vive for this demo, it will be important to use the wrist straps for comfort of the player and the owners of the vive. To handle this, I believe it is best to hand the player the controllers one at a time so they can use both hands to put the wrist straps on, without having to juggle two controllers. Now they’ve got their controllers and the headset, they need headphones. These need to be separate to the headset initially so that putting on the headset has one less cluttering object. But when the person assisting needs to give the player their headphones, they should approach from behind, and continue to talk to the player telling them they are going to put the headphones on now. Plugging in the headphones first and then placing them on the player’s head.

So now the player is all set up with the game. But do they know what they are doing, mostly with the game, it should be set up to be self explanatory. But one thing that is important to teach them is the chaperone system. If they don’t know what this is, they might get confused or ignore it entirely. So to introduce them, it is best to let them discover it by walking forward. This can take some encouragement, so it is best to tell them to take a step at a time until they see the blue. Once they see it, then the person outside should tell them that the lines are a representation of their playspace, and that there may be people outside it. But how do you talk to them when they’ve got a headset on and are in a loud room without shouting at them? An inline mic is the solution to that problem. We can use it to talk to the payer calmly and without shouting to give small instructions if anything were to go wrong.

So now the player can play and can be given instructions when things go wrong. Now they can start playing. But it is important for the demo instructor to pay attention to the player so that they know when the player is ready to finish and start the process of taking off the headset. This being to take the controllers first, then take their headphones allowing them to take the headset off themselves. Once you unplug the headphones and put both the controllers and the headphones down, you can take the headset from the player. It is important to pay attention to the player because they may want to stop playing quickly and will want to pull the headset off first. So it’s important to be ready to take things from them quickly.
My team and I will need to pay attention to these things when we are in our upcoming demonstration to create the best possible experience for our players. Here is a video explaining more about this demoing process: