The Unity5 deprecated Application.LoadLevel()
is a perfect example of why separating your code out can be so useful.
So with the game written in Unity5 using Application.LoadLevel() without using something along the lines of the LevelManager, your calls to load the levels will be scattered across the game.
Does this matter? The game still runs? Might depend where you want to draw the line I suppose.
Right now it will work as intended, fab! But what about when we want to change something? The deprecated method is a great example. If you use something like the LevelManager, which handles the loading of levels and perhaps other “level” related concerns, all of the “now load me the next level” type method calls across the game will point to this one object. When it comes to making changes, especially during the upgrade to Unity5, you can make them in the one place rather than across the entire application.
So, whilst it might be a few extra lines of code now, the time it will save you in the future will invariably pay dividends.
So, why not break everything into a million little parts and separate everything? It’s a balance. Trying not to do too much more now but at the same time not knowing causing big problems for the future.
In the specific case of the LoseCollider - should it really load the lose level? In this small version of the game, yeah I guess that’s ok… but what if your player had more than 1 life? Be nice not to have to start the whole game again So in that case you may want to load the same level, change the number of lives, update the number of lives on the screen, adjust the score, play a sound, animate an image - the list goes on…
As you add all of those wonderful things, that’s quite a lot of extra lines of code in the LoseCollider - and should it really have them all there? I may want to play a sound else where in my game, so now I’m duplicating that code. I will most likely want to update the score, so now I’m duplicating that code. If I can lose lives, chances are there is a mechanic for gaining them, so now I’m duplicating that code…
What happens when I find a bug in one of those features… now I have to change it in multiple places throughout the game…
I’m sure you get the idea…
As a rule of thumb, I tend to start refactoring my code the moment I find something doing pretty much the same job in more than one place, because if I’ve used it twice, chances are I’ll use it three, four or more times across the application.
It’s really worth considering the separation of concerns, what things should do what and what things should know about other things.
If I have a piece of code separated away for handling the addition and subtraction of lives from a player object, it doesn’t actually matter what causes the addition or subtract (getting a specific score, collecting a power-up, completing the level, or losing the ball, crashing into an enemy, running out of time etc), all it has to do is what it’s told, increment or decrement the lives of the player. As @Joao_Dalvi mentions above, it also provides a means of re-usability, if its generic enough it code be easily used across multiple games and without change.
This kind of approach isn’t perhaps a lot of fun to start a course off with, but the use of the LevelManager is perhaps a simple way of injecting an approach without it being too full on. It can however be a lot of fun as you get in to it, I personally find it really rewarding to refactor code and make it more generic, more usable, more maintainable…
Anyway, bit of a lengthy response but I hope there is something of use scattered amongst my many words! (sorry)