Updates to my Skybox Portal Reign Game

Unity Courses Talk
#82

Okay so once we correct the make changes all I need to do is commit the same copy and rename it then apply the above instruction you gave?

#83

I don’t understand the above? “correct the make changes”?

I don’t understand what you mean here either? “same copy”?

Sorry Martin, I don’t have a clue what any of the above means. Rename what?

#84

Okay Sorry, Thank you for all you do no worries I just misunderstood you in an earlier post. :slight_smile:

#85

Ok, so, review Project Boost, see if you can apply the same approach to Portal Reign and if you get stuck after you’ve given it a good go, let me know :slight_smile:

#86

Okay will do. If you don’t mind what section in project boost should I look for? I don’t recall project boost in the c# having code that relates to my sound issues but I will look over it and get back to you. Thank you again :slight_smile:

#87

In project boost you add an audio effect for when you add the thrust, have a look through the lectures after the player input. From memory, at the very beginning you wire up the player input so that you can make the rocket take off, so the sound effects and particles will be after that - you’ll have to look through the lectures, I’m sure the names will be useful, if not, you can always follow the links to the GitHub repository for that project and look at the ReadMe files, there’s one for each lecture and it states what is covered.

#88

I got it Thanks working on it now :slight_smile:

1 Like
#89

Hi Rob, I really appreciate you this is what I got done so far and the video shows how the game plays I have no syntax errors. :slight_smile:

using System.Collections;
using System.Collections.Generic;
using UnityEngine;

public class LaserSound : MonoBehaviour
{


    [SerializeField] private AudioClip Laser;


    Rigidbody rigidBody;
    AudioSource audioSource;

    enum State { Alive }
    State state = State.Alive;


    void Start()
    {
        rigidBody = GetComponent<Rigidbody>();
        audioSource = GetComponent<AudioSource>();
    }

    // Update is called once per frame
    void Update()
    {

        if (state == State.Alive)
        {
            audioSource.Stop();
            audioSource.PlayOneShot(Laser);
        }
    }
 
}
#90

I hope we can continue tomorrow Pal. Thank for your guidance. :slight_smile:

#91

I won’t have any more time this evening Martin, but as a couple of pointers for you…

You don’t need the State enum stuff, that was used in Project Boost to indicate whether the ship was effectively flying or crashed. You already have control over whether the player can control the ship, its used towards the end of the circuit, so if you wanted to prevent the player from shooting, you could use the same approach.

With regards to the odd sound effects, this is because currently you are effectively spamming the hell out of the AudioSource. You have your statement to play the audio within the Update method which executes each frame. You don’t want the audio to play each frame.

I did suggest starting by looking at your code for handling the player input, that would give you a handle on whether the player was pressing fire or not, only if they are do you want to play the audio.

Additionally, you’ll want to have some form of rate of fire / delay so that even if the player is holding down fire, they can only still fire every so many seconds for example, this would give you the ability to play the audio with a gap before playing the same audio again.

So, there’s some things to look at.

#92

Rob, enjoy your evening and Thank you, Pal. :slight_smile:

1 Like
#93

This what I got done so far when you get a chance later tomorrow look over it for me I going to get some rest.
I would appreciate it.

using System;
using System.Collections;
using System.Collections.Generic;
using UnityEngine;

public class GunLaser : MonoBehaviour
{
    AudioSource LaserSound;
    Rigidbody rigidBody;
    AudioSource audioSource;

    void Start()
    {
        rigidBody = GetComponent<Rigidbody>();
        LaserSound = gameObject.GetComponent<AudioSource>();
    }
    void Update()
    {
        RespondToFireInput();
    }
    private void RespondToFireInput()
    {
        if (Input.GetKey(KeyCode.Space))
        {
            audioSource.Stop();
            audioSource.Play();

        }
    }
}
#94

Hi Martin,

You’re heading in the right direction, but, some observations;

  • I have mentioned several times now that you already have code that is handling the player input for firing and suggested you started there, instead you have created another script which is now also handling player input, but, unlike the existing, you are targeting specifically the Space key, where-as your existing code used the CrossPlatformInput control which provides more flexibility.

  • By adding a second location for managing the player input you are opening yourself up for more problems later on when you assume that all of the player input code is in one location, you make a change and then wonder why it doesn’t work, or some other undesired behaviour occurs, as you’ll have lost sight of the other (this) code that is squirrelled away on a game object burrowed deep within the nested GameObjects which represent your player.

  • Was there a reason you added the Rigidbody reference in the above code?

  • Calling Stop on the AudioSource will cause the previous audio clip, assuming its still playing, to stop abruptly, is this the desired behaviour?

