Swift roundup: Game programming!

by Joey deVilla on October 2, 2014

swift kick

Today’s Swift Kick features a roundup of tutorials and resources for the Swift developer who’s into game programming. If you’ve been meaning to learn Swift, games are a fun way to do so, and if you’ve been meaning to learn game programming, you’ll find these useful!

Brian Advent’s tutorial on building a networked tic-tac-toe game with Swift and the Multipeer Connectivity Framework

Brian Advent (whom I’ve written about before) has posted a video tutorial showing how to build a networked tic-tac-toe game using iOS’ Multipeer Connectivity Framework, which allows you to connect and share data with devices nearby.

RayWenderlich.com’s Sprite Kit Tutorial for Beginners updated for Swift

ray wenderlich ninja game

Two years ago, Ray Wenderlich posted the sort of game programming tutorial that he wanted to see: in his own words, “very simple but functional game with animation, collisions, and audio without using too many advanced features.” The resulting game is the one pictured above, featuring a shuriken-hurling ninja taking on approaching monsters.

The game was originally written in Objective-C and used the open source cross-platform 2D gaming framework Cocos2D 1.X, and was followed by an update for Cocos2D 2.X. When Sprite Kit came out, Ray wrote a new version of the game using that framework, and I took some ideas from that game and turned it into a simple shoot ‘em up game in Swift.

Ray’s updated his Sprite Kit Tutorial for Beginners for Swift, and it’s a great way to brush up on Swift and game programming at the same time. Check it out!

Conway’s Game of Life in functional Swift

life

While it can be argued that Swift is not a functional programming language, it certainly lends itself better to functional programming techniques than many other languages, Objective-C included. With this in mind, take The Game of Life with Functional Swift, written by Colin Eberhardt, one of the co-authors of the RayWenderlich.com books iOS8 by Tutorials, Swift By Tutorials, and Core Data by Tutorials. He writes:

This blog post shows an implementation of Conway’s Game of Life using functional techniques in Swift. This results in code which is a clear and concise representation of the game’s logic. I also take a closer look at ranges, intervals, the pattern match operator, ~= and how local functions help organise your code.

Taking a functional programming approach allowed Colin to condense the rules of Conway’s Game of Life down to this:

If you’re looking for a challenge, you might want to take MakeGamesWith.Us’ implementation of the Game of Life (pictured below) and refactor it using Colin’s functional approach.

life in swift

SwiftCast: Game Programming in Swift

The latest Swiftcast, which you can listen to using the player above, is all about game programming in Swift:

Swift game development is very exciting. If it isn’t already obvious with the content of our site, we love to talk about game development. Mobile gaming is a rapidly growing market, and iOS is by far the most rewarding and exciting to build games for. If you’ve ever wanted to learn how to build an iOS game as an indie developer, we have some resources and advice for you.

iOS Games by Tutorials updated for Swift

RayWenderlich.com’s book, iOS Games by Tutorials, has been updated for iOS 8 and Swift. In 28 chapters and over 800 pages, you’ll learn game programing with Swift and Sprite Kit by building the following games:

zombie conga

Zombie Conga, where the player is a partying zombie who’s trying to build a conga line of cats while avoiding crazy cat ladies. It covers introductory topics such as sprites, processing touches, collision detection and scrolling.

XBlaster

XBlaster: a space shooter where you’ll work with physics and particle systems.

cat nap

Cat Nap, where you’re trying to help a sleepy kitty get to bed. This is a “physics-based” game, so this introduces the Sprite Kit’s physics engine starting with the basics, but getting into stuff advanced enough for you to write your own version of Angry Birds or Cut the Rope.

pest control

Pest Control, a tile-mapped game where you take a Schwarzeneggarian hero on a bug-killing spree. This covers building a tile-mapping engine and adding all sorts of effects to a game.

circuit racer

Circuit Racer, a racing game made more complicated by obstacles on the track. This one features mixing Sprite Kit-based UIs with UIKit-based UIs, using the accelerometer, and interfacing with Game Center.

Also covered:

  • Porting your iOS games to OS X
  • Using texture atlases for reduced memory overhead and better performance
  • Tips and tricks for getting the most performance out of your game code
  • Basic game art-making for programmers

