How to Use GameplayKit in an Arcade iOS Game
Make your game structured with GameplayKit
It’s my turn to take the skScene! Ha-ha! No? Ok fine…
Hi, I’m Oreste and if you’re here it probably means that you have your first game with a SpriteKit Scene, and if not , I really suggest you to check the first part of this tutorial by Luigi Minniti about SpriteKit.
But now, what you can do to go to the next level? Do you know how to handle a full game, making it clean enough to ensure efficient scalability and without having to rewrite multiple times something you already made available inside the project?
Then,
We need to talk about GameplayKit.
GameplayKit is a framework developed by Apple introduced in iOS 9 and macOS X.11 that provides the infrastructure that is common in many types of games.
It lets you focus on the gameplay and rules of what your game is about minimizing spaghetti-code-like writing and it requires only an interface based on Objective-C or Swift.
With GameplayKit it’s all about structure.
One thing that can often happen to developers is this massive scene that hides everything and makes their life harder and that’s something very predictable, especially with SpriteKit.
Once you start a new project Xcode gives you a certain direction, a class that inherits from SKScene already settled to handle inputs, frame update, node hierarchy, all physic management, etc…
But these are only small building blocks and if you put them all together sooner or later…
[ you’re gonna have a bad time ]
It’s ok to start this way, but that’s not something you wanna do in the long run.
To be honest with you, I don’t see myself as an expert but I thought about showing you a few things that I’ve learned so far while looking into GameplayKit for the realization of my last two projects and in particular, as WillPower version 0.0.1(3) went out, ECS and State Machines, using also something I looked for when studying it and that you all should be familiar with: Pac-Man!
Entity-Component System
ECS is the acronym of Entity-Component System, a Software Engineering practice that Apple encourages us to adopt in our project while developing our game, nothing new, just a common practice in Game Development.
Instead of having your code stuck inside the scene or in a SKSpriteNode subclass, you have these more abstract things called entities that represent objects in your game ( player, enemy, wall, anything ) that have only few data and information needed, while you put everything else inside Components.
Each Entity is a GKEntity, or more likely a subclass of it, in which you add your needed properties that are only data, you don’t want your functionalities to be put in there.
class WPEntity: GKEntity{
//........
}For them, you use components, subclasses of GKComponent, then add them to the entity. You only write once, to give this functionality to every entity you want.
This is a massive improvement toward independence, modularity, scalability, and maintenance.
Let’s make an example with a Pac-Man-like game starting with the inheritance of the classic object-oriented paradigm: A Pac-man game relies on elements such the player, ghosts, fruits, pellet, and power pellets; let’s focus on player and ghost for now.
As a superclass of both we can think of a Renderable Class because we need in some way to display them, it’s one of the first things to imagine. Pac-Man is also subject to player input, so we make it inherits also from a Controllable Class.
But what if after I want to make my game a multiplayer party game, maybe through a playable ghost? Or make it harder with invisible ghosts? You may already see some problems emerging as the number of characters scales up. How to set up the inheritance chain? Playable Ghost could inherit from ghost but it also need to be controllable; Invisible ghost is indeed a ghost but what about Renderable?
Let’s try to switch to ECS:
Pac-Man and Ghost are subclasses of Entity and Invisible Ghost and Playable Ghost inherits from Ghost. Already an easier concept as it follows semantics.
As we said earlier we can think of their functionalities broke down as only 3 components: Renderable, Controllable, and Respawnable.
Once you create those, you can add them to the entities that have that piece of functionality and you’re good to go! You can also use ComponentSystems to manage every instance of certain functionality.
State Machines
Every game has to worry about Game States: it’s all about them and how they change. They are representations of what is happening and they impact everything like how you handle input, how you display information etc…
If you just were to dump all that code into your scene or even in an Entity object, you might end with a massive chain of if-else that are hard to debug, extend, to deal with in general.
GameplayKit includes a way of doing state machines so you can deal with them so let’s make an example with Ghosts behaviors:
A Ghost has 4 states:
- Chase, in which it tries to reach the player;
- Flee, enabled by eating a power pellet that makes it run away from pac-man to not get eaten;
- Defeated, when the player eats the ghost;
- Respawn, when it goes back to their cell to start again with the chase state.
To implement this structure, we create an instance of GKStateMachine, which you give a list of state that each of them has to be a specific subclass of GKState. The idea is whenever you have to make some decisions or do some functionalities that depend on that state, you put that functionality in the state you wanna deal with, and you can achieve that overriding method according to what you want to happen for example during transitions, entering, leaving, etc… [ didEnter(from previousState:GKState) ; willExit(to nextState:GKState) ]
Here’s another example with the State Machine I used in WillPower for the Health Component:
Declaration inside Health Component:
States classes:
Wrapping it up
I really encourage you to give GameplayKit a try, it really simplified my workflow allowing to make WillPower in just 3 days!
If I discover something new I’ll try to update this article and don’t hesitate to reach me to discuss it and keep developing! ( mostly games! 👾 ).
If you want, check the article my colleague and childhood friend Matteo Morena wrote about WillPower, the game we developed together.
