About 'Use Random.Range()'!

cud_s04_use_randomrange

#1

In this video (objectives)…

  1. Use Random.Range() for our guess to introduce randomness.
  2. Refactor our code to only have 1 place of calculating guess.
  3. Tweak our logic to prevent the computer from guessing a number already guessed.

After watching (learning outcomes)… Use Random.Range() to add randomness to the number guessed.

(Unique Video Reference: 10_UI_CUD)

We would love to know…

  • What you found good about this lecture?
  • What we could do better?

Remember that you can reply to this topic, or create a new topic. The easiest way to create a new topic is to follow the link in Resources. That way the topic will…

  • Be in the correct forum (for the course).
  • Be in the right sub-forum (for the section)
  • Have the correct lecture tag.

Enjoy your stay in our thriving community!


#2

Heya there Rick,

I believe there are 2 issues in this video( bash me if I’m mistaken)

First is that using Random.Range with integers is sightly different than using it with floats. The thing is that “max” is not included, its excluded from the generation process:

Second is what happens if you keep pressing Higher? In my case(and in doubt I copied all the code from the github link) it goes over 1000.

Check this please:

I got arround this little bug by adding a condition that only +1 the min if it does’t go above the max(the same for max in lower button)

Thank you for your time,


Already guess number bug
#3

Oh goodness, you are correct! Max is exclusive for integers, its only inclusive for floats. Thanks for pointing that out.

In terms of the value going over, I noticed this and it requires the player to say higher if the number is actually correct which I figured is not logical. So, if your number is 1000, the guess is 1000, you got it correct, but pushing higher will produce a guess of 1001.

We can also clamp the value, but I didn’t want to introduce that just at the moment.


#4

I’m uploading a patch for the video now, thanks again for pointing this out!


#5

Perhaps I am wrong, but if in the StartGame() there is a max=max+1 (so the program arrives at 1000) before calling NextGuess(), then there is no need to do OnPressLower max=guess-1 to do then in NextGuest max+1. The random will begin between 1 and 1001 (1 to 1000), and the max will be always 1001 until OnPressLower() is called. Then max will be the guest and the program doesn’t need to do -1 in OnPressLower() following a +1 in NextGuess().

I think this explanation is the most confusing thing I have written this last week… :sweat_smile:


#6

Well, I used your patch of max = guess - 1, and unfortunately it doesn’t fix the issue totally. If you keep pressing higher over and over, you might get to 1005 as I did. I don’t know the best fix however, as I am not a good programmer (yet!).

Edit: Actually, if you get to 1005 and press lower than higher several times, then lower, then higher again several times you can keep going up forever!


#7

A game within a game!

We chat about this in upcoming videos, especially in an instructor hangout on this topic.


#8

HI, Rick!
Thank you for the course!
In the lesson you fix the random guess and it is invoke the wrong behavior.
When you click only “higher” your guess will be 1000, when you click it another time min will be 1001 and we can get wrong guess. If I have the same code as you and if my code is right, we need to check if min < max, and if it’s wrong, we have to assign max to min.


#9

Thanks for your post. I do discuss this in upcoming videos. One of the assumption I am making at this stage is that the player will not lie - they will click correctly when the guess is at 1000. There are ways to fix this, which I discuss in some later videos.


#10

Hello!

I’m doing something wrong or if the player press Higher after the guessed number becomes 1000, the guessed number continues to grow to 1001, 1002, …


#11

Yes that is a known issue. For now we are assuming that the player would have correctly clicked when the correct guess was made. We talk about this in one of our instructor hangouts.


#12

I used this for the NextGuess() method to stop the the number from going out of bounds while max is equal to min

void NextGuess()
{
    if (max != min)
    {
        guess = Random.Range(min, max + 1);
        guessText.text = guess.ToString();
    }
}

#13

Thank you Bucky! You inspired me to try something slightly different because this was bugging me, too:

void NextGuess()
{
    if (max >= min)
    {
        guess = Random.Range(min, max + 1);
        guessText.text = guess.ToString();
    }
}

#14

Hi Will - your solution worked for me, thanks for that. I had made a typo and forgot to add the +1 to the max, but found that it still worked.

    void NextGuess()
{
    if(max >= min)
    {
        guess = Random.Range(min, max);
        guessText.text = guess.ToString();
    }
}

#15

I wanted to make this absolutely bugfree, so I came up with the following addition to make it work.

Instead of in the NextGuess() method, add an if-statement in the OnPressHigher() and OnPressLower() methods:

public void OnPressHigher()
{
    if (max > guess)
    {
        min = guess + 1;
        NextGuess();
    }
    else if (guess == 1000){Debug.Log("The maximum you can choose is " + max);}
    else{Debug.Log("You said it would be lower than " + (max + 1) + ". You're lying!");}
}

public void OnPressLower()
{
    if (min < guess)
    {
        max = guess - 1;
        NextGuess();
    }
    else if (guess == 1){Debug.Log("The minimum you can choose is " + min);}
    else{Debug.Log("You said it would be higher than " + (min - 1) + ". You're lying!");}
}

Note that the else if and else statements are just for debugging, to see if the part of the code is being executed when expected. Possibly if you know what you’re doing, you could attach a pop-up message to show the player why his input is wrong.

In short, this is what the code does:
OnPressHigher() checks if the max is still higher than the guess. If so, it can execute the code. If the max isn’t higher than the current guess, that means the player shouldn’t be able to say his number is higher than the guess.

Same with OnPressLower() but looks at the min instead of the max: if the min is lower than the current guess, execute the code. If the min is not lower than the current guess, the player should not be able to say that his number is lower than the current guess.

I hope this helps anyone who is also looking for an airtight solution. (If it’s not airtight, please let me know, I might just have missed something.

Extra note: I hard coded in the max and min for the debug message of reaching the max and min, you could choose to set these to variables, but they will have to be seperate from the current max and min variables. Create a initialMax and initialMin in the Class scope, set them to max and min in the StartGame() method and voila, you should be good to go.


#16

This code works for me, it just ignores the button presses if the min and max are equal or if min is 1 less than max. Let’s say min is set to 1 and max is set to 1000. Since max is exclusive, it would never take the guess of 1001. So the only maximum choice is 1000 because that’s what min would eventually become, or 1000 because it can’t ever guess the actual max value. If they are equal, then the lower and higher buttons are more or less disabled because of return.

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

public class NumberWizard : MonoBehaviour {
    [SerializeField] int max;
    [SerializeField] int min;
    [SerializeField] TextMeshProUGUI guessText;
    int guess;

	// Use this for initialization
	void Start ()
    {
        max += 1;
        NextGuess();
	}

    public void OnPressHigher()
    {
        min = guess;
        NextGuess();
    }

    public void OnPressLower()
    {
        max = guess;
        NextGuess();
    }

    void NextGuess()
    {
        if (min == max)
        {
            return;
        }
        guess = Random.Range( min, max);
        guessText.text = guess.ToString();
    }

}

#17

Hey Rick,

I just wanted to give a little feedback on the challenge for this one in regards to the above issue (numbers going above 1000)

I had gotten the code to stop showing repeats the correct way during the challenge, but then I tested it and I noticed this issue of it counting above 1000 and I had assumed I had done it wrong. I spent a lot of time trying to figure it out and then in the end figured I couldn’t do it the right way and I just went back to the video. Turns out I had done it right but that was just a new bug.

After that it never came up again and it left me very confused. Just wanted to give my personal experience with that one!

Loving the courses so far otherwise! I really liked the bonus points part of the challenge. It’s nice to have extra stretch goals.


#18

Instead of making min = guess + 1 for all cases, why not just add 1 when min isn’t equal to 1000?


    public void OnPressHigher()
    {
        if (min != 1000)
        {
            min = guess + 1;
        } else
        {
            min = guess;
        }
        guessedNumber = min;
        NextGuess();
    }

This completely eliminates the problem of adding 1 to min when min was already at its max (1000).
Also, I don’t see the point of subtracting 1 from max when in Random.Range, max is exclusive. So subtracting 1 just restricts an extra number that you shouldn’t be excluding.

I’m not sure if my solution is great or not, but it definitely fixes any errors found in the original solution without changing the original solution much.


#19

The issue with Sarah and Rob’s solutions are that they’re back to ‘hard coding’ the 1000 maximal figure. i.e., it will break again if you changed the Game object to a different max value.

Will’s solution is very graceful, but you could also extend the code out to acknowledge the error. You could even change your ‘Success’ button text to ‘Hm, try again?’ or something similar using what is learnt in the course so far. :slight_smile:

@Rick_Davidson - I think this bug does at least need acknowledging in the video. I went back and checked again when you were testing the fringe cases when I noticed this error myself and thought I was going insane.

I think it’s OK to make the assumption for now that the human plays straight and doesn’t make any mistakes - there isn’t a need to introduce the ‘fix’ for it now per se if you’d rather not, but it does need a mention I think is my strong feedback on this one!


#20

Thanks Naithin, we do indeed cover this topic a couple more times before the section is done.