1

In my game I spawn many enemies with random coordinates, but they share the same internal data.

Currently I have a function SpawnEnemy() who looks like this:

func spawnRedPawn(timer: NSTimer) {
    var redPawn = Ship(entityNamed: ESHIP_REDPAWN)
    let action = SKAction.moveToX(0, duration: timer.userInfo as! NSTimeInterval)
    let actionDone = SKAction.removeFromParent()

    redPawn.position = CGPoint(x: self.size.width, y: CGFloat(arc4random_uniform(UInt32(self.size.height - redPawn.size.height))))
    redPawn.setupPhysicsBody(PC.enemy)
    redPawn.setupContactTestBitmask([PC.projectile, PC.player])
    redPawn.addEmitter("propulsionParticle", offset: CGPointMake(redPawn.size.width / 2 + 5, 0))
    redPawn.runAction(SKAction.sequence([action, actionDone]))
    self.addChild(redPawn)
}

PS: the function format (called by NSTimer Selector()) will probably be changed

I am new to SpriteKit but I feel that this setup process is quite resource intensive right?

My question is: is it possible/would it be better to run this fonction only once, and then only duplicate the created enemy?

  • Aside from performance question, note that NSTimer don't respect view's, scene's or node's paused state... So you should use SKAction for time related stuff. – Whirlwind May 23 '15 at 13:29
  • I already use SKAction, the timer is used for creating a new enemy every X second (creating the node, setting the action, and running the action). Is it heresy? –  May 23 '15 at 13:30
  • @Mayers It could make a problem if you use NSTimer for that. Imagine that you spawn new enemy every five seconds, and eventually user pause the game...After some time, let's say a minute, because NSTimer don't respect the paused state of scene, you'll have a bunch of enemies on the screen. Which is not what you want... – Whirlwind May 23 '15 at 13:33
  • Yhea i already experience this problem. I thought of making a class with function like `startTimer() pauseTimer() invalidateTimer()`. Is that wrong? If so, do you have any insight of using Action as i use NSTimer? –  May 23 '15 at 13:34
  • 1
    That's another question, but I think everything is explained here : http://stackoverflow.com/a/23978854/3402095 – Whirlwind May 23 '15 at 13:36
  • Wow great forwarding. Many thanks –  May 23 '15 at 13:43

1 Answers1

3

Here are some basics that you should know:

What you can do (especially if you are experiencing performance problems) is to:

  • use texture atlases. This way you are reducing number of cpu draw calls required to render a sprites.

  • cache different resources like emitters (or sounds). This way you are keep them in memory and you don't need to read them from disk. Search Apple's Adventure game to see how you can cache the resources. Basically, you preload everything before gameplay using the completion handler.

One way you could go is to pre-create a bunch of nodes and use them until game is finished. This way you won't re-create the SKSpriteNodes many times (which sometimes can cause noticeable lag). Here you can read about that.

Important:

  • Don't take simulator results into account, because those are not realistic. If you are interested in real information about performance you should test on device.

Hope this helps a bit.

Community
  • 1
  • 1
Whirlwind
  • 14,286
  • 11
  • 68
  • 157
  • Thanks for sharing these wise infos. I don't have performance issue, but I dont want to have to rethink my whole structure in few days when it will appear (if it appear, that's my question. What's your thoughts about that?) –  May 23 '15 at 13:32
  • @Mayerz It is always good idea to put everything "on paper" before actual apps implementation. Just be aware of premature optimization. – Whirlwind May 23 '15 at 13:51
  • 1
    @Whirlwind - Agreed. I think every developer has had a problem with premature optimization at some point :) – sangony May 23 '15 at 14:05
  • Ok ok, i keep all these wises infos and keep developing, if i encounter problems I will turn back to this (excepted for the SKAction/NSTimer thing which I will replace immediately.) Thanks for all –  May 24 '15 at 00:44