Chalenge

[Marky01]

Hey Teachers. Today i did a chalenge and i have different code than rick does i want to ask if it will not interfiere with future lessons thanks.

private void SpawnAttacker()
{
    Spawn(AttackerPrefabArray.Length);
}

private void Spawn(int index)
{
    Attacker newAttacker = Instantiate
        (AttackerPrefabArray[Random.Range(0, index)], transform.position, transform.rotation)
        as Attacker;
    newAttacker.transform.parent = transform;
}

[Nina]

Hi Marky,

Good job on developing your own solution. What is the difference betweem your solution and Rick’s? Do you see anything that could cause a problem in the future?

Generally, unless I know of a potential problem, I would not worry if your solution will still work in the future. Why? When you were able to write your solution, you will probably also be able to adjust it.

Furthermore, we try to follow the single responsibility principle, which is one of the main principles of object-oriented programming. This means that we try to make our “modules” not to depends on too many things.

When Rick instantiates an attacker in his code, he does not check a dozen conditions and does not rely on the existence of any external objects. He instantiates it. Done. Next problem.

If your solution does not do anything else but instantiating an attacker at the expected position, your solution should be fine. Our defenders will check if there are any attackers in their lane, not what algorithm placed them in the scene.

With this in mind, what do you think about your solution?

[Marky01]

I think there is no potential harm in my solution but wasn’t sure if we will be doing something with that method in the future because a haven’t seen the whole course thanks for respond

[Nina]

but wasn’t sure if we will be doing something with that method in the future

Don’t worry about that. As far as I can see, your code is fine. However, I’m no clairvoyant, and neither are you. You did your best. That should be sufficient for now.

The only time one should be wary is when somebody implemented a messy workaround because they were too lazy to write a (longer) proper solution. Messy solutions are always a potential source of errors and unexpected side effects.

That’s not the case in your code. Keep it up!