I have a Direction enum that I use to position UI layers in my adventure game. It supports 8 compass directions plus a case for centre:
public enum Direction : String, CaseIterable, Codable {
case center, north, northeast, east, southeast, south, southwest, west, northwest
}
I’m going to be generating a lot of images over the coming months and I’ll be using many different apps to generate them.
So far, for my example adventure game, I’ve used Procreate, Adobe Comp, and Affinity Designer on the iPad and Photoshop on the Mac. I’ve also developed an asset management app on the Mac that I use to create the animation JSON data for my engine and that moves the assets into the asset catalog within the game bundle
A lot of what drives my entities happens in pseudo-systems. These systems are GKComponent subclasses where the update(deltaTime:) method goes in an extension in order to separate the verb part of the component from the noun part:
Update: I would say this method is still valid if you want to use single assets across all devices, but I am now using points and asset catalogs (even though it’s a lot of extra work).
I honestly thought I had it figured out.
I hadn’t.
I mean, I had. Except it’s always more complicated than that.
Let’s talk about scene sizes.
(Again.)
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.
One of the advantages of blogging about my work is that it makes me think carefully about what I’m doing. After finishing my post on my instruction system, I started reading more about closures which led me to reconsider some of the decisions I’d made.
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’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:
