Jump to content
  • Advertisement
  • entries
    44
  • comments
    19
  • views
    2432

Day 38 of 100 Days of VR: Creating a VR First Person Shooter I

Josh Chang

1034 views

Welcome to Day 38! Today, we’re going to talk about the limitations of mobile VR and make some changes in our game to fix things.

We’ve already started to fix some things, specifically adding event triggers to our enemies, but there’s still many more things to solve!

Here’s a quick list of things I want to tackle from what we encountered 2 days ago:

From a technical limitation:

  1. We can’t move
  2. We only have one input which is clicking

Some actual technical problems:

  1. The enemies are all black color
  2. We don’t have any of our UI’s anymore

We’re going to address these problems over the next couple of days.

Today, we’re going to focus on the technical limitations of Mobile VR, today’s priorities are:

  1. Discussing how to change our game design to accommodate our new limitations
  2. Implementing our new designs

Edit, Important Note:

After playing around with the Cardboard in Unity today and looking at this article about Google Cardboard’s inputs.

It seems that we don’t have to use Google VR SDK. Unity already has most of the internal integration necessary to make a VR app

Everything we had already works, the reason why there I initially thought there was a problem is, because of how we did raycasting.

Specifically, our raycasting code targeted where our mouse/finger was touching, not the middle of the screen! More on this later.

Step 1: Changing the Game to Fit our Mobile Limitations

Like mentioned before, in the Google Cardboard, we have 3 limitations:

  1. We can’t move our characters position
  2. We only have tapping as an input to interact with the game
  3. Our cursor will always be in the middle of the screen

Even for the Daydream Viewer, we will have the first 2 limitations.

However, with the new Daydream Standalone device coming out, we’ll have World Space, finally allowing us to track the player’s movements without requiring external devices like what the Vive does!

Anyways, back on topic.

Considering these 3 limitations, here are my thoughts of what needs to be changed in our game:

  1. Because we can’t move, we should place our character in a more centered location for the enemies to reach us
  2. Because we can no longer run away, we should make the enemies weaker so that we don’t get swarmed
  3. Because we only have one input, we can shoot, but we can’t reload, we should get rid of the reload system

Essentially, we’re going to create a shooter with our player in the center with enemies coming from all around us.

Step 2: Implementing Our New Designs

Now that we have everything we want to do planned, let’s get started in the actual implementation!

Step 2.1: Placing the Character in the Middle

Let’s place the character in the middle of where our spawn points are set.

After playing around with it, I think the best spot would be at Position: (100, 1, 95)

center-location-1024x394.png

  1. Select Player in our hierarchy.
  2. In the Transform component, set our Position to be X: 100, Y: 1, Z: 95

Step 2.2: Making the Enemies Weaker

Next up, let’s make the enemies weaker.

In the Enemy Health script component attached to our Knight, Bandit, and Zombie prefab, let’s change their health value.

In order of our health, the order of size from largest to smallest is: Zombie > Knight > Bandit. Let’s set the health to be:

  1. Zombie: 4 HP
  2. Knight: 2 HP
  3. Bandit: 1 HP

Here’s how we change our health:

  1. In Assets > Prefabs select our prefabs, in this case, let’s choose Zombie.
  2. In the Inspector, select the Enemy Health (Script) component and change Health to be 4

change-zombie-health-to-4.png

Do the same change with the other 2 prefabs.

Step 2.3: Remove our ammo system

Now it’s time to back to our Player Shooting Controller (Script) Component that we disabled yesterday.

I want to keep the animation and sound effects that we had when shooting our gun, however, I’m going to get rid of the ammo and the need to reload.

Here are my changes:

using UnityEngine;
using System.Collections;

public class PlayerShootingController : MonoBehaviour
{
    public float Range = 100;
    public float ShootingDelay = 0.1f;
    public AudioClip ShotSfxClips;
    public Transform GunEndPoint;
    //public float MaxAmmo = 10f;

    private Camera _camera;
    private ParticleSystem _particle;
    private LayerMask _shootableMask;
    private float _timer;
    private AudioSource _audioSource;
    private Animator _animator;
    private bool _isShooting;
    //private bool _isReloading;
    //private LineRenderer _lineRenderer;
    //private float _currentAmmo;
    //private ScreenManager _screenManager;


    void Start () {
		_camera = Camera.main;
	    _particle = GetComponentInChildren<ParticleSystem>();
	    Cursor.lockState = CursorLockMode.Locked;
	    _shootableMask = LayerMask.GetMask("Shootable");
	    _timer = 0;
        SetupSound();
        _animator = GetComponent<Animator>();
        _isShooting = false;
        //_isReloading = false;
        //_lineRenderer = GetComponent<LineRenderer>();
        //_currentAmmo = MaxAmmo + 10;
        //_screenManager = GameObject.FindWithTag("ScreenManager").GetComponent<ScreenManager>();
    }
	