iOS Games by Tutorials is available in PDF form for $54, and it’s a great deal at the price. Buying it also gets you free updates for the life of the book; if you bought the earlier Objective-C/iOS 7 edition, you already own the current Swift/iOS 8 edition!

…and don’t forget…

The Flappening, in which I fix the implementation of Flappy Bird that changes to iOS’ Swift APIs broke, and…

my simple “shoot ‘em up” game in Swift, which has also been updated to work with post-beta Swift.

{ 0 comments }

swift kickA couple of quick updates about the simple “shoot ‘em up” game tutorial app written in Swift with Sprite Kit that I posted a little while back:

{ 0 comments }

Xcode 6.1 beta 3 and iOS 8.1 beta are out!

by Joey deVilla on September 29, 2014

do you feel lucky geek

For those of you who like living on the edge, beta 3 of Xcode 6.1 (the current stable version is 6.0) is now available to registered iOS developers. Of note in this release:

  • More APIs have been made optional-conformant. The good news is that code will make more sense. The bad news is that some existing code may break.
  • Value of type Any can now contain function-type values, as you might come to expect from a value named Any.
  • Documentation for the standard library, which shows up in quick help and in the synthesized header for the Swift module, is improved.
  • All the *LiteralConvertible protocols now use initializers for their requirements rather than static methods starting with convertFrom. Any type that previously conformed to one of these protocols will need to replace its convertFromXXX static methods with the corresponding initializer.
  • Xcode now produces fixit hints to move code from the old-style fromRaw()/toRaw() enum APIs to the new style-initializer and rawValue property.
  • Class properties don’t need to be marked final to avoid O(n) mutations on value semantic types.
  • iOS Playgrounds now support displaying animated views with the XCPShowView() XCPlayground API. This is disabled by default, but can be enabled by checking the Run in Full Simulator checkbox in the Playground Settings inspector. When this checkbox is checked, running the playground will cause the iOS Simulator application to launch and run the playground in the full simulator. This is also required for some other functionality that fails without the full iOS Simulator, such as NSURLConnection http requests. Running in the full iOS Simulator is slower than running in the default mode.
  • Apple has addressed an issue that could cause Xcode to become unresponsive while editing Swift code.
  • Dead code stripping no longer removes public declarations from Swift application targets which are needed by unit testing.
  • Weakly-linked symbols no longer cause compilation errors in Playgrounds .
  • Swift expressions like expr, p, and print that are evaluated from the LLDB prompt in the Debugger console will now work on 32-bit iOS devices.
  • Profiling App Extensions with Instruments now works.
  • Ampersand and double quotation mark characters are now fully supported in the company name for iOS projects you create.

Also available for download is iOS 8.1 beta. As with Xcode 6.1 beta, you have to be a registered Apple developer to get it now.

Remember, these are betas, and the standard caveats apply.

I’ll close with the Dirty Harry clip referenced in the photo at the top of this article, for the benefit of younger readers who may not be familiar with Mr. Clint Eastwood’s iconic character:

{ 0 comments }

RootMetrics gives Verizon top marks for its wireless network

rootmetrics on us carriers

Investment site The Motley Fool points to RootMetrics’ report for mobile carrier performance for the first half of 2014, which shows Verizon as the best overall performer of the “Big Four”. RootMetrics’ methodology incorporates thousands of mobile network performance tests performed on voice, text, and data from the consumer’s point of view. In the most recent round of these tests, Verizon performed best in reliability, speed, voice call performance, and data performance. AT&T beat them out in text message performance.

rootmetrics tests 1

rootmetrics tests 2

rootmetrics test 3

Click on any of these test graphs to see the RootMetrics report.

The Motley Fool credits Verizon’s XLTE — their branding for their Advanced Wireless Service (AWS) spectrum — which allows them to offer more than double the bandwidth provided by 4G LTE to customers, and this often yields faster connection speeds. Verizon has made XLTE available to 80% of its wireless market and 35% of devices currently on their network, and nearly all the devices it sells are XLTE-compatible.

total us carrier subscribers

Graph from Jan Dawson’s US wireless market trends for 2014 slide deck.
Click to see the source.

