Disadvantages to this approach for the Project Boost Course

Unity Courses Ask
,
#1

Hi All,

I’m enjoying this course. I realize there can be multiple answers/approaches to the same problem. This was my approach to the course. I essentially just created a Function to handle the level/scene loading and reloading instead. I heard what Rick said about having menus for scenes; however, I suspect that I would have an entirely separate script that would be checking for a Key Press or a special condition to be met.
I also would anticipate that any additional menu or other non-playable level/scenes I would probably arrange for those to be the first or last scenes of the scenes in build, and simply account for those in the index by setting a constant and utilize basic arithmetic to account for the max levels.

Acknowledging my limited experience regarding game design and programming, what issues can I have with this approach in the future?

public class CollisionHandler : MonoBehaviour
{
const string FINISHTAG = “Finish”;
const string FUELTAG = “Fuel”;
const string FRIENDLYTAG = “Friendly”;
int currentSceneIndex;
int maxLevels;
void Start()
{
currentSceneIndex = SceneManager.GetActiveScene().buildIndex;
maxLevels = SceneManager.sceneCountInBuildSettings;
}

void OnCollisionEnter(Collision other)
{
    switch (other.gameObject.tag)
    {
        case FINISHTAG:
            Debug.Log("Collided with: " + FINISHTAG);
            currentSceneIndex++;
            LevelHandler();
            break;
        case FUELTAG:
            Debug.Log("Collided with: " + FUELTAG);
            break;
        case FRIENDLYTAG:
            Debug.Log("Collided with: " + FRIENDLYTAG);
            break;
        default:
            Debug.Log("You Exploded!!!");
            LevelHandler();
            break;
    }
}

void LevelHandler()
{
    Debug.Log(currentSceneIndex);
    if (currentSceneIndex == maxLevels)
    {
        Debug.Log("Congratulations!!! YOU WON!!");
        currentSceneIndex = 0;
    }
    SceneManager.LoadScene(currentSceneIndex);

}

}

#2

Hi Aaron,

Your reasoning makes sense in the context of this game. A separate class for checking the user input is a matter of personal preference. As long as you have good arguments, “everything” is fine.

Regarding your collision handler, I like that you defined the strings as constants. That makes your code more maintainable as one will not have to scroll through your code to “update” the tag strings. Editing them at the top of the code is sufficient.

Regarding the LevelHandler method, it is common practice to name one’s method in the manner of “DoSomething”. The name LevelHandler sounds like a class. This indicates that there “should” be a class. Furthermore, one could argue: What does a level have to do with collisions? If the answer is “nothing”, it is good practice to to create separate classes to reflect those independent concepts.

maxLevels is a good idea. However, since you use it only once, you could tidy your class up by making maxLevels a local variable of LevelHandler. Also, SceneManager.sceneCountInBuildSettings is not “expensive”, so you don’t need to assign it in Start(). The same applies to currentSceneIndex as you do not use it anywhere else but in the LevelHandler method.

Acknowledging my limited experience regarding game design and programming, what issues can I have with this approach in the future?

I wasn’t able to spot actual issues. What I wrote above are just ideas how to improve your code in regards to OOP principles. Keep up the good work! :slight_smile:

See also:

1 Like
#3

Hi Nina,

Thanks for taking the time to respond with such thorough feedback. I 100% agree that the level handler should really be in a class or a separate game manager script; however, that’s just where I am currently in Rick’s course with Project Boost.

I did do the max levels deliberately that way, because I’m anticipating we/I will build more levels for this game, but that definitely could be made local.

I’m undoubtedly being influenced by the VBA macros I’ve done prior, and I was always trying to make things solved programmatically where possible; however, I am usually trying to set many of those near the top of my script, which isn’t really needed in this format, and it could just add to the confusion when I come back and try to read my code.

As I write this, I’m realizing that when you have one line calculating that’s less of an issue, but when you have dozens or hundreds of such calculations, that could be performance needlessly spent.

Again, thank you. I appreciate the feedback, and I will definitely incorporate your suggestions and thoughts!

#4

When writing code, always keep your future self in mind. If you aren’t able to read your code, other people will probably not be able to read it either.

Apart from that, feel free to explore your ideas. There is no universal solution that works for all Unity projects. By testing your ideas, you’ll learn what the advantages and disadvantages are in the context of your game project(s), especially in comparison with other people’s (here: Rick’s) ideas/concepts.

Have a nice weekend. :slight_smile:

#5

This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.

Privacy & Terms