High Concept Document
Our High Concept Document (HCD) outlines the overall concept of the story, including our goals, target audience, unique selling points and competition.
As part of creating the story, a number of different assets needed to be created. To do this, we created an asset list for which we can track who is working on what and what stage they are on. I myself worked on creating the corridors, assets for the final evil ending room, a lab machine and one of the beakers.
I blogged about creating the corridors in a separate post which be found here.
The creation of the lab machine is my most complex model and animation utilizing a number of various techniques and tools to create a fluid animation and clean model. The model is also UVW Unwrapped to allow for custom created textures that suit the model.
To start, the arm rail and the arm itself was modelled so I had a rough idea of how big it would be as well as what I wanted to happen.
To create the rail, I first created a Spline using the Arc default then edited the spline to add straight lines at either end. To ensure the arc was smooth as well as the lines were straight, the snap settings were enabled with the snap points set to the grid points. Although editing the spline to add the straight lines worked, it created them with new vertices so to join them to the old ones, I used the Weld tool.
Once the splines were created, I then applied to Sweep modifier to it which is basically where a shape (or another spline) is extruded along the path. As I wanted to create a sort of grip railing that the arm base would run in, I used a default shape and adjusted the settings so it was in the position and orientation I wanted it (Flip along the XY axis).
To create the base of the arm that would run along the path, I can extract the general shape of the inside of the railing. For this, the Edit Poly modifier was applied to the railing then the edges on the side were selected and turned into a shape using the Create Shape tool. From there, I could edit the shape (which was basically a spline) to add the missing edge then apply the extrude modifier to give it thickness.
For the arm itself, it was created as a cylinder as a separate object which was then extruded multiple times. Around were the arm would bend, extra vertices and edges were added to prevent weird distortions when animated. This was repeated until there was one main bend and a bend at the end for where the fingers would be. The flat base on the end was created by using the Outline tool to expand it then the Slice tool was used to split the end into multiple faces. To ensure that the slice tool only affected the end, the end face was selected first.
The fingers were then created by extruding the faces out, moving their position outwards, then using the bevel tool to extrude and effectively scale the face at the same time.
The enclosure around the machine used mostly the box modelling technique to be made. However due to the unique shape of it, it did require a bit of manual work to get somethings how I wanted. For example, the entire front faces of the machine needed to be recreated as some was overlapping. To do so, I delete the face then using the edge selection mode, used the Bridge tool to then create faces across the selected edges.
I also used the Slice Plane tool to create extra edges, such as on the front for the slant, where required.
The lab machine itself has two different UVW Unwrap modifiers applied to it, one on the main enclosure and the other on the arm. This was done so specific detail could be added to the model without stretching other materials. UV mapping itself is a fairly simple idea in that it matches up a specific point on the texture (the UV) with a vertex on the model. It then repeats this for every vertex until they are all mapped to a coordinate. The best example of seeing this is by looking at an OBJ file format where it pairs up UV co-ords with specific vertices.
To make the arm animated, a bone structure was created that followed the layout of the arm. The root bone was made a child of the arm base so that it would follow it when the base followed the path animation of it moving around. The bones in the fingers were set as the children of the bone in the hand.
To make the arm move in a more natural way as well as to reduce the workload of manually animating it’s position, an IK (Inverse Kinematics) solver was setup between the hand and the base of the arm. The idea of IK is that instead of the parent affecting the child, the child affects the parent instead. This is perfect for a limb style bone structure as it can make a somewhat natural looking animation. This solver in particular is a HI (History Independant) solver which means that the angles of bones are not restricted and each movement is recalculated as new. Compared to the other main one, HD (History Dependant) solver which is where the angles can be limited, it offers more freedom however some of the movement can be unrealistic.
However one issue I ran into with this method was that is was causing the hand bone to rotate to try and fit within the solver which I did not want. To solve this, I added an Orientation constraint to the base hand bone with the orientation target set as the world. This means it will always keep its rotation the exact same as the world which for my situation worked out perfectly. I could have used the LookAt constraint instead to look at the cylinder however it caused a few issues for me.
The arm base itself is animated via a path constrained animation. This means that the object will only move along a predefined path for the period of how long it is set to do. In this case, I can reuse the spline from when I made the railing for the path to save on a lot of time and reduce possible issues from minor differences.
As I wanted the path animation to not be a linear speed and instead adjust, I changed the animation curve on it from Linear to Bezier by right clicking the path constraint in the editor and applying the Bezier controller to it. This allowed me to slow the animation down at the start and end of its movement and create a more natural look.
Model File: Download
There are numerous assets in the evil ending room, both 2D and 3D, to create the scene. I’ll be mostly focusing on the 3D assets and animations as the 2D assets were created in Unity itself with it’s UI system.
The lever itself is the main part of the room and clearly stands out compared to everything else in the room. The lever is animated so that it flips down when the player interacts with it and flipping all of them triggers then end scene.
The base of the lever is a box that then had the edges chamfered to created the slanted look. The texture on the base is also UV mapped using the box projection to reduce the stretching of the texture and make it look more natural.
To create the handle and bars, a cylinder was created then the end edges selected and the chamfer modifier applied. So that a rounded edge is created instead a flat, the chamfer type was changed to square, the tension reduced to 0.5 and the number of segments increased to 3 to give a smooth look. The bars were extruded from one of the cylinder until they reached the desired length.
The animation for the lever flipping down is a simple keyframed one. An initial keyframe is made of its starting position, then another keyframe is made a few frames later in its final position. However to create a more realistic animation, I adjusted the animation curve. This affects the “speed” of the animation so that the lever will move slower at the start as you pull it down then speed up once you would start pushing it down, creating a more realistic effect.
To adjust the curve, I opened the Curve Editor in 3DS Max then adjusted the Bezier handles connected at the first and last frame. This could have also been done in Unity using a similar process.
Now that the minimal viable product for the story has been completed, we can then conduct a usability and playability test to see if there are any issues both with the design and program. This usability test will see if there any issues interacting with the interface, to see if there any level design issues as well as how well the Leap Motion and Oculus Rift DK2 enhance the story.
Before we can conduct the test, we need to plan out what we wish to test and how to then run it to reduce any possible bias in the results. We will also need to plan out how many people we should aim to test it on and how the tasks will be given to the user.
To start, we decided we should test the UI as it involves using the Leap Motion which is a very different way of interacting compared to the standard input for computers. It will allow us to see if the user can quickly pick up the idea of using their hand to interact with the world as well as then using their hand to control the UI.
Another aspect we decided to test was how viable the DK2 is and how it enhances or hinders the users experience. For this, we asked if the text on the UI was visible then if they believed it enhanced their experience or if they experienced any motion sickness.
We also will ask the user how they find the story as well as navigating the world. It can identify weak areas of the level design as a poor level design could mean they miss aspects of the story.
At the start of the test, we briefed the user about the overall goal of the test as well as what is expected in terms of feedback from them at the end. They was informed that no help would be offered unless asked for and once a task was complete, we would let know and move them onto the next task if required.
For the test, there would be 2 observers who would make notes about what the user is saying as well any difficulties that we may have noticed the user experience. The use of 2 observers is to reduce the load on just one as well as reduce the chance that something is not missed.
To collect data from the users regarding the test, there are methods we decided to use. One is asking them to complete a questionnaire after each task is completed, this is so that it is still fresh in their mind and can answer with more accuracy compared to having them complete it at a later time where they may have forgot. The other way of obtaining feedback is via observation as noted above.
The task list and setup can be found here: UsabilityTestTaskListAndSetup
The test was conducted over a number of days with a total of 7 participants, of which 2 had tested the story before. For the purpose of this analysis, I shall only be focusing on those who have not tried it before.
Of all our participants, 85% were male and 18-25 which is our main target demographic. 71% of testers play games for more than 10 hours a week.
None of our testers were colour blind and all were right handed. This was an important question to ask as our main interaction with the world is via the right hand so users who have a predominantly left hand might struggle.
71% of the testers has used the Leap Motion before and all had used the DK2. This will lead to some bias in our results as they may be more familiar with the general mechanics of VR games and stories.
2 testers managed to reach the cafeteria area of the story where the first branch would take place. Their main reasons for reaching this area is that one was thirsty as the other always goes right when given a choice. All found it easy to navigate.
5 testers reached the server room section of the story where the other branch occurs. The main reasons behind this was that they generally always go left or had reached the other destination and wanted to explore the other direction. The testers who generally went that direction did find it harder to navigate.
There was no real logical choice why they want one direction or another as there was not a major compelling reason as reflected in their response. This is should we could look into addressing in the future by having the user want to know more about certain subjects that can only be found by going a certain direction.
As part of the world interaction section, we tested to see how well the testers interacted with the world and if there was any issues doing so. We also covered how well they could use and distinguish elements on the UI.
57% of the testers could read all the text whilst wearing the DK2 whilst 28% couldn’t read any at all. This is partially a limitation of the DK2 due to the low resolution however it could also be caused by the DK2 not being configured correctly for each individual user.
Out of all the testers, 85% interacted with the world without prompt. This is a very good percentage considering the unusual method of interaction however we did have some users confess that they have heard about how the mechanic works ahead of time, leading to a bias.
A common comment made by many testers was they wanted more interactable objects within the world. We observed that most tried to use the vending machine so it’s something we should look into adding interaction with.
There was a mixed response across all the testers regarding their experience with the leap motion. There was a lot of issues with hands failing to track correctly or not rendering properly. This was also noticed by our observers as well who made notes on how frustrated the testers got. We also got one feedback where the tester did not like that it was a hybrid control system between Leap Motion and keyboard/mouse. Designing to cater for a Leap only experience, one concern we had with going Leap only is arm fatigue from needing to hold your hands up a lot which is why we discarded it.
Building upon earlier sentiments, a lot of users did not fully utilise the Rift, more so once they realised how they could control their character. Most of the participants did not know how to properly move their character with the majority initially thinking that their character will move forward with the direction their head is pointing.
Testers enjoyed the unique AR style UI as they felt it was very immersive. There was also a few bugs that was reported or noticed by our observers which have now been fixed.
One feedback we got was with regards to the level design in that the hallways were too generic and boring, not offering them a good enough indication of where they were.
Based upon the feedback from the usability test, a number of changes were made to reduce frustration for the user as well as make more logical sense.
One of the major changes was the way the UI worked with the text size being increased. How it also appears and disappears was also changed so it would linger around longer and retrack the hand to compensate for issues with the Leap Motion.
Signs were also added to the corridors to help guide the users to certain destinations and prevent them from getting lost. Tutorial signs were also added to the starting room so that users could see how to interact with the world as well as move about.
There are some more changes we need to investigate such as changing how the player moves around including turning their body. Unfortunately doing such a change will require a lot of research and more usability tests which we did not have time to conduct.
As just mentioned, there are some areas that will take more time to investigate into how to solve such as the interaction. However I do have one idea myself on how to solve this based upon other VR experiences and how they handle it.
Instead of having the user move around with keyboard/mouse or gamepad, they could instead teleport between the different rooms. This could play in with our idea that you are an AI and by you “teleporting”, it’s more travelling along different data lines to different data centres. There you could interact with the objects around and next to you and complete puzzles to unlock more information.
This would solve some of the locomotion issues and allow an almost DK2/Leap Motion only experience.
Overall our usability test gave us a lot of good feedback that allowed us to make numerous changes to the story. The way in which we conducted the test was good as we felt it allowed us to see how users would naturally react however some users did have prior knowledge of how some of the systems worked even though they had never tried it before. A second usability test is currently being conducted to allow us to see if our changes have had any improvements.
As part of our virtual reality story, IAN, we needed a way to display information to the player to help them learn about who they are. This was going to be in the form of journals and log entries as well as memories IAN has of conversations between researchers. We wanted this information to be available as both text and audio form for the player so they can more easily absorb the information.
For this, we had to design a UI that could be interacted in a 3D space, ideally using the players hands to control it. As such, I created the initial design for the UI below.
I decided to do a wrap up post regarding the current state of the score system as it’s the system I’ve worked on the most and I’m pretty proud of it. It is a little rough around the edges still and there is plenty of ways it can be expanded but it is functional and suits our games needs.
Last week, I implemented a scrolling background into our game to give the sense of movement that the player plane was flying forward.
The scrolling code was very simple to do using only 2 background objects. How it worked was you set the speed and direction you wanted the GameObject to move then once it reached a certain point, it would look back up to its original position and repeat. In this case, the certain point was the length of the Sprite so as soon as the GameObject had moved it’s own length, it would then set the position back to it’s original one. The use of Mathf.Repeat helped simplify the movement code as it ensured a value was kept within a certain range and if it went beyond that range, it would loop back around to the start and add the difference on.
The code is simple, robust and is easy to read so I am happy with it. Using the y size of the Sprite means this script can be easily added onto any other GameObject with a SpriteRenderer and have that be used as a scrolling object without needing to calculate the length of it in Unity’s world units. Although there isn’t a specific I would improve this script, I would like to improve the background scrolling system overall. This would be done by allowing some randomness so the surface underneath you doesn’t feel as repetitive as different background sprites would be used. The sprites could also be randomly offset along the x axis too, to give more variance to the terrain.