	void Update ()
	{
	    _timer += Time.deltaTime;

	    // Create a vector at the center of our camera's viewport
	    //Vector3 lineOrigin = _camera.ViewportToWorldPoint(new Vector3(0.5f, 0.5f, 0.0f));

	    // Draw a line in the Scene View  from the point lineOrigin in the direction of fpsCam.transform.forward * weaponRange, using the color green
	    //Debug.DrawRay(lineOrigin, _camera.transform.forward * Range, Color.green);

        if (Input.GetButton("Fire1") && _timer >= ShootingDelay /*&& !_isReloading && _currentAmmo > 0*/)
	    {
            Shoot();
	        if (!_isShooting)
	        {
	            TriggerShootingAnimation();
	        }
	    }
        else if (!Input.GetButton("Fire1") /*|| _currentAmmo <= 0*/)
	    {
            StopShooting();
	        if (_isShooting)
	        {
	            TriggerShootingAnimation();
            }
	    }

	    /*if (Input.GetKeyDown(KeyCode.R))
	    {
	        StartReloading();
	    }*/
	}

    private void StartReloading()
    {
        _animator.SetTrigger("DoReload");
        StopShooting();
        _isShooting = false;
        //_isReloading = true;
    }

    private void TriggerShootingAnimation()
    {
        _isShooting = !_isShooting;
        _animator.SetTrigger("Shoot");
        //print("trigger shoot animation");
    }

    private void StopShooting()
    {
        _audioSource.Stop();
        _particle.Stop();
    }

    public void Shoot()
    {
        //print("shoot called");
        _timer = 0;
        Ray ray = _camera.ViewportPointToRay(new Vector3(0.5f, 0.5f, 0f));//_camera.ScreenPointToRay(Input.mousePosition);
        RaycastHit hit = new RaycastHit();
        _audioSource.Play();
        _particle.Play();
        //_currentAmmo--;
        //_screenManager.UpdateAmmoText(_currentAmmo, MaxAmmo);

        //_lineRenderer.SetPosition(0, GunEndPoint.position);
        //StartCoroutine(FireLine());

        if (Physics.Raycast(ray, out hit, Range, _shootableMask))
        {
            print("hit " + hit.collider.gameObject);
            //_lineRenderer.SetPosition(1, hit.point);
            //EnemyHealth health = hit.collider.GetComponent<EnemyHealth>();
            EnemyMovement enemyMovement = hit.collider.GetComponent<EnemyMovement>();
            if (enemyMovement != null)
            {
                enemyMovement.KnockBack();
            }
            /*if (health != null)
            {
                health.TakeDamage(1);
            }*/
        }
        /*else
        {
            _lineRenderer.SetPosition(1, ray.GetPoint(Range));
        }*/
    }

  
    // called from the animation finished
    /*public void ReloadFinish()
    {
        _isReloading = false;
        _currentAmmo = MaxAmmo;
        _screenManager.UpdateAmmoText(_currentAmmo, MaxAmmo);
    }*/

    private void SetupSound()
    {
        _audioSource = gameObject.AddComponent<AudioSource>();
        _audioSource.volume = 0.2f;
        _audioSource.clip = ShotSfxClips;
    }

    public void GameOver()
    {
        _animator.SetTrigger("GameOver");
        StopShooting();
        print("game over called");
    }
}

I’ve kept what I commented out, here’s the clean version of our script.

using UnityEngine;
using System.Collections;

public class PlayerShootingController : MonoBehaviour
{
    public float Range = 100;
    public float ShootingDelay = 0.1f;
    public AudioClip ShotSfxClips;
    public Transform GunEndPoint;

    private Camera _camera;
    private ParticleSystem _particle;
    private LayerMask _shootableMask;
    private float _timer;
    private AudioSource _audioSource;
    private Animator _animator;
    private bool _isShooting;

    void Start () {
		_camera = Camera.main;
	    _particle = GetComponentInChildren<ParticleSystem>();
	    Cursor.lockState = CursorLockMode.Locked;
	    _shootableMask = LayerMask.GetMask("Shootable");
	    _timer = 0;
        SetupSound();
        _animator = GetComponent<Animator>();
        _isShooting = false;
    }
	