Verizon added 1.4 million net new wireless subscriptions in Q2 2014, and most of them — nearly 1.2 million — were tablet subscribers, not phone subscribers. Tablet mobile plan subscriptions are typically secondary subscriptions (with the primary one being for a mobile phone), and this, coupled with the fact that they’re one of the top 2 carriers in the US, suggests that their focus is on retaining customers and keeping their churn rate down. They seem to be succeeding in this goal, considering that they’ve kept their churn to under 1% for postpaid subscribers in Q2 2014.

Worth reading: Jan Dawson’s US wireless market trends for 2014 slide deck

The last graph in the segment above comes from US wireless market trends for 2014, a slide deck created by Jackdaw Research’s chief analyst, Jan Dawson. The deck looks at the wireless market’s financials (revenues, profitability, capital intensity), subscribers (total subscriptions, net adds, churn), and device trends (subsidies and penetration). If you want a good overview of the market, this is a good place to start.

AT&T offers double the data for family plans

att double data chart
att jpgFrom now until October 31, a family currently on AT&T’s Mobile Share Value plan can apply to get double the data on their plan for the same price. The deal doesn’t expire once you’ve signed up for it, but you do have to sign up for it, as it’s not automatically offered, and you have to do so before Hallowe’en.

Want an unlocked iPhone 6? T-Mobile’s got ‘em!

t-mobileIf you’ve got the money to buy it outright from the get-go, T-Mobile can help you; they’re the only US carrier who sells unlocked, contract-free iPhone 6. If you take this route, you’ll have to pay off any installment balance remaining on it and use the T-Mobile network for 40 days, which is the usual policy for T-Mobile. Once those 40 days have passed, you can switch to the network of your choice.

this article also appears in the GSG blog

{ 0 comments }

For a while, FlappySwift — an implementation of Flappy Bird put together by the folks at FullStack.io as part of a Swift development course — was the go-to GitHub repo for understanding both Swift and Sprite Kit. Then, Xcode 6 beta 7 happened and…

xcode beta 7 broke everything

At the beginning of the beta period, many of Apple’s APIs returned values as implicitly unwrapped optionals, which I suspect was a quick and dirty way to get a large number of APIs Swift-compatible. As the beta period went on, they started changing the APIs for optional conformance, which means that:

  • If an API call was going to return a value that might be nil, it would do so as an optional, and
  • if an API call would never return a nil value, it would do so as a non-optional.

A lot of the APIs were updated for optional conformance in Xcode 6 beta 7, including Sprite Kit, which means that suddenly a lot of Swift game code broke. Any code that expected to be using PhysicsBody! objects was suddenly dealing with PhysicsBody? objects and therefore wouldn’t run thanks to a crop of PhysicsBody? does not have a member named [SomeMember] errors.

I explained how to fix this problem in an article titled Why your Swift apps broke in Xcode 6 beta 7 and the GM versions, and how to fix them, but I thought I’d do one better.

I decided to fork the FlappySwift repo, make the necessary fixes, and post the resulting working new version on GitHub.

Now there’s a Swift version of Flappy Swift that will compile under the Xcode 6 GM and the optional-conformant APIs. Enjoy!

{ 0 comments }

BlackBerry Passport’s big screen

blackberry passport american cheese

The Canadian BlackBerry Passport meets American cheese…and dirty fingernails.

Nothing conveys the size of the BlackBerry Passport’s screen as well as this photo from Charlie Wells’ recent tweet:

Bendgate

bendgate

The current kerfuffle in mobile technology goes by the name “Bendgate” (or my favorite, “Bendghazi”), in which a number of users have reported that their brand-new iPhone 6 Plus devices would have a tendency to warp and bend while in their pockets.

I’ll leave it to tech videographer extraordinaire Marcus Brownlee to explain it in detail:

In response, the Apple PR machine has given tours of their iPhone torture-testing facilities:

In a story on The Verge, Josh Lowensohn reports that 30,000 iPhone 6 units — 15,000 of the 4.7″ iPhone 6 and 15,000 of the 5.5″ iPhone 6 Plus — underwent testing at Apple’s labs, where he saw phone undergoing all manner of stresses that they might undergo in regular (and some not-so-regular) everyday use. Apple report that they’ve received a mere 9 complaints.

