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:
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.
For the third time in the last couple of years, I’ve found myself reaching for Apple’s Scanner class. Every time I use it I find myself tripping over the deceptively simple API.
This is my attempt to document it in a way that I understand for future reference.
(You’re welcome, future me.)
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.
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.
Now that I have a game where pieces are randomly placed and the player can drag them into position to win the game, I want to make things more difficult.
When the game begins, as well as being randomly positioned, the pieces will be randomly rotated.