Now that we understand the basics of coding in Swift, the generic flow and class structure of an iOS app, as well as the optional structuring of apps with storyboards and segues, we can move on to transforming our apps into playable games.
For this chapter, we will begin with the 2D game design and game development framework created exclusively by Apple for iOS game developers known as SpriteKit. SpriteKit first became available with iOS 7 to help simplify the game development process for the family of iOS devices. The framework runs a typical rendering loop to draw and update 2D objects/sprites to your game's scene. There's much going on behind the scenes to run this loop and draw your game sprites. Thankfully, Apple built the first party game development frameworks to do much of the heavy lifting for us. This way, we can focus more on making the game itself without worrying too much about how that game will connect and run with the hardware, something developers in the past had to contend with.
Every update of iOS and Xcode continues to add more tools and frameworks to improve the ease of game design, including the companion framework introduced first at WWDC15 for iOS 9 known as GameplayKit. GameplayKit can allow us to separate, copy, and modularize the game logic and even copy for use in future game projects, be it SpriteKit or the 3D framework of our next chapter, SceneKit. We will go over GameplayKit in later chapters as well. At the end of this chapter, we will look at a complete game example that is for a simple game in its gameplay but somewhat complex in its logic.
SpriteKit and the 3D game framework, SceneKit, were not the first methods used for developing games in iOS. We'll quickly see why it became a welcomed addition to the developer toolset. Initially, we, the game developers, had to practically talk directly with the GPU using the OpenGL API to put both 2D and 3D graphics/vertices on to the screen. On the upper level, there always was Foundation and CocoaTouch to interact with user gestures to manipulate UIKit objects, but dealing with game development essentials, such as SpriteSheets, mipmaps, normal maps, partial emitters, bounding boxes, and culling, involved some level of lower-level structuring. Apple made those calls to various graphics buffers and VBOs slightly easier when they created their GLKit framework in 2011. Thankfully, various third-party frameworks, such as Cocos2D, Box2D, Sparrow, GameMaker, Unity, Unreal Engine, and others made this process less engineering-intensive in an effort to keep the design aspect of game design the focus. GameMaker, Unity, and Unreal Engine are more sandboxing- / drag-and-drop-styled engines akin to the mentality behind storyboards and segues, while engines such as Cocos2D and Sparrow are more code-heavy / boilerplate OOP structures that shortcut the initial coding buildup. Engines such as Unity and Unreal Engine are great in that they offer a more hands-on sandboxing-type environment with various features that simplify the MVC model. Some drawbacks to such engines are that they are sometimes closed source, usually cost money to utilize to their fullest and aren't device-specific (Unity particularly falls into this category). Working with these visual engines could sometimes lead to optimizations being required in platform-specific IDEs such as Xcode, due to a sometimes one-size-fits-all methodology. Apple's SpriteKit and the 3D API, SceneKit which we'll see later, give us a first-party platform-specific middle ground that grants the developer both upper-level API editing, but even lower-level graphic API (OpenGL/Metal) customizations.
Note
The negatives to sandbox/drag-and-drop-styled engines have decreased over time. Engines used by AAA studios, such as Unreal Engine, Unity, Havok, and others have lessened their upper-level ambiguity between the API and targeted devices' lower-level code. A good example of this would be Unity's IL2CPP, which converts the upper-level API calls directly to fast device-specific C++ code. This includes code and graphics pipeline optimizations that make use of Apple's slim Metal API. This homogenization of upper level applications with traditional boilerplate code now allows developers from all skill levels to make amazing games. That is why from iOS 8, iOS 9, and onwards, the Apple game development frameworks adopted a more visual design methodology. Xcode 7 introduced game state machines, components, and the ability to edit/copy and reuse player actions and animations throughout your projects. This allows developers to work specifically in iOS/Xcode while utilizing the visual design benefits of the device-independent game engines.
For this chapter, we will learn how to make a tile puzzle game named SwiftSweeper using the SpriteKit framework and with a more traditional boilerplate code method. This means that we will make our first demo game in a code-heavy / model-centric fashion. Not only will this give us a look into the inner workings of SpriteKit's code but it will also let us utilize more from the Swift programming language from Chapter 1, The Swift Programming Language.
We will conclude this chapter by briefly mentioning Apple's latest SpriteKit demo game, DemoBots, which utilizes more of the visual tools/frameworks from Xcode 7 and later. Seeing the more code-intensive method first though will later let us appreciate the time saved with these newer tools.
Apple has gone out of their way to mimic the visual design methodology to game design seen in other engines since game design is as much about code/logic as it is about art and design.