Whether or not your bent iPhone 6 is your fault, chances are that if you take your bent iPhone 6 to the Genius Bar at your local Apple Store, they just might replace it, given their mandate and training to provide maximum customer satisfaction.

No Galaxy Note Edge for you!

samsung galaxy note edge
Remember Samsung’s Galaxy Note Edge, which we wrote about in our article covering the IFA trade show? It turns out that despite all the promotion, it’s a concept device.

galaxy edge edge

The phablet, which boasted a screen that curved around its right edge, with the curve acting as a second screen that could be viewed from its side, is a limited edition device whose primary purpose is simply to, as PC World puts it, “scream ‘First!'”. According to them, there will be limited sales in South Korea next month, and only way you’ll have a chance of getting one in the U.S. is either by being very lucky or knowing someone high up in Samsung US.

FBI director “very concerned” about new Apple and Google smartphone privacy features

fbi director james comey

In response to announcements from Apple and Google about enabling encryption on their mobile operating systems that would keep out both thieves and law enforcement, FBI director James Comey expressed his concern:

“I like and believe very much that we should have to obtain a warrant from an independent judge to be able to take the content of anyone’s closet or their smart phone. The notion that someone would market a closet that could never be opened — even if it involves a case involving a child kidnapper and a court order — to me does not make any sense.”

The Verge provides some valuable perspective in their article on the subject in these two paragraphs, which we’ll close with:

If this fight sounds familiar, it’s because much of the 90s was spent on exactly this legal question, a fight that’s now known as the Crypto Wars. PGP founder Phil Zimmermann almost went to jail over it. Of course, because it was the 90s, the fight was over desktop hard drives rather than phones, but when the dust settled, the courts ruled it was completely legal and large, reputable companies like Microsoft and Apple started offering full-disk encryption services without anyone making a fuss about it. Julian Sanchez has a great rundown of how it happened and why it was a good decision, but the general punchline is that it’s hard to build a backdoor that can only be used by the good guys.

It should also be pointed out that Comey’s refreshing enthusiasm for warrants is not shared across all federal agencies. Surveillance of this type frequently happens under a much lower legal standard, whether it’s a subpoena, a National Security Letter or plain old FISC-approved bulk collection. In fact, programs like that are the biggest reason Apple implemented this encryption in the first place, trying to placate concerns over unauthorized government data collection. Unfortunately for Comey, just invoking kidnapped children isn’t enough to undo 20 years of legal precedent.

{ 0 comments }

xcode beta 7 broke everything

If you had Swift projects that worked perfectly fine under Xcode 6 beta 6, you might find that they no longer work under beta 7 or the GM versions. This article will show you how to fix them, and why they broke.

For example, the FlappySwift game on GitHub — “Flappy Bird”, implemented in Swift — worked fine in Xcode 6 beta 6 and earlier, but is rife with errors in the present version of Xcode:

flappyswift code screencap

Click the screen capture to see it at full size.

Most of the errors are of the form “[SomeClass]? does not have a member named [SomeMember]“. The fix is simple — use optional chaining to fix the problem. For example, code like this:

should be changed to:

Note the addition of a ? — the optional chaining operator — to physicsBody when accessing one of its members. Make changes like this to FlappySwift’s code (it won’t take longer than a couple of minutes), and it’ll work again.

What happened?

It’s not as if Apple didn’t tell you what happened. It’s all spelled out in the Xcode 6 beta 7’s release notes:

A large number of Foundation, UIKit, CoreData, SceneKit, SpriteKit, Metal APIs have been audited for optional conformance, removing a significant number of implicitly unwrapped optionals from their interfaces. This clarifies the nullability of their properties, arguments and return values of their methods. This is an ongoing effort that started shipping in beta 5. These changes replace T! with either T? or T depending on whether the value can be null or not null, respectively.

It’s perfectly understandable if you read that and this was your reaction:

beavis and butt-head wtf

We’ll translate this into plain language, but first, let’s do a quick review of non-optional, optional, and implicitly unwrapped optional variables.

Non-optionals, optionals, and implicitly unwrapped optionals: a quick review

