0

I am contemplating a simple app that has four characters that you can drag around on the screen. While dragging they "wiggle" — that's the animation. And they snap to a position if they get close enough to it... like in a puzzle. Without the animation, this is all simple in UIKit.

My first thought is to render each character in its own SKView inside a plain old UIView. I could attach UIGestureRecognizers to each SKView to track tapping and dragging. But I think this implies individual GameScenes for each character/SKView. That seems go go against the grain of SpriteKit.

The alternative is a single GameScene with the four sprites. But I would still need to track & drag them and I don't see how to do that within an all-SpriteKit app.

Is either approach better practice than the other?

Andrew Duncan
  • 3,553
  • 4
  • 28
  • 55
  • For performance issue, the second way is feasible. And since all sknodes are from UIResponder, it is not hard to handle touch events. – E.Coms Oct 03 '18 at 19:43
  • I would not use SpriteKit at all. UIKit is capable of animations – Knight0fDragon Oct 04 '18 at 12:57
  • I have about 200 different animations, and the animator is sending them to me in spritesheets. And I gather that SpriteKit handles memory better than `UIImageView.animationImages`. And I need to switch animations per sprite a lot. – Andrew Duncan Oct 04 '18 at 22:41
  • If your animator is working in a sprite sheet, then the technology wouldn't matter. You would have to break up the sprite sheet into individual images/files to take advantage of SKTextureAtlas. If you already have all the work done in UIKit, then you are just wasting time and energy rebuilding it from the ground up in sprite kit all for animations. – Knight0fDragon Oct 05 '18 at 13:59
  • There will be about 50,000 images in all, it's hard to see how I will break up the sheets into individual files, even with rigorous naming conventions. But my Q is: suppose I do that. Then how do I animate? Using `UIImageView's` animation methods? Roll my own with Timers or `CADisplayLinks` or what? It seems like leaning on SpriteKit to animate should be the easiest. FWIW, I am having more success with strategy from paragraph 2 ("my first thought") in my OP. But that def goes against the Cocoa grain. Would you like to take this offline? I am still at something of a loss. – Andrew Duncan Oct 05 '18 at 19:57
  • Forgive my animation naïveté. My background is in digital signal processing and compiler design. But in a startup I have to wear new hats. – Andrew Duncan Oct 05 '18 at 20:00
  • Hi @Knight0fDragon, Here is a video (http://andrewduncan.net/drag/drag.m4v) using the technique you described in https://stackoverflow.com/questions/39004565/how-do-i-drag-and-drop-a-sprite-in-swift-3-0. It shows terrible lag. Surely there's a better way? – Andrew Duncan Oct 05 '18 at 21:08

1 Answers1

0

You should implement the one that has a single scene and separate sprites for each character. The sprites will be SKSpriteNode instances which are SKNode instances, which descend from UIResponder and can, therefore, respond to touch events.

Look at the documentation for SKNode. It is a wealth of information that applies to sprites as well as to any other kind of node. In particular it says:

All nodes are responder objects that can respond directly to user interaction with the node onscreen…

And then later has a section on "The Hit-Test Order is the Reverse of Drawing Order" etc.

Scott Thompson
  • 22,629
  • 4
  • 32
  • 34
  • Yes, since I discovered that I can use `UIGestureRecognizers` with sprites I am leaning more to the second option, as you suggest. It's just so unfamiliar. Thirty years of writing code for Apple devices and I'm still a n00b! – Andrew Duncan Oct 03 '18 at 23:54
  • I started on the Apple ][+ in about 1981 :-) – Scott Thompson Oct 05 '18 at 00:44
  • You can't use `UIGestureRecognizers` with sprites, only `UIView`. You need to convert from view -> scene -> sprite, which is not what this answer is alluding to. This answer is telling you to use the `UIResponder` of the sprite, which is your `UITouch` events. The problem with this is you plan on dragging a sprite, which means you need to leave the bounds of the sprite to move him, or make the sprite bounds so large that it would have to cover the entire screen. – Knight0fDragon Oct 05 '18 at 14:02
  • Yeah, using the `UIGestureRecognizer` I had to attach it to the whole SKView and then figure out which thing to move. Not so convenient really. Unfortunately, just using the `touchesMoved` method in the `SKScene` results in *very* slow, lagging dragging. I tried subclassing `SKSpriteNode` to use the responder chain (which seems better anyway since each sprite will handle its own events) *but*... couldn't figure out how to get the sprites into the responder chain. As you mentioned above. So the questions remains: How the f*** do I drag sprites smoothly? – Andrew Duncan Oct 05 '18 at 17:05
  • I may go to using mvids and use Mo DeJong's library. (Needed because I need an alpha channel in videos). But that's a completely different production toolchain. Suggestions welcome! – Andrew Duncan Oct 05 '18 at 17:07
  • Ha, @ScottThompson, you are ahead of me. I cut my teeth (figuratively) on Inside Macintosh. What a work of art that was. – Andrew Duncan Oct 05 '18 at 18:12