More methods for the sake of more methods?

I’m curious if there’s a reason why you separated SpawnAttacker() into two different methods? It’s more code with not a lot of gain from what I can see. When I did the challenge, I simply created the array as you did, but chose an enemy from the array during the instantiation:

private void SpawnAttacker()
{
    Attacker newAttacker = 
        Instantiate(attackers[UnityEngine.Random.Range( 0, attackers.Length)], 
        transform.position, Quaternion.identity) 
        as Attacker;
    newAttacker.transform.parent = transform;
}

I could see doing it if you’re trying not to put too much on one line, but that seems to be a personal preference.

I agree with you. I did something very similar to how you handled it here. I see no real reason for the extra method, unless there’s something I am missing…

Here’s how I did it:

    private void SpawnAttacker()
    {
        Attacker newAttacker = 
            Instantiate(attackerPrefabArray[Random.Range(0, attackerPrefabArray.Length)], 
            transform.position, transform.rotation) as Attacker;
        newAttacker.transform.parent = transform;
    }

Hi,

I just finished this course and i did almost the same thing like Rick. The reason for this is; in simple words one method - one responsibility. This way i have a method that calls a specific attacker and a method that can randomize attackers. Lets say i want to call a boss at the end of the level, i already have a method to call a specific attacker.Or i want to create a level that only lizards are attacking and the next level is for only fox attackers… and so on… In the long run i can use these methods without creating something extra and achieve more things… basically your methods should not do many many stuff, its responsibility should be clear, but this is not a rule just an approach.

what you did isn’t wrong for this course, and may be more than ok for the course,. Hopefully you get the point of creating a new method here. As i said it is just an approach not a rule, not wrong or right either.

Privacy & Terms