	void Update ()
	{
	    _timer += Time.deltaTime;

        if (Input.GetButton("Fire1") && _timer >= ShootingDelay)
	    {
            Shoot();
	        if (!_isShooting)
	        {
	            TriggerShootingAnimation();
	        }
	    }
        else if (!Input.GetButton("Fire1"))
	    {
            StopShooting();
	        if (_isShooting)
	        {
	            TriggerShootingAnimation();
            }
	    }
	}

    private void TriggerShootingAnimation()
    {
        _isShooting = !_isShooting;
        _animator.SetTrigger("Shoot");
    }

    private void StopShooting()
    {
        _audioSource.Stop();
        _particle.Stop();
    }

    public void Shoot()
    {
        _timer = 0;
        Ray ray = _camera.ViewportPointToRay(new Vector3(0.5f, 0.5f, 0f));
        RaycastHit hit = new RaycastHit();
        _audioSource.Play();
        _particle.Play();

        if (Physics.Raycast(ray, out hit, Range, _shootableMask))
        {
            print("hit " + hit.collider.gameObject);
            EnemyMovement enemyMovement = hit.collider.GetComponent<EnemyMovement>();
            if (enemyMovement != null)
            {
                enemyMovement.KnockBack();
            }
        }
    }

    private void SetupSound()
    {
        _audioSource = gameObject.AddComponent<AudioSource>();
        _audioSource.volume = 0.2f;
        _audioSource.clip = ShotSfxClips;
    }

    public void GameOver()
    {
        _animator.SetTrigger("GameOver");
        StopShooting();
        print("game over called");
    }
}

Looking through the Changes

We removed a lot of the code that was part of the reloading system.

We basically removed any mentions of our ammo and reloading, however, I kept the changes involved with the shooting animation, shooting sound effects, and shooting rate.

There were only 2 changes that were made:

  1. I changed the input we use to shoot from GetMouseButton to GetButton(“Fire1”), I believe this is the same thing, but I’m making the change anyways. Either option returns true when we’re touching the screen on our mobile device.
  2. I also changed our Ray from our raycasting system. Before casted a ray from where our mouse was located at, which before we fixed at the center. However, after we got rid of the code that fixed cursor to the middle, we needed a new way to target the middle. Instead of firing the raycast from our mouse, we now fire the raycast from the middle of our camera, which will fix our problem with our mobile device.

Go ahead and play the game now. We should be able to have a playable game now.

There are 2 things that will happen when we shoot:

  1. We’ll shoot a raycast and if it hits the enemy, they’ll be pushed back
  2. The enemies trigger event will detect that we clicked down on the enemy, so they’ll take some damage

At this point, we have a problem: if we were to hold down the screen, we’ll push the enemy back, but they’ll only be hit once! That’s because we only have that deals with an OnClick event, but not if the user is currently selecting them.

We’re going to fix this problem tomorrow, but I’ve done a lot of investigation work with raycasts now and want to take a break!

Step 2.4: Changing the ScreenManager script

One more thing we need to do before we leave.

The Unity compiler would complain about a missing reference with our ScreenManager, specifically with the MaxAmmo variable that we got rid of.

Let’s just get rid of it:

using UnityEngine;
using UnityEngine.UI;

public class ScreenManager : MonoBehaviour
{
    public Text AmmoText;

    void Start()
    {
        {
            PlayerShootingController shootingController = Camera.main.GetComponentInChildren<PlayerShootingController>();
            //UpdateAmmoText(shootingController.MaxAmmo, shootingController.MaxAmmo);
        }
    }

    public void UpdateAmmoText(float currentAmmo, float maxAmmo)
    {
        AmmoText.text = currentAmmo + "/" + maxAmmo;
    }
}

And we’re good to go! Technically speaking, we won’t be using this script anymore either.

Conclusion

And another day’s worth of work has ended! There’s a lot of things I learned about VR, such as: we don’t need ANYTHING that the Google VR SDK provides!

Unity as a game engine already provides us with everything we need to make a VR experience. Google’s SDK kit is more of a utility kit that help make implementation easier.

The TLDR I learned today is that we don’t have to be fixed on using Unity’s Raycasting script, we don’t need it. We can continue to use what we already have. However, for the sake of learning, I’m going to continue down re-implementing our simple FPS with the Google Cardboard assets!

We’ll continue tomorrow on Day 39! See you then!

Day 37 | 100 Days of VR | Day 39

Home



2 Comments


Recommended Comments

VR actually does have other input, you can move things around.

Using a Leap motion controller I was able to create a reloading function. I just had a box around the gun's hand grip and a smaller one attached to the clip's top. Once the two boxes intercept a reload animation plays.