I would recommend taking a look at your existing code withing your PlayController.cs script, you have an existing method there named ProcessFiring, to me that would be a fairly sensible place to start. Directly underneath that (at least on GitHub), you have the method SetGunsActive, so again, you already have something in place which is heading the right direction for controlling the emission of the particles also.

#95

Okay Thank you

1 Like
#96

All Done Thank you :slight_smile:

using System;
using System.Collections;
using System.Collections.Generic;
using UnityEngine;
using UnityStandardAssets.CrossPlatformInput;

public class GunLaser : MonoBehaviour
{
    AudioSource LaserSound;
    AudioSource audioSource;
    bool isControlEnabled = true;
    private AudioSource play;
    private IEnumerable<GameObject> guns;

    void Start()
    {
        LaserSound = gameObject.GetComponent<AudioSource>();
    }
    void Update()
    {
        if (isControlEnabled)
        {
            ProcessFiring();
        }

    }
    void ProcessFiring()
    {
        if (CrossPlatformInputManager.GetButton("Fire"))
        {
            SetAudioSourceActive(true);
        }
        else
        {
            SetAudioSourceActive(false);
        }
    }
    private void SetAudioSourceActive(bool isActive)
        {
           play = gameObject.GetComponent<AudioSource>();
           play.enabled = isActive;
        }
}
#97

I was actually referring to placing the code in your PlayerController.cs so that you don’t have the player input spread across the project.

#98

So your saying add this code to the playerController.cs correct?

#99

It’s hard with this project to give sound architectural advice, as it is already quite all over the shop (not of your doing), but as you already have code in the PlayerController class that is handling the input from the player, and the emissions of particles, it seems to me that, at the moment, adding a couple more lines of code to play some audio when the player fires would best be in the same place.

This would certainly make refactoring your project a lot easier later on also, as you’d be able to see exactly what the PlayerController was doing that perhaps it shouldn’t be. As an example, perhaps later on your guns have their own class which is responsible for both the particle effects and the audio, but they are only activated through the method which is currently handling the player input in the PlayerController.

Arguably, if you use what you’ve already created above, you are starting to separate those responsibilities, but that still leaves the particles in the PlayerController and the handing of input from the player in two places - which I would recommend you avoid.

#100

So now I have to incorporate this code in the play controller some how without breaking anything that is a big job will work on starting later tonight I have class at Keller in a bit. Thank you for your guidance. :slight_smile:

#101

You don’t have to, it’s only a suggestion, and it isn’t that big a job.

Note, in the above you have a lot of left overs that you are not doing anything with, you really should start keeping an eye on this, the reason being it creates a lot more clutter, which, when you come back to a specific piece of code in six months time and can’t remember what it actually did, you’ll spend a lot of time trying to work out your own code because of all the extras that don’t need to the be there…

Specifically, based on the above;

  • isControlEnabled - you set this to true and then test to see if its true before processing the firing. The reason for this is because you’ve copied a chunk of code from PlayerController.cs, but it makes no sense to add a bool, set it to true, and then test to see if its true, because there’s nothing else in that entire script that will ever change it to false. Worse still, you carry out that test every frame, yet you know it will never be any different.

    So, in this script, both the bool and if statement within Update are redundant and costing you a little performance.

  • guns - this is an unused variable. It isn’t serialized so we can tell you are not populating it from within the Inspector, and it is not referenced anywhere in this script.

  • play - as a variable name I would suggest this is perhaps not overly helpful, always ask yourself “Will this make sense to me in six months or a year from now?” With this specific variable, which is a reference to the AudioSource, if you wanted to call it’s Play method, your code would look like this play.Play() - that’s a bit odd. I’d have a rethink on the naming of this.

The only other observation I’d make would be regarding the setting of enabled/disabled on the AudioSource. Disabling it will stop anything that was playing instantly, creating choppy sound effects. This would also imply, that by design you have an AudioClip for the laser sound which is just in a state of constant looping, is that the case?

Privacy & Terms