My dad likes to forward me tech articles where the writer will interview someone at a small gaming company and ask them how much work is required to support the latest changes to the iOS or a new device. The answer is usually from one of the cooler heads at the company that has already made their peace with whatever workload has crowbarred its way into their weekend plans. Whereas, I’m always reminded who my developer friends are when a flurry of Tweets or Facebook postings over-exaggerate a few extra hours of work on a past app. Someone always dusts off the picture of a baby crying in front of a computer and adds a new caption about the latest release (I love that).
Unfortunately, I don’t have a crystal ball to ensure everything I teach you in this book stays perfectly valid forever, but I can offer some pointers and words of encouragement. Anyone starting a project now already knows they should make high resolution images for both the iPhone and iPad. Unless Apple has plans for some kind of triple resolution screen, we should be safe for a while there.
The next “gotcha” would be something similar to the recent release of the iPhone 5 where the screen is slightly bigger than the previous phones. Fortunately, this can be planned for in your code. The projects in this book will try to use the width and height of the device as much as possible. So instead of hardcoding in the location of say, a health meter, with a specific value like 460, we can make that position based on a variable called screen Height. If the health meter was always located at the height of the screen minus 20, then it shouldn’t matter if the app is running on the iPhone 4, 4S, 5 or even on an iPad.
The example projects in this book will primarily be setup for the iPad, but at any time you can switch your project settings to iPhone-only or Universal and test how a drastic screen change affects your game. Hopefully if we build things right, the core engine of our games will still run fine.
This is a nice lead in to some code you might need one day. You can check what kind of device family your app is running on using the exact same code that is already included in the IntroLayer class of the Cocos2d v2 template (you could paste this block into any other class):
The code in the first set of squiggly brackets would run if your device was an iPhone or iPod touch. Otherwise the code in the next set of brackets would run, meaning the device was an iPad. This would be helpful if you were building a Universal app and needed to set some position variables that were not based on the device’s screen width or height. So inside the ‘if’ or ‘else’ statement above you could set a CGPoint value (the x and y location) for an object to be created. We’ll talk more about CGPoint variables later, so ignore that term if you aren’t familiar with it yet.
If you want to check a specific device model, like if your app is running on an iPhone 3GS, I’m going to let you walk down that dark alley alone. There is plenty of example code in forums to do exactly that, but as many wise people have pointed out in response to those posts, this can lead to problems where developers forget that a new model is always around the corner, and they only perform code for devices in existence. Writing from experience, it’s rare you’ll need to check a specific model, especially for game creation. Plus if you really must know more about the device your app is running on, you can check the screen size or whether or not it supports a Retina display.
Suppose you included this code within the first ‘if’ statement in our previous example:
Now you could do some further positioning based on that code (which assumes the app is set to portrait mode by the way). Hold on though, what if the next generation iPhone isn’t 568 tall? Now your app is basically assuming anything that isn’t 568 is probably a lower model than the iPhone 5. That ‘else’ statement would catch everything ‘else’. So you can see how things can get a bit dodgy coding by device. Then again, that’s the world we live in as developers. You can’t always plan perfectly for the future.
The past is a different story. You’ve got a window into ages long gone with the iPhone Simulator. While it isn’t the smoothest way of testing your application (the actual device is almost always faster) you can test on iOS models you don’t actually own. When you publish to the iOS Simulator, from the Hardware menu, scroll to Device, and you’ll see other models to test on.
It is always smart to double check that past models run your app correctly because a simple missing image can lead to a crash. Remember, if you’re including standard and high definition images you might forget to import one of them for the device model you don’t regularly test on.
Finally, if your app ever needs to check if the device is enabled for Retina display, one easy way to do this is using code similar to what we already saw last section.
Assume we are testing an iPad-only project, and want to see if the device is an iPad 1, 2, mini, or iPad Retina display:
The CCLOG statements above would send a message to the Output window with either of those messages above. More on log statements later. Keep in mind, that code actually enables Retina display (if it wasn’t before), but it also could be used to tell us if enabling worked or not, letting us make assumptions about the model.
Now why check for this? Remember Cocos2d does all the work for you in terms of swapping in HD graphics, so that’s not something we need to handle with our own code (we just have to name the files correctly). Here’s one simple reason. We know the more recent iOS models are generally faster. So you could include a Cocos2d particle effect in the background of the game on a faster model device, but exclude it on the older models (keep in mind, the iPad 2 and iPad mini don’t have a Retina display but are obviously much faster than an iPad 1).
Excerpt from iOS Game Programming with Xcode and Cocos2d by Justin Dike © 2013 Taylor & Francis Group. All Rights Reserved.