Working on a simple Lives system, constraining to original game design

Unity Courses Ask
,
1

Hey everyone,
Going back over this to help my students get a working lives system setup. What I have so far is the following. It’s in the LoseCollider script. I can’t figure out how to reset the Ball at this point. I’ve tried grabbing the object and manipulating the transform to no avail. Any ideas?:

void OnTriggerEnter2D(Collider2D trigger)
{
    lives--;
    Debug.Log(lives);
    if(lives <= 0)
    {
        Debug.Log("Lost");
        lives = 3;
        levelManager.LoadLevel("lose");
    } else
    {
        
    }
    
}
2

Assuming you have the Reset method inside the Ball.cs script, add these lines inside the LoseCollider script:

[code]private Ball ball;

void Start () {
ball = GameObject.FindObjectOfType();
}[/code]

and inside your else:

} else { ball.Reset(); }

2 Likes
3

…and if you don’t, consider what you need to have inside one…

  • stop the ball from moving by changing it’s velocity
  • change any flags you may have which indicate the ball is in motion
  • re-position the ball to the position it started from above the paddle
1 Like
4

Yeah resetting the position is my problem. Reading my own code, I am unclear how exactly the position of the ball was set. It seems like I set it by hand and constrained it from there. That seems to present a problem.

1 Like
5

That’s correct. In the lectures you positioned the Ball game object by hand. So, you could consider viewing the position in the Ball’s transform, and placing this in code instead. You could consider adding this as a method to your LevelManager which is actually called at the start of the game also, thus, reuse. Be sure to reset the PaddleToBallVector also.

1 Like
6

Here’s what I’ve got so far… It’s spawning two balls when the ball collides with the first brick. The rest of it works but… Yeah…

In LevelManager:

public void ResetBall()
{
    Debug.Log("Called");
    ball.transform.position = ballPos;
    ball.GetComponent<Rigidbody2D>().velocity = ballVel;
    ball.SetStarted();
}

in LoseCollider:

void OnTriggerEnter2D(Collider2D trigger)
{
    lives--;
    Debug.Log(lives);
    if(lives <= 0)
    {
        Debug.Log("Lost");
        lives = 3;
        levelManager.LoadLevel("lose");
    } else
    {
        levelManager.ResetBall();
    }
    
}

On the Ball:

public bool SetStarted()
{
    hasStarted = false;
    return hasStarted;
}
7

It seems odd that this happens from colliding with a brick doesn’t it? Might need to post your full code up.

1 Like
8

Never mind. I’m an idiot and had two ball gameobjects in my hierarchy. That seems to be working. I’m getting a nullreference exception from my LevelManager I need to track down. Thank you so much @Rob and @Galandil

2 Likes
9

Great to hear your are making progress Jason, and you’re more than welcome :slight_smile:

1 Like
10

The exception was occurring when the levelManager tried to locate a ball on the lose screen (it didn’t exist.) I fixed it with this conditional:

    ball = GameObject.FindObjectOfType<Ball>();
    if(ball)
    {
        ballPos = ball.transform.position;
        ballVel = ball.GetComponent<Rigidbody2D>().velocity;
    }
1 Like
11

If you find yourself checking for more than just the Ball, and the logic starts getting quite complex, you may find determining at the beginning of the game initialisation which scenes are playable and which are not useful.

For example, you know that Start, Lose, Win (the named scenes) are not playable.

So you could pop the non-playable scene names into an array and then, on loading the scene, check to see if the scene that has loaded is in fact a playable scene or not based upon its name being contained in that array.

The result of this check could then be set in a flag of Type bool, e.g. bool sceneIsPlayable.

Then, all of your logic around what should/shouldn’t appear or happen within that scene can be based around that variable.

1 Like
12

That’s solid information! I may give it a try. I’m considering rebuilding some or all of this game from the ground up with a potentially more streamlined scripting system. We will see if I have the time. Thanks again @Rob.

1 Like
13

That sounds like a great idea, not because you necessarily need to, to have a playable game, but by rebuilding it you will invariably find that, now you have a complete working game that you understand, you are in a much better position to redesign / restructure it’s architecture.

When you find yourself saying “should this really be in the lose collider” or, “should the ball really know about the player’s lives” etc, jot those down, either on paper, or as comments in the code with a “TODO:” in front of them, if you are wondering about these at any point it may suggest that something isn’t quite right and that it needs a little further consideration.

Let us know how you get on :slight_smile: