This is part 2 of my attempt to document the process of creating a simple jigsaw puzzle game in excruciating detail.
To create the puzzle images, I want to be able to take a Photoshop document, slice it up using the selection tools, then export those sliced-up layers. I also want to use a script to automatically generate the final, correct locations for all of the pieces and write them to a JSON file that will work on all devices.
I was recently playing The Black Mirror and one of the earlier challenges is a jigsaw puzzle where you have to reconstruct a torn up photograph.
The player clicks on a piece to activate it, then they can move it around using the mouse or right-click on it to rotate it to one of four preset rotations. They click again to release it. When a piece has the correct rotation and is near the correct position, it snaps into place, which works as visual feedback that it has been placed correctly.
It was an enjoyable break from the exploring and it got me thinking about how I might add it as an optional mini-game type in my adventure game engine.
As I’ve been working with Entity Component Systems in SpriteKit, I’ve come to realise that Apple’s implementation of the pattern is subtly different to what I understand is the ‘pure’ form of this pattern.
Since I started my series about handling movement, I’ve learned a lot more about Entity Component Systems and I’m changing the way my engine is structured to reflect this.
While this sounds like a Typical Simon Rabbit Hole, it has fundamentally changed how I approach game engine development and I have made some huge strides with very minimal effort. Thanks to the advantages of ECS, some features that I thought would have to wait for many versions down the line have become trivially easy to implement.
In part one, I set up a Movement Component that moved sprites around a space without any regard for the type of scene that they inhabit.
However, many adventure game scenes have some sort of perspective where it’s possible for players to move around an object.
Imagine a game where, say, a character in a trench coat is visiting a square in Lecce, Italy. For some reason, there’s a crate in the middle of it:
In my initial prototype I used SKActions exclusively to handle movement. It’s a fire and forget solution—I create an action with a destination point and a duration and run that action on a sprite. SpriteKit will move that sprite to the given point over the given time without me having to think about it again.
let moveAction = SKAction.moveTo(x: hasTarget, duration: length / moveSpeedInPointsPerSecond)
It’s great for many situations. However, there are a few limitations:
Since my last update, we have settled in Lecce, Italy for four weeks and I am back in the saddle and racing that horse as hard as I can towards the bright and glorious sunset that is AdventureKit 1.0.
Tortured metaphors aside, I have made some significant progress in the last two weeks. All of the Development tasks in my roadmap are just about complete which means I can now edit scenes directly on the iPad and have the changes appear in running scenes!
It has been almost a month since I last launched my AdventureKit Xcode project.
We have been doing some travelling in that time and I am now in Italy where there are many things to see and do (including the consuming of much delicious food and wine).