Let's now finally get to working with these tools and learn the basics of structuring game apps on a broader storyboard level. As of the writing of this book, the latest version of Xcode available is version 7.0. This will be the version we shall work with, but Xcode is always updating with even a beta version available to separately test the newest features.
Visit https://developer.apple.com/xcode/ to download and read up on all that Xcode has to offer for iOS developers.
To start structuring your app using storyboards, follow these instructions:
Applications
folder (or in your Dock if you placed it there for easy access).StoryBoardExample
.Now we have our default app created by the template. We should see on the left-hand side, in the File Navigator Pane, various files and folders created for us. As we can see, the AppDelegate.swift
and the ViewController.swift
files were automatically created for us and right below that, we'd find the Main.Storyboard
file. This is our storyboard and when you click on it, you should see the two panes open at the center of your Xcode window. The left side is the view controller Scene dropdown, which shows the hierarchy of the scene controlled by the provided the view controller. The right pane in the center allows us to visually see the view controller and eventually elements that we can place in it. The main visual part of the storyboard can be zoomed in and zoomed out. As we add more scenes to it, this will allow us to see the entirety of our storyboard or the portions we are working on.
You might have to zoom out slightly to see it (using your mouse or using the pinching gesture on your trackpad with a MacBook), but to the left of the View Controller scene there's a gray arrow. This is the entry point and the first View Controller scene attached to this arrow is your RootViewController
/Initial scene.
Let's start by creating a separate scene for our storyboard:
Now we have two scenes in our storyboard, but nothing is there to tell us what they are. They are just two blank scenes!
Let's put a Label object in these scenes to represent what they are and at runtime tell us which one we are in.
To keep this in the mindset of developing a game, let's put a label in the first one called Intro Scene, where we'd maybe have an intro animation to our game with a Start/Options menu, and in the next one, put the label Game Scene
to represent that this is where that actual gameplay would occur.
Here's how to do that:
label
. This will isolate the label
object, so you don't have to scroll through the entire list.label
object to the canvas of the first scene. If it doesn't look like it's trying to snap to the scene's canvas, you might have to select the View portion of that view controller scene's hierarchy, using the left pane of the Main/Storyboard's main view. Alternately, you can also double-click the view in the Inspector to get the scene in focus so that you can place the label onto it.The Utilities pane should have some fields visible when selecting the label to control various aspects of its text like font size, alignment, and style.
Label
as the default, so let's rename it to Intro Scene
for the first scene by either double-clicking the label itself in the canvas, or changing the name in the second field down from Text in the Utilities panel.Note how the label is clipped from the size increase and hardly visible.
Reposition the label to return it to the center of the scene.
Though rather rudimentary and with still some more work to do with, this is all it takes to create separate scenes visually. If you have an idea of how you want to structure your game, this is where you can start with the use of storyboards. Of course, there is still more to do here before we make this storyboard have any function.
We can see that Xcode is giving us the following warning:
Scene is unreachable due to lack of entry points and does not have an identifier for runtime access via -instantiateViewControllerWithIdentifier
.
This is referring to the Game Scene object that is essentially orphaned due to no connection to the Intro Scene nor the app's entry point.
This is where segues come into play. Yet, before we work with segues and create a flow to these scenes and more, if we were to run this app, we'd note another issue. We could have sworn that we centered the text, but if simulating or running this in, say, an iPhone 6s, the text is completely off to the upper-right side. This is because the default canvas is a generalized all device template to begin with via Auto Layout.
Auto Layout has gotten easier with each new build of Xcode, but one could still argue it's still a bit of a hassle at times to fine tune, particularly when creating constraints (set spaces/margining between various storyboard objects). Let's take a quick look at how to work with constraints.
One quick way to alleviate the issue we have here is to just work with the Base Values panel found at the bottom center of the storyboard canvas by clicking on the w/Any h/Any text. Once clicked, a pop-up table of cells will appear. Rolling over with your mouse or trackpad to the various cells will bring up a number of different configurations as oppose to w/Any h/Any. What's great about this is that you can change/add and delete various objects simply based on the device type using these options.
Before storyboards and Auto Layout, this would involve huge amounts of testing and refactoring of code in a view controller or Nib classes to get the layout just the way you'd like visually. Apple would then create the next device with a different screen size to prior devices, it would become an even greater hassle or the developer would risk a broken game on the newest device.
To make the labels be in the center for all iPhones in portrait mode for example:
Pinning with constraints could actually streamline this process. For example, let's say that you want to place a Pause button at the upper right corner of your Game Scene and you know that no matter the orientation, it will always be at a certain distance (in percentages or pixels) away from the right and top of a device's screen. We can click on the pin button at the bottom of the canvas to create these constraints in the w/Any h/Any configuration and skip manually adjusting the icon on every one of the base configurations.
Xcode already gives us a scene, the LaunchScreen.xib
file, which, if you have already ran your code, was actually what was seen first before the first view controller in the storyboard.
To have just your Main.Storyboard
file be at startup you can select the main project file at the top left corner in the Navigation pane and in the Launch Screen dropdown of the Apps Icons and Launch Images section, select Main.Storyboard
. Then, you can delete the LaunchScreen.xib
file if no longer needed. It can be a good file to see working constraints, and if so be it, it can be your initial splash screen for your game. More on constraints can be found here in the official documentation: https://developer.apple.com/library/prerelease/ios/documentation/UserExperience/Conceptual/AutolayoutPG/WorkingwithConstraintsinInterfaceBuidler.html.
Games have scenes, and all scenes have transitions between them. Segues are simply transitions between scenes in a storyboard. Segues come in various types:
UINavigationController
instance.UISplitViewController
, a Container view controller is typically used in iPad apps to browse news/email apps, where the left side of the page is a UITableViewController
object and the other side of the same page are the details of that table/list. This calls the details for the DetailView
controller portion of the page when triggered by a gesture from the selected item on the UITableViewController
side.The typical storyboard structure when building say, an e-mail app, will more than likely need to make use of a navigation controller and UITableView
controllers to structure the data and flow of the app. Now, we can very well do the same thing for game apps. Game Over, Menu, Rankings, and Pause screens could make use of these view controllers. For our example, we'll keep it simple and unrestricted to let you, the developer, have a better starting point to branch from.
Let's take care of that warning and link up these scenes as well as begin to show the overall structure of a typical game using storyboards.
button
or scroll down the objects in the Utilities panel and then drag and drop the button onto the scene.ViewController
object on the scene, preferably above or below the Game Scene on the canvas.PAUSED
the same way the Game Scene
and Intro Scene
labels were made.Now to create the segues visually using the storyboard:
performSegueWithIdentifier("segueIDNameeWithIdentifi)
The warning should now be gone as all of the scenes are connected with segues, and after possibly some Auto Layout fixes, running the app now has a game-like scene structure that transition the way we'd normally see in other games. We can go from here and make other scenes, such as a Game Over scene, a Stage Win scene, or others. Even if this might not be the way you'd like your final game's transitions to end up (particularly since the default transition of the Show segue does a quick vertical), this can be a very quick way of prototyping your game right off the bat. Custom segues and segues triggered with code are how we can dive deeper into fine tuning when the default setting might not match with our vision of our games.
Here's more documentation on making custom segue classes if you really want to dive deeper into segues:
Similarly to how we Control-Dragged the button's linkage to the next view controller scene, we can do the same to our ViewController.swift
file.
Here's a summery on how to do that for the first view controller:
startGame
.ViewController
class; preferably at the bottom of the code but still within the class's closing brackets.startButton
.IBAction
function: @IBAction func startButton(sender: AnyObject) {}
.self.performSegueWithIdentifier("startGame", sender: nil)
3.145.52.188