/Dev/World is a three day conference in Melbourne covering everything Apple-related. It was my first time there and it was incredible. All of the talks were excellent and everyone was welcoming and friendly.
These are my notes, published here mostly so that I can tie all the things I learned directly back to the people who taught me. Blockquotes are paraphrased from the talks.
In one of my many previous posts on screen sizes I mentioned that I have decided to use points and asset catalogs with scaled assets for AdventureKit.
A couple of weeks is all it took for me to revisit this.
It seems that Apple read my previous post about using iPad-sized assets across all devices and said to themselves “Best put a stop to that nonsense.”
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:
|
1 2 3 |
public enum Direction : String, CaseIterable, Codable { case center, north, northeast, east, southeast, south, southwest, west, northwest } |
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.)
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:
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.
