The default way of working with SpriteKit is to have the
SKScene instance capture all the inputs and then have logic within that scene file to figure out the user’s intention.
In order for this to work,
SKNode instances added to this scene have their
isUserInteractionEnabled property set to
false by default. This property prevents these nodes from capturing input and are effectively invisible to the event chain.
I have been working on a library of basic components that is designed to work for many different types of game. It abstracts away platform-specific inputs, converting them into platform-agnostic interactions.
Taking this a step further, I have expanded this into an instruction system that takes advantage of Swift’s features to create an
Instruction struct. This struct uses pseudo-English formatting that makes adding actions to entities simple and easy to read:
The docs for SKNode say that the hit test order is the reverse of the render order (i.e. hit testing works from the topmost node down), but this isn’t strictly true.
It implies that if you have two nodes overlapping and the top one is not participating in hit testing, then the next one down will get the event. Unfortunately, this isn’t what happens.
I have a sketchy, working version of AdventureKit:
Since I announced that I was working on it last year, it has grown considerably.
After taking a hard look at what I’ve done so far, I realised that there are some fundamental problems with it. It has become more complicated and the interactions between components have gotten messy.
It also has a few key things missing that would be tricky to add at this stage:
I’m in the process of developing a library of useful, reusable components that could be dropped as an external library into a SpriteKit project.
They include things like my
NodeComponent and an abstracted way of managing three different kinds of input from either macOS or iOS (single tap/left click, double tap/right click, and pan/mouse drag). It also has a physics component and a render component—things that come up in games of all different types.
The components often have a lot of editable properties that affect how entities behave in the game. Tagging these properties with the
@GKInspectable tag allows you to use these components within the SpriteKit visual editor.
I have a game project with two targets, one for macOS and one for iOS. I want to use the same
SKScene file for both. I add the
SKS file and set the targets as follows:
Now that the physics is working for this basic node component, let’s make it a full contact sport. Contact detection is a huge benefit of using a physics engine, so in this SpriteKit tutorial I want to make sure that we can still enjoy those benefits while adhering closely to my weird interpretation of Entity Component Systems.
Now that I have node components working in SpriteKit, it’s time to add something more dynamic than tapping to add a node that then doesn’t do anything.