The name 'health' does not exist in the current context

Question

I am getting this error when trying to make a text based adventure game. I dont know how to proceed without fixing this so.

public static void nukeCutscene() {
int health = 20;
int sanity = 20;
}

public static void dwaneDeath() {
  Thread.Sleep(200);
Console.Clear();
Console.WriteLine("A yellow-red explosion goes into your face.");
int explosionDamage;
System.Random random = new System.Random(); 
explosionDamage = random.Next(3,9);
Console.WriteLine("-"+explosionDamage+" health. ("+health+" health now)");
  }

Answer 1

Without wishing to sound rude or patronising, I think what you need to do is to work your way through a very basic coding tutorial first, and then move on to writing games later.

The issue you're seeing is due to a thing called scope.

health and sanity are only defined within the scope of the method nukeCutScene. They don't exist outside of that function. A different function like dwaneDeath simply cannot see into the local variables of another function.

One solution might be to move your variables into an enclosing scope, like this:

public class Program
{
    static int health = 20;
    static int sanity = 20;

    public static void nukeCutscene()
    {
        // this method can see the static variables health and sanity
    }

    public static void dwaneDeath() 
    {
        // and so can this one
    }
}

But seriously, start with the basics.

Answer 2

You can use IterableOnce but that would force you to get an Iterator which is always sequential.

This is a conscious decision from the maintainers, you can read all the related discussions by starting here: https://github.com/scala/scala-parallel-collections/issues/101
The TL;DR; is that the maintainers agree that it is a bad idea to provide an abstraction between two; mainly because parallel collections should not be used as general collections but rather as localized optimizations. Also, the point out how easy it would be to introduce errors if you could abstract over the two (as was the case in 2.12).

Now, if you insist you want to abstract over the two, you may create your own typeclass.

---

Finally, I may suggest looking at using Future.traverse instead of parallel collections.