This Virtual Reality application will simulate an on-rail first person shooting game that generally involve the player trying to survive through a predetermined path that is filled with enemies.
Enemies that will try and kill you through various technique implemented by simple AI within the game. You can try to dodge the enemy's attack by moving your body within the provided space
For those who are unfamiliar with the two terms "First-Person Shooter", and "On-Rails", the two terms are generally used to describe how the orientation of the camera works in game. First-Person Shooter (FPS): This type of game will have the camera in perspective of the player in game. So what we see is what the player should see. There may be times when the game will enter a third person mode which means the player can see its own 3d-model . Such instances may include dying in game, cut-scenes, or loading. This is where the HTC VIVE headset and controllers come in.
A rail shooter is a type of action-based video game. In a rail shooter the player control is limited to directing where to fire a virtual gun or move his or her avatar around the screen; the player does not control the path his or her avatar takes from the start to the end. Since this game does not consist of blood spatters or horrific death cut scenes, it can caters to anyone above 13 years old
How it works:
The VIVE headset will track the player's direction of view, and thus in game, will provide a similar direction of viewing. Such as if the player is physically looking up, then so will in game. Our game will be utilizing both dimensions of 3d movement (thus we must view 360° in both the X and Y planes). User is able to choose their choice of weapon and aim it as they would holding a gun by just pointing the HTC controller at the enemy. There exists a health bar display at the top left corner of user's point of view to inform the player of their status
Another thing worth noting is that after a fixed number of enemies that are killed by the player, (or whenever a stage is finished), the next stage will proceed. User doesn't necessary need to physically walk around as the camera will automatically pan around for them.The panning speed would be slow and smooth so user doesn't get motion sickness. Enemies will be spawning at multiple locations at random time ( to provide somewhat of a difficult to the game).
Enemies to look out for:
Enemy Sniper: Enemy rifler: Enemy helicopter:
has distinctive laser that is pointing shoots round projectiles at you! -detect your location up to 50ft!
to wherever you are at! Takes - red model for easy pinpointing -projectiles travel really slow, but
4 seconds to aim, and another - shoot a slow moving bullet every fire at rapid rate . Kill it before it
to shoot second (use this to your advantage!) kills you
Enemy melee attacker: Enemy melee attacker # 2:
-Will attempt to sneak up on you -Will run at you very fast
and attack with his right hand -Easier to kill than others
-walk slow, hits hard -Punches with fist to knock you out
Features that user can do in this project:
Shooting - By pulling on the hair trigger of HTC controller, it allows the user to shoot the gun that is currently being held within the game. Since the 3D model of the right controller will be replaced with whatever gun model user chooses, you can look down the barrel to aim at your target. ( this currently only consist of right controller being the hand that is holding the gun, and the left controller is designated for menu selecting/ laser UI interaction)
Reloading gun -By putting your right controller down below the waist level ( doing the motion that is similar to the picture shown to the left below), it will let user reload the current weapon that is currently on. This closely resembles the motion of reloading from a shooting arcade. Note that by doing this, program also provides an audio feedback - the sound of bullets being changed and loaded into the gun. The picture to the right below was taken taking in consideration of an average height of an average 20 years old - 5'7 . Although doing this motion should work for all heights
Switching weapon - While holding your controller, user can put their right hand over-shoulder behind their back( very similar to the motion of someone who is trying to reach for their sword attached to their back), it would summon an in-game menu option pops up in front of the user. This menu would let user choose and switch their gun to a preferred weapon of choice. By using the left controller (it also include a red UI laser to let user know where they are pointing at), you can pull the trigger to select
(below is the picture of how it looks like.There are currently only 2 weapons available to choose from- a hand gun revolver and a shot gun or bare hand.Note that during reloading, the 3D model of your hand in-game wouldn't perform any reloading animation). While this seems somewhat limited, user could still have a good experience regardless.
Area of movement- Since this project is based in a Virtual Reality world, user need to have some physical space to move around freely without hitting the objects/furniture around them. Baring this in mind, we have provided user enough room to maneuver and dodge projectiles ( roughly equivalent to 8meters wide each side). User will get an audio and visual warning if they step outside of the given area of movement ( shown in the green color rectangle on the ground). Each time the game moves on to the next stage, the camera will pan smoothly so that user does not get motion sickness. It would also provide a wide enough area within the game scene so that user can visualize where they can and cannot go.
More Visual and Audio feedback: In order to provide an unique VR experience,we have decided to added in some features that let user know when an event has happened. Refer to the left picture below, it show the effect a bullet has upon impact with the wall, or anything other objects. There would also be an audio sound of shots being fired and projectiles hitting objects. Also, whenever the user gets hit or gets shot by an enemy AI, the screen would flash red showing the impact.
Interesting things we needed to do to get this project to work
-One of the many things we incorporated into this project so that it would look smoothly is Quaterion Lerp and Quaterion Slerp.
Quaterion.Slerp: Spherically interpolates between a and b by t. The parameter t is clamped to the range [0, 1]. (Unity definition). What this means is that instead of having an object to rotate from x point to y point in a very quick manner, it would slowly turn towards it (or 'slerp' towards it). The interpolation is mapped as though on a quarter segment of a circle so you get the slow out and slow in effect. The distant between each step is not equidistant.
For example, in some of the AI enemy, we implemented a function in which it would attempt to detect the location of the player and would try to turn towards them, then start the attacking phase. Initially, we had the AI doing a quick turn, but it looked very broken and discontinuous.
As you can see from the gif to the left, this rifler enemy would slowly turn ,interpolate spherically from its original position to the position of the player- making it looks as if the enemy is actually turning instead of instantly teleport to be facing you
Quaterion.Lerp: Interpolates between a and b by t and normalizes the result afterwards. The parameter t is clamped to the range [0, 1]. (Unity definition ). In order to provide user a smooth experience and prevents motion sickness, we have incorporated Quaterion Lerp in our transition of the on-rail. What this means is that instead of having the user teleporting directly on top of the next scene, the program would try to pan towards the next phase by using Lerp.
This snippet of code would allow the transition to be much smooth as it uses Quaterion.Lerp to pan the play area from x point to y point.
It also takes into consideration if the user chooses to skip the text showing on the panel. If that happens, the panning would speed up slightly to allow user to fast forward to the next phase
It's important to note that although this does minimize the motion sickness, it's not perfect as there is no tactile feedback. User might still get slight headache after long period of usage
Unity Mecanim Animation System: Another interested thing that worth mentioning in this section is the usage of Unity Mechanim Animation system. In details, it consists of many different stages that the animation would play accordingly to the event within the game. In order to code an Artificial intelligence enemy that would detect your location, move towards you and attack you, ( or play a death animation if needed), we implemented a state machine shown as below. It includes states of Idle, Attack, Run and Death.
The enemy would just stand in one spot and idle if the player is not within the radius of attack. It would start moving towards your location whenever you are close by. (fixed radius of 20ft). Plus, it would attack you when the current distance between player and itself is within arm reach.
*For this demonstration, I have changed the condition that the enemy dies - after it has attacked you twice, it would play a death animation. In the real game, this wouldn't happen as it would make the game incredibly boring to play. Also, the two videos are not synced up.
Controller Orientation: In order for the user to summon a weapon switch menu ( or reload the gun ), we have to take into consideration of the orientation of the controller. It adds more control to the game by using familiar real life motions ( such as putting your right controller over shoulder and behind your back in order to switch weapon , or put it below waist level in order to reload ). Both utilizing the library and hardware that VIVE offers.
For example, by turning the gun half way to being upside down, it would trigger a function that summons the switching menu. Note that doing this would work anywhere within the game, not just at the initial starting position.
Conclusion / Personal thoughts:
Even though we came across many bugs and mysterious errors along the way, we were able to accomplish what we set out to do initially. Note that during the process of researching, we noticed that there are many other VR on-rail first person shooting game available. Our project might not be the best out there, but it definitely helped the group experience how a real life project/ assignments in our future careers in regards to teamwork and managing work load. Working in group and/or having someone else else as partner seems more realistic and applicable to the real world. Plus, it provided extra pairs of eyes to spot any bug/syntax mistakes within the code.
Since this project is only small scale - there is only one level and 5 enemy AI's, it is much easier for us to expand upon this game. Its worthy to note that we have learned all the necessary and crucial elements in order to develop and give a fuller version of an on-rail first person shooting:
- Slerp/ Lerp for smooth transition of camera
- Making the 3D model of the HTC controller into the model of any weapon we'd want
- Provide a play area
- Controller Orientation incorporated into some familiar real life hand motions to do specific tasks
- Enemey AI , in terms of tracking user's location and attacking
- Mecanim Animation System controller
Being a part of a group project means that we have to be more aware of the code we're producing. Sloppy, messy or hard-to-read code will make your group members spend more unnecessary time trying to understand what you've published. We've noticed that we tend to go back and forward on our code, modifying and adjusting things as we go. There are issues that did not originally occur at start, but eventually came across. So it's definitely helpful to have good communication between group members and an agreed location to upload/ publish our work on. Also, before submitting our share of work to other members of the group, we made sure that we have tested all components within the program. As errors from our part might effect the work from another member.
In the end, we'd say that the most challenging part of doing this project would be debugging and trying to learn the built-in functions that Unity has offered us. There are many things out there that we were not aware of which made our coding process much easier ( Slerp , Lerp, Vector distance, Time delta, etc. )
Reference / Sources:
Models and Animations:
default YBot and XBot models; https://www.mixamo.com/#/?page=1&query=bot&type=Character
multiple animations packages: https://www.mixamo.com/#/?page=1&query=&type=Motion%2CMotionPack
Reference from youtube video for mecanim and AI:
https://docs.unity3d.com/ScriptReference/Vector3.Slerp.html Slerp documentation
https://docs.unity3d.com/ScriptReference/Quaternion.Slerp.html more slerp documentation
https://docs.unity3d.com/ScriptReference/Vector3.Lerp.html Lerp documentation
https://unity3d.com/get-unity/download Unity download
https://www.assetstore.unity3d.com/en/#!/content/32647 SteamVR for Unity
Trying out the project yourself at home!
If you're one of the lucky people who possesses their own VIVE headset and HTC controller, you should try out our project. It's free of charge. Simply just download the archived files with this link.
Instruction on how to build the project from your PC or anywhere:
-Download and install Unity 5.6.3 (the latest version of Unity 2017 wouldn't work on this version of our on-rail game)
-Download and install SteamVR (should be available for free via Steam)
-Extract all the files needed within a folder that is a accessible.
-Open Unity. Go to 'Open' , then direct to the folder containing the files
-Upon opening, the current scene might not be called 'menuScene' . Simple direct to your asset folder and double click on 'menuScene' (this is where the tutorial starts. You also have the option to skip the tutorial within the scene and go straight into the game play).
-Make sure your SteamVR is opened, running and tracking your VR hardwares correctly.
-You can try playing it within the Unity Editor (or build the project into an executable and play it outside of the Unity Editor)
Steps to build the project:
1). on the top left corner, click on File->Build Settings
2). Within the build settings, you would see this window opens
3). Select your desired platform and simply click on
Steps to run the project within the classroom EVL:
1). Download the folder and extract all (link)
2). Open Unity 5.6.3 and direct to Assets folder
3). Open the scene 'menuScene'
4). Enjoy the game :-)!!
Struggles and Complications
• Considering that we did not have the HTC VIVE headset and controllers in possession during this project, we had a lot of trouble calibrating a lot of things. Most specifically we had trouble orientating the UI, where UI buttons and elements would appear on the headset rather than the screen.
Another orientation problem was the angle and rotation of the controllers. When using the SteamVR assets and code, the HTC VIVE controllers do not show up in the Unity developmental scene and thus we do not know what exactly the rotations are. This was an issue when we tried to develop the reload and weapon select functions for the controllers.
• Staging process: We had multiple issues when we are designing the process in which a stage progresses. Such as the tutorial per se. For the tutorial we had to Lerp our player’s platform through certain points, but we had to consider that the user will have to interact or provide input. So we had multiple states and variables that allow the user to continue fluently, such as the scrolling text -> another set of scrolling text -> shooting panel -> continue.
• Unity Layering system, apparently in Unity, anything with a rigid body can cause things to collide, thus for the shotgun, the bullets were all bouncing off each other/colliding each other. This was circumvented by using the layer system, in which player projectiles do not interact with other specific player layers (including the own camera, yes bullets were able to hit the player’s body).