This was easier than the "realistic" gun VR games and had none of that struggle to reload problems. 

Share this comment


Link to comment

That's a really interesting idea. I've never thought of using Leap motion controller. I've heard a lot about them, but I've never had the chance to play around with one. It'll definitely be on my bucket list of things to do!

Share this comment


Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement
  • Advertisement
  • Blog Entries

  • Similar Content

    • By Nick Griffith
      I'm making a 2d platformer game as a learning experience, and I need a character and some backgrounds.
      The idea is a person on the brink of death "running" through his memories. The background is his memories.
      This game will make minimal revenue, because it'll be a free mobile game.
      I'll give you more details if you respond.
      Thanks.
    • By GameDev.net
      Search GameDev.net directly from the Unity Editor with the GameDev.net Search plugin!
      Customize your search for all content on GameDev.net, only the latest, or the most relevant. Or, narrow your search to specific GameDev.net content:
      Blogs Articles Forums News Contractors Projects and more!
    • By Heretic Arts
      Hello, 
      We are an American based videogame development team that crafts games utilizing neural networks, handcrafted art, studio quality audio, and immersive storytelling to provide the player with an unforgettable experience. Our current team comprises of a Software Engineer, Designer, Producer, Audio Engineer, and a systems admin. Obviously we are missing an art staff! Now, that being said, we have outsourced our concept art for the game to an experienced artist. We are wanting talent to join us to take it the rest of the way with animation and art. If you are interested in joining the team and feel that you are ready to work along a committed team, send a sample of your work and contact information to HereticRecruitment@HereticArts.com. 
      Job Specifics: 
      General: 
      Unpaid. This is normal. We all have fulltime careers outside of the team, but if there is money to be made upon release, it will be split evenly - no questions asked.  All expenses are paid by Administrative Team (GSuite account). So no worries - We want someone to join, have fun and create with us! Expectations of meeting weekly (via internet) and taking direction from producer.  Open minded  
      Skill sets: 
      Experience in designing and creating character art.  Full adobe suite.  Maya experience preferred.  Experience with developing for the Unity Engine.  Willing to work with design team to incorporate their ideas into art.  Knowledge of game design documentation and how it pertains to art creation.  In depth sprite animation knowledge. 
    • By GameDev.net
      GameDaily.Biz spoke to Improbable about its new shortcuts to multiplayer game development for Unity and Unreal. 

      Improbable helps game developers build believable online worlds with its bespoke technology, SpatialOS. Now, that task is much easier and accessible for those building games on the technology with the recent release of the SpatialOS Game Development Kit (GDK) for Unity. With these kits, Improbable hopes that developers find it easier to create vast, dynamic and unique worlds.
      This GDK for Unity includes a 200-gamer, first-person project that allows developers to experiment and tinker with their ideas for what their vision of a multiplayer game will look like.
      GameDaily.Biz met with Improbable’s Head of Product Marketing, Paul Thomas, and Head of Comms, Daniel Nye Griffiths, to speak about the SpatialOS GDK for Unity, as well as the upcoming launch of the SpatialOS GDK for Unreal Engine.
      In its first week, the SpatialOS GDK for Unity achieved over 2,000 developer sign ups to use it. “What we're trying to do is basically make it really fast for people to build multiplayer games,” said Thomas. “It comes with all the multiplayer networking so that developers don’t have to do any multiplayer networking. It comes with feature modules to allow [easy] solutions to common multiplayer problems, like player movement and shooting. And it comes with a cool starter project where you have 200 players in a free-for-all scenario. You can obviously use the power of SpatialOS to scale that project up to more players, with NPCs, and things like that. It gives people a really good base to start building multiplayer games.”
      There are several games currently in development or early access that utilize SpatialOS. The first into Early Access was Spilt Milk Studios’ Lazarus, a space MMO where the player becomes a pilot in a universe that ends every week, complete with a map that’s twice the size of Austria. Additionally, Bossa Studios released its survival exploration game Worlds Adrift into Steam Early Access earlier this year.
      Also using SpatialOS is Scavengers from Midwinter Entertainment, a studio founded by former 343 Industries studio head and Halo 4 Creative Director, Josh Holmes; the game is heavily inspired by his Halo 5: Guardians’ multiplayer mode, Warzone. Right alongside that company, Berlin-based Klang Studios is working on Seed, a simulation MMO that, according to its developers, lets players “interact and collaborate to create a world driven by real emotion and aspiration.”
      According to Thomas, for those looking to use the SpatialOS GDK for Unity, there is no limit to  what their games can do with Improbable’s tech.
      “What we're doing is expanding the possible gameplay you can do. Traditionally, when you make a multiplayer game, you're constrained by one single server. So you can say you have a 64-player game with a handful of NPCs or you could have a world that's 3km by 3km. With Spatial, you can go beyond that, test a much broader canvas to start thinking about different gameplay.”
      “You can go for a massive online persistent MMO with 10,000 players and hundreds of thousands of NPCs, something very, very vast and big like that. But you can also have smaller experiences. For example, there's a lot of interesting space in just extending what you see in the Battle Royale genre and session-based gameplay.”
      Thomas continued: “Our partners at Automaton have a game in development called Mavericks. The interesting thing there is they have a Battle Royale with 1,000 people, but what I really find interesting is the gameplay mechanics they've put in, like footprints so you can track people. They've added a cool fire propagation mechanic so you can start a fire that  spreads across the map and changes the world. Or you can add destructible buildings and things like that.”
      “So I think even looking at smaller scale games, we add a lot of value in terms of the new gameplay you can start adding. I'm just interested to see what people do with this extra power - what they can come up with.”
      While Battle Royale games and MMOs are obvious standouts for genres that best fit with SpatialOS, Thomas introduced some other ideas of genres that could benefit from the technology.
      “I also think there's a space for very interesting MMORTSs as well,” he said. “An RTS where you have persistent systems, like telling AIs to do things and then coming back to them a week later and seeing what's happened is an interesting space.”
      “I also see interesting mobile experiences that could come up. Having these worlds where you lay down some interesting things and then come back a few weeks later to see how they've evolved and changed, and the massive player interaction. Say for example with Pokemon Go, we can actually roam around the world and battle on the streets. I can see something like that working very well. Again, these are just ideas we've had and talked to people about. It's about giving people that flexibility and the ability to explore these ideas.”
      Klang’s Seed
      Griffiths added the possibility of events in a game that will have a massive, rippling, and lasting impact on its world as something that has people excited. One example he gives is how someone on one side of the map can do something that’ll have a knock-on effect for the rest of the world in real time.
      “There's a whole bunch of different angles you can take, some of which are about much larger player numbers or a much larger map, but there are other things you can do which are taking a relatively constrained game experience, a smaller map, a smaller number of players and adding richness to the game as well.”
      In fact, this is something that Thomas refers to as a “persistent in memory database,” meaning that for every object in the game world, there’s a history. Two examples cited by Thomas: “...a player could chop down a tree and that tree stays disappeared forever. Or a player can kill a big monster that was raiding a town and that town no longer gets raided by that monster, and this changes the dynamics of the world. Worlds can have a history. That means players can have a lot more meaning in these MMO worlds.”
      “Normally in MMOs, they're kinda like roller coaster rides: you go into a dungeon, you kill the boss and that guy respawns. It all resets,” Thomas continues. “But in Spatial MMOs, you could have these persistent effects that should change the gameplay meaningfully for all the rest of the player base.”
      “The other one I think that is interesting is the level of dynamism that you could have. So because you can have so much more server-side compute, you could potentially have NPCs roaming around the world changing their mind and deciding all of a sudden, 'oh, we're going to attack this player's base' or 'we're gonna go attack this town' and they have a lot more range and emotion and intelligence to them that you'd not see in other MMOs.
      “Normally in MMOs, NPCs sit there tethered. You go near them and they come and attack you, you run away, and they go back to where they were. In a Spatial MMO, that NPC can trace you across the whole map or a group of them can decide to get together and attack someone..”

      Bossa Studios' Worlds Adrift
       

      Next week, Improbable plans to launch its SpatialOS GDK for Unreal Engine, which will have a big focus on ease of use for access to Unreal, as well as a big emphasis on porting your projects to SpatialOS.
      “One of the things we'll be trying to push is a porting guide so you'll be able to take your existing Unreal game, move it onto SpatialOS and then you can grow to expand it with new and extra gameplay,” says Thomas. “ You can bring across your existing Unreal game and it feels very, very native and similar to Unreal if you're familiar with Unreal.”
      Griffiths continued, explaining how testing these experiences includes free cloud deployments, to a certain point. “If you're developing in SpatialOS in other ways, we provide a sandbox environment so you can get your game running. When you’re happy, you can port it over and sort of experiment with it in a free sandbox environment with a small number of cores to get started.”
      Based on what we learned, Improbable’s SpatialOS GDK for Unity will give developers enhanced flexibility to produce more in depth and engaging videos games. That said, we look forward to catching up with the company in the near future to see how this exciting technology is being used in the different games that we play.
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!