optional 1 In Swift, a variable whose type that doesn’t have any punctuation is guaranteed to contain a value of that type. For example, a variable of type String is guaranteed to contain a string value, even if that string is a zero-length string (“”). It will never be nil (nil means that the variable doesn’t contain a value), and you can start performing string operations on its value immediately.

Of course, there are times when you want a variable that might not contain a value at the moment, to indicate that you haven’t yet recorded a value or to denote that there’s no connection to another object. That’s what optionals are for: optional 2 Variables in Swift whose type ends with a question mark — ? — are called optionals, and they’ll either contain a value of that type or nil (which means that it contains no value). You’ll need to perform a check to see if contains a value or is empty first, and you’ll need to unwrap it before you can use its value.

For example, a variable of type String? will contain either a string value or nil. An often-cited example for showing optionals in action starts with a Dictionary with String keys and values, like the one below:

This dictionary lets you look up the name of an airport given its three-letter code like so:

You might think that the type of airports[airportCode] is String, but it’s not — it’s String?. That’s because the value of airports[airportCode] will be either:

  • a String value, if the value for airportCode corresponds to one of the dictionary’s keys: YYZ, YUL, TPA, SFO, or ORD, or
  • nil, if the value for airportCode isn’t one of the dictionary’s keys, such as LAX.

With optionals, you’ll write code that first checks to see whether or not they contain a value, and if they do, unwrap them with the ! operator. Here’s an example that continues with our dictionary:

This sort of check is going to happen quite often, so Swift’s designers added the “iflet” shorthand to save reduce the amount of code you have to write:

You can also unwrap an optional by assigning its value to an implicitly unwrapped optional: optional 3 Variables in Swift whose type ends with an exclamation mark — ! — are called implicitly unwrapped optionals, and they’re optionals you don’t have to unwrap in order to access the value they hold. When you want to work with the contents of an optional, you can either use the ! operator to unwrap it, or you can assign its value to an implicitly unwrapped optional, like so:

in which case tampaAirport is a String! variable. It’s still an optional, but you can use it as if it were a regular string variable. It’s still an optional, and it can be nil. There’s a coding convention that promises that by the time you need to access an implicitly unwrapped optional’s contents, it’ll hold a value.

This “it may have been nil at one point, but I promise it’ll contain a value by the time you use it” property of implicitly unwrapped optionals make them useful for instance variables whose values can’t be set when they’re declared. For example, suppose we need variables to store the width and height of the screen — values that we can’t know in advance:

That’s the review. Now let’s look at why your code broke.

Why your code broke after Xcode 6 beta 7 and later

This long answer on Stack Overflow explains implicitly unwrapped optionals exist. Long story short, they’re a practical compromise that allows Swift, which purposely doesn’t have null pointers, to work with iOS’ existing APIs, which were written with Objective-C, its pointers, and its conventions in mind.

There were a number of iOS APIs that were returning values as implicitly unwrapped optionals because they’re as close as you get to pointers in Swift: they can either hold a reference or nil, and you can access them directly without unwrapping them. Over time, Apple have been updating these APIs so that they followed the rules for optionals — if they might return nil, return the value as an optional, otherwise, return the value as a non-optional. Hence the term “optional conformance”. With the release of Xcode 6 beta 7, and after that, Xcode 6 GM, most of the APIs now conform to the rules for optionals. If an API call returns a value that could be nil, it’s no longer returned as an implicitly unwrapped optional, but as an optional. Here’s a snippet of code from my “Simple Shoot ‘Em Up” game that worked in Xcode 6 versions prior to beta 7. It assigns physics bodies to missile sprites:

It used to work when the SKPhysicsBody(circleOfRadius) initializer returned an object of type SKPhysicsBody!, which granted access to its properties. As of Xcode 6 beta 7 and later, SKPhysicsBody(circleOfRadius) returns an object of type SKPhysicsBody?. You need to unwrap it to get at its properties, which you can do through optional chaining, as shown below:

My suggested general guideline is that if you’re dealing with an API call or property that returns a pointer, you’re dealing with an optional that you’ll need to unwrap. You can always check the type of an entity in Xcode by putting your cursor over it and alt-clicking:

returning a pointer

{ 0 comments }