UPGRADE YOUR SKILLS: Learn advanced Swift and SwiftUI on Hacking with Swift+! >>

SOLVED: Project 23

Forums > 100 Days of Swift
@Sammy  

i am having difficulty understanding the function below.

https://www.hackingwithswift.com/read/23/4/enemy-or-bomb-avaudioplayer

func createEnemy(forceBomb: ForceBomb = .random) {
    let enemy: SKSpriteNode

    // I dont understand the 6 lines below  
    var enemyType = Int.random(in: 0...6)

    if forceBomb == .never {
        enemyType = 1
    } else if forceBomb == .always {
        enemyType = 0
    }

    if enemyType == 0 {
        // bomb code goes here
    } else {
        enemy = SKSpriteNode(imageNamed: "penguin")
        run(SKAction.playSoundFileNamed("launch.caf", waitForCompletion: false))
        enemy.name = "enemy"
    }

    // position code goes here

addChild(enemy)
    activeEnemies.append(enemy)
}

3      

@roosterboy  HWS+

Keep in mind one rule in this function:

If enemyType is 0 we create a bomb, otherwise we create a penguin.

var enemyType = Int.random(in: 0...6)

We are creating a new enemy and assign it a type randomly. This is a number within the range of 0 to 6. This line adds an element of randomness to whether we will create a bomb or a penguin each time the function is called.

This function takes an optional parameter that can be either .random (the default), .never, or .always, which determines whether or not the newly spawned enemy can be a bomb.

If the forceBomb parameter is set to .random (which it is by default), then we can just use the number generated for enemyType above.

However we should take the forceBomb parameter into account...

if forceBomb == .never {
    enemyType = 1
} else if forceBomb == .always {
    enemyType = 0
}

If the forceBomb parameter is set to .never, we don't ever want a bomb. We set enemyType to 1.

If the forceBomb parameter is set to .always, well, we always want a bomb. We set enemyType to 0.

Remember the rule I stated at the beginning of this post.

Now we come to the meat of this function. We create a new enemy based on the value of enemyType.

if enemyType == 0 {
    //create a bomb
} else {
    //create some other non-bomb type of enemy
}

If we have an enemyType that is 0 we create a bomb. If the forceBomb parameter was set to .always, then enemyType has been set to 0 and we'll always get a bomb.

If we have an enemyType that is not 0, we create a penguin. If the forceBomb parameter was set to .never, then enemyType has been set to 1, which is not 0, and we'll never get a bomb.

Essentially, we use a random number to determine if we get a bomb or a penguin, but then use the value of the forceBomb parameter to supersede that random number and force the outcome we want.

Make sense?

4      

@Sammy  

This explanation has somewhat made sense, but I still have a few more questions.

If the forceBomb parameter is set to .never or If the forceBomb parameter is set to .always, wouldn't this ruin the randomness of the game? I understand that .random is the default parameter, but in which scenario would we ever want .always or .never?

Why would we want forceBomb to supercede the random enemyType?

3      

@roosterboy  HWS+

Paul addresses this in the page you linked:

An additional complexity is that in the early stages of the game we sometimes want to force a bomb, and sometimes force a penguin, in order to build a smooth learning curve. For example, it wouldn't be fair to make the very first enemy a bomb, because the player would swipe it and lose immediately.

3      

Hacking with Swift is sponsored by Essential Developer

SPONSORED Join a FREE crash course for mid/senior iOS devs who want to achieve an expert level of technical and practical skills – it’s the fast track to being a complete senior developer! Hurry up because it'll be available only until April 28th.

Click to save your free spot now

Sponsor Hacking with Swift and reach the world's largest Swift community!

Archived topic

This topic has been closed due to inactivity, so you can't reply. Please create a new topic if you need to.

All interactions here are governed by our code of conduct.

Swift breaks down barriers between ideas and apps, and I want to break down barriers to learning it. I’m proud to make hundreds of tutorials that are free to access, and I’ll keep doing that whatever happens. But if that’s a mission that resonates with you, please support it by becoming a HWS+ member. It’ll bring you lots of benefits personally, but it also means you’ll directly help people all over the world to learn Swift by freeing me up to share more of my knowledge, passion, and experience for free! Become Hacking with Swift+ member.
Click here to visit the Hacking with Swift store >>
 
Unknown user

You are not logged in

Log in or create account
 

Link copied to your pasteboard.