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.
The test project I created for my SpriteKit components library is getting out of hand. Here is a panel from the introduction comic.
Yep, my example mini-game now has an introduction animated comic (if you were wondering why I haven’t released an actual game yet).
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.
Let’s get…physical.
(sorry.)
During my puzzle game process, I came up with a way that I could use a single Photoshop document and from this create larger sprites for iPads and Macs and smaller versions for iPhones.
Turns out that this might have had a case of Premature Optimisation (ladies…).
After the development of my simple puzzle game, one of the things I wanted to do differently was using a generic Node Component. This would be a component that would do all the scaling, rotating, and positioning in such a way that it could apply to any node type (label, sprite, shape, etc) or even things like particle emitters.
In this post, I’ll create a simple SpriteKit scene with a basic render system and a few simple components to see how this might work.
As I write this, I’m walking the Dale’s Way with nothing but my iPad Pro so this will all be done using the Swift Playgrounds app.
I have reached the end of my jigsaw puzzle game journey!
Documenting this process in as much detail as I did has been revealing. There were holes in my knowledge: things that I knew how to do without a full understanding of how they actually worked. Trying to explain every line of code forced me to reach for that deeper understanding.
Despite this, some of my decisions were still questionable and I would do certain things differently now. On the other hand, I was pleased at how other aspects came out and there are ways that I have implemented things in this that I definitely want to pull into my adventure game engine.