This solution seemed over complicated, any reason not to do it this way?

Unity Courses Talk
,
#1

I thought the bookkeeping of tracking bricks seemed like a lot of extra code when we already had objects with the Breakable tag that we can count. Also it is prone to error if say you add bricks that create more bricks on the screen.

I added this to my LevelManager.cs:

	void Start(){
		if (Application.loadedLevelName.StartsWith("Level_")) {
			InvokeRepeating("CheckForBreakableBricks", 1.0f, 0.2f);
		}
	}
	
	public void CheckForBreakableBricks(){
		var breakableBrick = GameObject.FindGameObjectWithTag("Breakable");
		if (breakableBrick == null) {
			LoadNextLevel();
		}
	}
1 Like
#2

I like it, but there are optimization issues. Searching for stuff is always an intensive process, and you are doing that every .2 seconds?

But if it works, then go for it. I see nothing wrong in the logic.

1 Like
#3

From what I can tell Unity keeps a list of all objects with tags so if that is the case then the performance would be O(n) in a worst case (where n is the number of objects with tags).

#4

There’s nothing that takes 0 of processing. Every method that looks for something will be heavy performance wise, you would be better off saving reference of every brick on the start() event and check if it’s not returning null. Loops are very heavy too, it is better to avoid them, you can call this method whenever a brick is destroyed (within the brick destroying process)

#5

I think maybe you misunderstood my Big O notation to be zero multiplied by n?

#6

Of course I misunderstood that you were talking about Big O and binary logarithms :unamused: You can’t throw an reference like that without saying what´s about…
There’s no reason to use a loop when you have events that could call the CreckForBreakableBricks(), like when the brick gets destroyed.

But other than that I do agree that this logic is better than the one used in the class since it looks of the “core” for the problem that you are solving (finding out if there is any active breakable brick), just feel that the loop is unnecessary.

#7

That is true, I could call it from the Brick class and then I wouldn’t need the timer loop. I guess early on I decided the Brick shouldn’t even know about the LevelManager so I removed the reference and didn’t even think to consider that route.

From a decoupling perspective I like that the Brick class doesn’t even need to know about it because then if you add other win conditions you might be able to consolidate them all in the LevelManager more easily.

1 Like
#8

Yeah, looking from a decoupling perspective it is better to keep this way :slight_smile:

Privacy & Terms