How to use Spritebuilder

how to download spritebuilder and how to install spritebuilder and spritebuilder drag and drop and spritebuilder default scaling spritebuilder game tutorial
Dr.KiranArora Profile Pic
Published Date:27-10-2017
Your Website URL(Optional)
In this chapter, you will learn the basics of working with SpriteBuilder, including its user interface and the first programming steps with Cocos2d-Swift using Objective-C and Xcode. You will learn how to create the most important elements in SpriteBuilder and how SpriteBuilder, Xcode, and Cocos2D are connected. At the end of this chapter, you will have a skeleton framework that you’ll continue to expand on. I assume you have downloaded and installed both SpriteBuilder and Xcode from the Mac App Store: SpriteBuilder:  Xcode: Creating a SpriteBuilder Project After launching SpriteBuilder, go straight to File➤ New➤ Cocos2D Project to start a new blank project. Save it anywhere where you’ll be able to locate it again—for instance, in the Documents or Desktop folder—and preferably use a name you’ll recognize again. The main example project in this book is named LearnSpriteBuilder.spritebuilder. If you haven’t used SpriteBuilder before, you should familiarize yourself with its user interface and the terminologies used throughout the book to describe specific areas and views in SpriteBuilder. The user interface is split into four main areas as shown in Figure 2-1. 1718 CHAPTER 2: Laying the Groundwork Figure 2-1. SpriteBuilder user interface 1. Resource Navigator (on the left). This is a tab bar view where you’ll find the following: from the leftmost tab to the rightmost tab: your project files in the File View (depicted) with a resource preview area and a list of files below the preview; a visual overview of resources in the Tileless Editor View; a list of available nodes in the Node Library View; and any warnings or errors (hopefully, none ever) in the Warnings View. 2. Stage View (at the top center). This is where the contents of a stage (which can be a scene, layer, node, particle emitter, or sprite) are displayed. You can select nodes in this view and use selection handles to move, resize, or rotate selected nodes. 3. Timeline View (bottom center). This is where nodes and joints in the stage are listed on the left side in hierarchical order, defining node draw order and parent-child relationships. The right side is the actual timeline, with its keyframe editor used to create animations (animations here being changes to a node’s properties over time). CHAPTER 2: Laying the Groundwork 19 4. Details Inspector (on the right), also known as Detail View. This is also a tab bar view with four panes. From left to right they are Item Properties, where you’ll find the selection’s editable settings and properties; Item Code Connections, where you can assign custom classes, variables, and selectors; Item Physics, where you can enable physics and edit physics body and shape properties; and finally, the Item Templates tab, which is used to create named templates from selected nodes and their properties but is currently used only by particle effects. The newly created project is actually a functional, runnable SpriteBuilder project. You can try this now by choosing File➤ Publish or by clicking the corresponding Publish button on the toolbar. The publishing process copies, converts, and caches the resources in the Xcode project associated with the SpriteBuilder project. The SpriteBuilder Project’s Xcode Project An Xcode project is located within every projectname.spritebuilder folder with a corresponding name projectname.xcodeproj. See Figure 2-2 for an example. The topmost folder with the yellow icon named LearnSpriteBuilder.spritebuilder is the project’s folder. Inside it is the project’s LearnSpriteBuilder.xcodeproj file, and the source code and published resource files for the app are found inside the Source folder. The SpriteBuilder Resources folder contains the resource and CCB files that SpriteBuilder lists in its File View. Figure 2-2. SpriteBuilder project structure as seen in Finder Note SpriteBuilder projects are folders with the extension .spritebuilder. SpriteBuilder will recognize projects only if the folder has the .spritebuilder suffix. If SpriteBuilder isn’t running you can manually copy, move, or rename a SpriteBuilder project folder using Finder, provided that you keep the .spritebuilder suffix. 20 CHAPTER 2: Laying the Groundwork Double-click the project’s .xcodeproj file, or open it via the File➤ Open command in Xcode. Xcode will greet you with a user interface similar to the one shown in Figure 2-3. Figure 2-3. Xcode user interface The Xcode user interface contains the following areas: 1. Toolbar, with scheme and device selection drop-down menu. Use the scheme drop-down menu to change which device or simulator the app should run on. 2. Navigator area, which contains multiple tabs. The default, leftmost tab (depicted) shows the files in the project. Other tabs allow you to search the project’s files, see build warnings and errors, manage breakpoints, and perform other tasks.CHAPTER 2: Laying the Groundwork 21 3. Editor area, where you type in source code. 4. Debug area, which displays debugging information. The left side displays values of variables at runtime, while the right side is the Console, where log statements are printed. 5. Utility area, which contains information about selected items. In this case, it shows detailed information about the selected MainScene.m file. You can build and run this minimal SpriteBuilder Xcode project by clicking the Play button, which is the leftmost icon on the toolbar. The project will build and launch either on a connected device or the iOS Simulator, depending on which run target is selected in the toolbar. You should see the exact same scene you saw in SpriteBuilder seconds before on your device or the iOS Simulator. Tip If you haven’t used Xcode before and need more instructions on how to use it, you should consult the Xcode Guide available via Help➤ Xcode Overview or online at library/ios/documentation/ToolsLanguages/Conceptual/Xcode_Overview. First Scene, First Code The first goal is to create a second scene and then connecting buttons so you can switch back and forth between the two scenes. This second scene is going to be the game scene, while the existing MainScene will become the menu screen. This is a commonplace, rudimentary separation between game and menu scenes. A scene contains all the content (nodes) that the game currently renders. Other scenes can replace the currently visible scene using transitions, just like Cocoa touch views can transition from one view to another with or without animations. Note A common misconception is that scenes and nodes can be used interchangeably with views. This is not so. Cocos2D has its own UIView class named CCGLView that renders all the scenes and nodes using OpenGL instructions. Therefore, other UIView instances can be either entirely on top of or behind the Cocos2D view and the scene it currently displays.22 CHAPTER 2: Laying the Groundwork Creating the GameScene Go to File➤ New➤ File, or right-click the Project Navigator pane below the preview area and choose New File from the context menu to create a new SpriteBuilder document file, also known as a CCB file. Select the Scene type, and enter GameScene.ccb as the file name (as shown in Figure 2-4) and click the Create button. Figure 2-4. Creating the GameScene.ccb To be precise, creating a new CCB file lets you choose one of five different types. Here’s a quick rundown of their purpose and major differences:  Scene: A presentable scene. Contrary to what you might expect, its root node is a CCNode, not a CCScene. It’s main difference from the Node type is that it defaults to display a nice device frame around it in SpriteBuilder.  Node: Essentially, the same as Scene, but it has no device frame, and it has a root node of class CCNode.  Layer: The only CCB file type whose content size can be set. This makes it ideal for any fixed-size layer. Again, the root node is of class CCNode.  Sprite: Because sprites are so commonplace in games, this CCB has a CCSprite as its root node. Other than that, though, it’s the same as the Node type.  Particles: Same as for Sprite type, except here the root node is using the CCParticleSystem class.CHAPTER 2: Laying the Groundwork 23 Note Technically, all CCB file types can be used interchangeably. The main difference between Scene, Node, and Layer is one of terminology and how it’s displayed in SpriteBuilder. The Layer type is the only one that allows for a user-definable content size. Layer need only be used over Node or Scene whenever the contents need a fixed, custom size—for instance, for game levels or fixed-size overlay menus. The GameScene.ccb will be presented as an iPhone device frame with no contents (black screen). Time to fill it with some content. Reviewing the Node Library On the Resource Navigator pane (left side), click on the Node Library View tab. This brings up a list of items that can be dragged and dropped onto the stage. Most of these items are nodes, inheriting from Cocos2d’s base class CCNode. The only other types of items are joints used by the physics engine. In Figure 2-5, you’ll find the full list of nodes available at the time of this writing. Figure 2-5. List of available nodes in SpriteBuilder 24 CHAPTER 2: Laying the Groundwork I’ll quickly go over the various node types and their purpose  Node: An invisible node that is used to group (or “layer”) other nodes. Imagine them being folders that contain related items. This affects draw order, and it can be useful to access related items easier in code, or just to sort, move, or collapse nodes in the SpriteBuilder timeline.  Sub File: A placeholder for embedding another CCB file. This is a very powerful node because it allows you to use other CCB files like templates and to create and edit a single CCB that is used (instantiated) multiple times. Dragging a CCB file onto a stage will automatically create a Sub File node.  Physics Node: This represents the physics world. Any node with physics enabled has to be a child or grandchild of a Physics Node, or it won’t have physics enabled after all. Generally, only one Physics Node should be used per scene. Multiple worlds are possible, but their children will not be able to interact with each other.  Color and Gradient Node: Look at these colors, wow Essentially, these are just sprites without images. They’re great for quick-and-dirty backgrounds or for use as placeholders for as-of-yet missing graphics. Sprite: The main constituent of any 2D game. Use this tool to draw a single sprite frame, a texture in its entirety, or a part of a larger texture. The Sprite 9 Slice can be used to create a resizable background for a menu screen or button, but it’s rarely needed thanks to the Button node.  Particle System: For explosions, exhaust smoke, fire swords, and the like. It animates a bunch of particles based on parameters that define how particles are created, what they do over time, and how long they live. Particles don’t interact with physics, and you can’t access individual particles in code. Particles can be drawn and animated more efficiently than the equivalent number of sprites.  Label TTF and BM-Font: For text and such. TTF stands for Truetype Font. The advantage these offer is that you can use any built-in iOS or custom TTF font. The disadvantage is that every change in text internally creates a new texture, which is inefficient for score counters. TTF fonts are best used for static text. For animated text, BM-Fonts are preferable, but they must be created with an external tool like Glyph Designer.  Button: A button is the ultimate combination of a Sprite 9 Slice (background image) and a Label TTF (text) to create the most awesome thing in the world. Almost. Well, you can tap or click it, and it can send a message in code which, if you set it up properly, won’t even crash but will actually run some code  Text Field: An editable label. A user can tap or click it and type some text, and your code receives a message either when text editing ends or even every time the text changes. CHAPTER 2: Laying the Groundwork 25  Slider: A user can move the slider handle left or right. Your code receives a message while the slider is dragged. Technically, it always operates with values in the range 0.0 to 1.0.  Scroll View: Despite its name, this is not meant to create scrolling game worlds. It’s intended to be dragged and moved by the user and to create a scrolling and snapping effect similar to the one used for browsing photos in the Photo library. You’ll later use a Scroll View to create a level selection screen.  Box Layout: Makes the tedious task of evenly spacing nodes a snap. You can align its child nodes horizontally or vertically, but alas, despite its name you cannot align them on a grid with multiple rows and columns by itself. However, you can use a horizontal Box Layout that contains multiple vertical Box Layout nodes as children, each of which contains the nodes in each column—or vice versa, with the horizontal and vertical alignment Box Layout nodes swapped. You have two ways of adding items from the Node Library onto the stage. Both involve dragging the desired item from the Node Library and dropping it either directly onto the Stage or dropping them on the left side of the Timeline View on another node. The latter approach gives you the option to determine where in the hierarchy the node should be added—in other words, what that node’s parent should be. If you drop the new node directly onto the stage, it will be added as a sibling of the currently selected node, or as a child of the root node for cases when the root node is selected or when no node is selected. Tip Selection can be performed by clicking on a node in the stage—or more accurately, by selecting the desired node in the hierarchical Timeline View. Multiple selections are possible by holding down the Shift or Cmd key while selecting. You can delete selected nodes by pressing the Backspace key. You can Edit➤ Undo most operations, including deletions, until you save the document. Creating a Button Now drag and drop a button onto the stage or timeline. Position it anywhere on the stage—that’s fine for now. The new button will be selected and labeled “Title”. On the Item Properties pane (to the right), you will see a large collection of values, buttons, check boxes, and text fields. The Button node is probably the most complex node of them all. An example of its properties is shown in Figure 2-6. Feel free to play with its settings and values at this point; there’s little you can do wrong. And if you do the wrong thing, you can Undo or simply delete the button and drag a new one onto the stage to start over. www.itbookshub.com26 CHAPTER 2: Laying the Groundwork Figure 2-6. Excerpt of CCButton properties For now, the only thing you probably should change is the button’s text, editable under the CCButton section in the Title text box. Enter “Change Scene” or something similar as the title. Assigning a Button Selector The really important part is the Code Connections tab in the Details Inspector on the right side. Click on this tab now. See Figure 2-7 for reference. Figure 2-7. The button’s Code Connections tab CHAPTER 2: Laying the Groundwork 27 You’ll see a section labeled CCControl that you’ll only see on user-interface nodes, namely Button, Text Field, and Slider nodes. This is where you can specify a selector, also known as “the name of a method” for those not afraid to put it in layman’s terms. That’s the message being sent (or simply “the method being called”) when the button is pressed. Enter exitButtonPressed in the Selector text field. As for Target, leave it on Document root. Be sure to leave the Continuous check box unchecked, or else the method would run every frame while the user keeps the button tapped or pressed. What happens now if you publish and run the code, and then press the button? Darn It’s still showing the original MainScene. Changing the Launch Scene To change the scene with which a SpriteBuilder project launches, open the AppDelegate.m file in Xcode. Locate the startScene method, and modify it so it loads the GameScene file: - (CCScene) startScene return CCBReader loadAsScene:"GameScene"; CCBReader is the class bundled with Cocos2d-Swift that is responsible for loading CCB files. The CCBReader methods you are likely to use are loadAsScene and load, which both load the specified CCB file and return a CCScene and CCNode instance, respectively. For now, it’s only noteworthy that loadAsScene: returns a plain CCScene instance with the GameScene.ccb root node as its only child. I’ll explain this in more detail soon. Publish again, and run the app. It’ll bring up the GameScene with the button, but tapping the button doesn’t do anything useful yet. Creating a Custom Class for the GameScene For code connections to work, both when specifying a selector and when assigning a node as an ivar (short for “instance variable of a class”), you will have to specify a custom class in SpriteBuilder. Then create the class of the same name containing the corresponding selector/ivar in Xcode. Or vice versa; the order is not important. Both for selectors and ivars, you can specify a target, which defaults to Document root and Doc root var, respectively. This so-called “document root” refers to the root node of the CCB file which contains the currently edited node. The root node is the topmost node in the hierarchy—the one that’s already there when you create a CCB file. (See Figure 2-8.) Therefore, the custom class property must be edited on the root node.28 CHAPTER 2: Laying the Groundwork Figure 2-8. The root node is selected Note Using the Owner setting as the target for selectors and ivars is done only in cases where you load the contents of a CCB at runtime with an already existing scene. You can specify a custom object (owner) as the receiver of selectors and ivars. One use for this is to map an overlay-menu CCB’s button selectors to the scene’s original custom class. A common misconception is that the Owner setting refers to the custom class of the selected node—that is not the case. Select the root node in the GameScene.ccb, and switch to the Code Connections tab on the Detail View. The root node is always the first node in the node hierarchy. You can most easily select it in the Timeline View, as seen in Figure 2-8. With the root node selected, enter GameScene in the Custom class field like in Figure 2-9. Be sure the case matches, too. If you enter “gamescene” in the custom class text field but name your class “GameScene,” the code connection is not going to work. You also have to use a valid Objective-C class name. If in doubt, just stick to letters and numbers and don’t start the class name with a number, and you’ll be fine. Figure 2-9. GameScene.ccb root node with custom class assigned Now switch over to Xcode. You should still have the project open. If not, go to File➤ Open Recent, and select the project from the list, or double-click the .xcodeproj in Finder as mentioned earlier. Select the “Source” group in the project, and perform File➤ New➤ File from the menu, or right-click and select New File from the context menu. Select the Cocoa Touch Class (Xcode 5: Objective-C Class) template from the list of items shown in Figure 2-10 before clicking Next.CHAPTER 2: Laying the Groundwork 29 Figure 2-10. Xcode file templates dialog Name your class exactly as you did in SpriteBuilder. In this instance, it must be named GameScene as shown in Figure 2-11. Make it a subclass of CCNode, not CCScene, because even in CCB files of type Scene, the root node is a CCNode instance. Click Next and save the file. Figure 2-11. Creating a new Objective-C class named GameScene30 CHAPTER 2: Laying the Groundwork Tip If you ever create a custom class for CCB files of type Sprite, you’ll have to make the class a subclass of CCSprite. Accordingly, for Particles CCBs, you’ll have to make them a subclass ofCCParticleSystem. For all other CCB file types, you have to make the custom class a subclass ofCCNode. Now select the GameScene.m file. As a quick test of whether the class is created and initialized, you can implement the didLoadFromCCB method sent by CCBReader to every node it creates. Your GameScene.m implementation should look like this: import "GameScene.h" implementation GameScene -(void) didLoadFromCCB NSLog("GameScene created"); end When you build and run the app now, you’ll find the following log message in the Xcode Debug Console, located at the bottom of the Xcode window in the debug area. See Figure 2-3, the Debug Console is the right half of the area labelled with 4. If you can’t see the Debug Console, go to View➤ Debug Area➤ Activate Console to show it. The message in the Debug Console should read as follows: 2014-06-05 20:00:01.014 LearnSpriteBuilder49183:60b GameScene did load Implementing the Button Selector Now you know that the custom class is loaded by the reader. All that’s left to do is implement the button selector. Create the button method, and name it exactly as you entered it on the Code Connections Selector field for the button. Your GameScene implementation should now have this additional method: -(void) exitButtonPressed NSLog("Get me outa here"); CHAPTER 2: Laying the Groundwork 31 Tip You can optionally set up the selectors for Button, Text Field, and Slider nodes so that they receive the sending node as a parameter. To do so, you would simply append a colon to the selector name—for instance, exitButtonPressed would becomeexitButtonPressed: in the Selector field on the Code Connections tab for the node. Then update the method signature accordingly, for brevity, in a single line: -(void) exitButtonPressed:(CCControl)sender NSLog("Sender: %", sender); Instead ofCCControl, you can use the sending node’s specific class—for instance,CCButton. CCControl is the super class which Button, Text Field, and Slider nodes inherit from and is guaranteed to work for all of them. Run the app, tap the button, and you’ll see a message like this in the Debug Console: 2014-06-05 20:24:02-959 LearnSpriteBuilder49437:60b Get me outa here Changing the Scene on Button Tap Would be even nicer if tapping the button actually did change to the menu scene, don’t you think? Connecting scenes is a task that you have to code, but it’s really straightforward and the same procedure for all scene transitions. See Listing 2-1. Listing 2-1. Changing the scene on button press -(void) exitButtonPressed NSLog("Get me outa here"); CCScene scene = CCBReader loadAsScene:"MainScene"; CCTransition transition = CCTransition transitionFadeWithDuration:1.5; CCDirector sharedDirector presentScene:scene withTransition:transition; Caution You should not append the .ccb file extension when loading CCBs. It’s a common and understandable mistake, but CCBReader will fail to load files where you specify the .ccb extension. Published CCB files are converted to a binary format optimized for fast loading and compact storage. This binary file format carries the extension .ccbi—that’s .ccb with a trailing i. The plain text format .ccb files aren’t actually in the bundle. Therefore, it’s important to omit the file extension in calls toCCBReader. Or, perhaps to remind you of the differing extensions, you can also append the .ccbi extension. 32 CHAPTER 2: Laying the Groundwork First, CCBReader is used to load a SpriteBuilder CCB file as the scene with the loadAsScene: method. The loadAsScene method is a convenience method. It returns a CCScene object with your CCB file’s root node as the only child. To better understand this, here’s the equivalent code to loadAsScene but implemented using the load: method: CCNode ccbRootNode = CCBReader load:"MainScene"; CCScene scene = CCScene node; scene addChild:ccbRootNode; Here scene is what the method returns. To access the MainScene’s root node, you would have to write CCNode rootNode = scene.children.firstObject; Now that you have an instance of a CCScene, it can be presented with an optional transition: CCTransition transition = CCTransition transitionFadeWithDuration:1.5; CCDirector sharedDirector presentScene:scene withTransition:transition; A transition is a way to animate the scene change. The fade transition fades one scene to black before fading the new scene in. You can also use cross-fade, fading to color and a variety of moving and pushing transitions. What are these transition methods’ exact names? This information is always at your fingertips with Xcode code completion suggestions—if you don’t get suggestions, check that the option is turned on under Xcode Preferences➤ Text Editing➤ Suggest completions while typing. Once you start typing parts of a class or method name, you should see a list of the available completion suggestions like in Figure 2-12. If not, try pressing the ESC key at this point. Figure 2-12. Taking advantage of Xcode auto-completion suggestions Tip You can also find a list of transitions in the Cocos2d class reference:http://www.cocos2d- Or typeCCTransition anywhere in Xcode, and then right-click the text and select Jump to Definition. (Alternatively, put the cursor anywhere on the text and select Navigate➤ Jump to Definition from the menu.) This will open the interface forCCTransition, where you’ll find, along with documentation, the names of methods and properties and other details of the class. CHAPTER 2: Laying the Groundwork 33 Now that you know how to the start scene in AppDelegate and how to change scenes when tapping a button, run the app and try it if you haven’t done so yet—I’ll leave it as an exercise to change the starting scene back to the MainScene and to add another button on the MainScene. So that, when the button in the MainScene is tapped, it transitions to the GameScene. An example of this project state is provided with the book in the 01 - Change Scenes with Buttons folder. Creating a Level Sub File Node Back to SpriteBuilder—specifically, the GameScene.ccb file. The game we’re building should support multiple levels. Because each level will have the same basic game play, it makes sense to reuse the GameScene.ccb for each level so that you don’t have to re-implement common features in each level separately. For instance, the HUD or heads-up display—a misnomer, but a commonly used term that refers to any nonscrolling content, like pause buttons and score labels in a scrolling world. This is where the Sub File node comes in handy. It allows you to create template CCB files that can be instantiated multiple times and edited in a single file. Consider the Sub File node being the equivalent of a class in Objective-C. The GameScene will have three Sub File nodes, one for the actual level contents, one for the HUD layer, and one for any popovers like the pause and “game over” menus. Since re-organizing resources at a later point is tedious and error prone, it’s important to start with a project structure that can grow with the project. For this exercise, start by adding a new folder named Levels to the project, where all the game’s level files will be added to. You can create a folder via the File➤ New➤ Folder menu or by right-clicking in the Resource Navigator view on the lower left half of the File View tab—that’s where the CCB files and other resources are listed. First, create a CCB that will contain the level’s nodes. Since a level needs a specific size, in this case to determine the scrollable area of the world, the Layer document type is the right choice. Select the Levels folder before you issue the File➤ New➤ File command, and before you right-click the Levels folder and select New File. This will display the dialog in Figure 2-13. Figure 2-13. Level1.ccb is of type Layer and uses a custom content size 34 CHAPTER 2: Laying the Groundwork Name the new layer Level1.ccb, and give it a size of 4000 by 500. Then click Create. Initially, the new CCB will be empty (black). The Level1.ccb file should be in the subfolder named Levels. If it isn’t, move it to the Levels folder by dragging the Level1.ccb onto the Levels folder. The project’s file hierarchy should be exactly like the one shown in Figure 2-14. Figure 2-14. Level1.ccb should be in the folder named Levels Switch to the Node Library View, and drag and drop a Gradient Node onto the stage or onto the root node in the timeline. The Node Selection Handles Now before you make this gradient fill the entire level, have a look at the selection handles for a node. You can easily spot the selected node in the stage because its corners are marked with tiny circles, the selection handles. As you move your mouse over a selected node in the stage, the mouse cursor will change to one of the following icons, and its corresponding action can be performed through clicking and dragging: Within the node’s rectangular area, the mouse cursor shows a 4-way cross of arrows (1). Click and drag when this is your mouse cursor to move the node. If the cross of arrows has a circle at its center (2), the mouse is hovering near the node’s anchorPoint and dragging will cause the anchorPoint to move instead. The anchorPoint itself is often mistaken as a way to reposition a node, but alas it’s mainly the center of rotation and scale operations for a node. Typically, the anchorPoint is either at the lower left corner (0, 0) or the center (0.5, 0.5) of a node. Caution Unless mentioned specifically in this book, you should leave the anchorPoint at its default value. Watch out for the slight difference in icons 1 and 2 before starting to drag a node. CHAPTER 2: Laying the Groundwork 35 The two-way arrow handle (3) allows you to scale the node and becomes visible when hovering over one of the four selection handles. It can be mistaken for resizing the node, but except for Color Node and Gradient Node, changing a node’s size by changing its scale will result in reduced image quality, in particular when enlarging the node through scaling. If you move the mouse cursor slightly outside the node but hover near a selection handle, its shape will change to a bent 2-way arrow (4), which allows you to rotate the node when dragging. Finally, the two split-in-half arrows (5) indicate the skew action. You can grab a node between two selection handles to move that edge along its axis, forming a trapezoid-shaped node. Editing Node Properties For precision changes, the mouse drag operations are unsuitable. You can use the Nudge, Move, and Align commands from the Object menu for finer control, but this doesn’t suit every situation either. Most of the time, when you know the exact value of a property you’ll want to use the Item Properties view on the right side of Detail View. All node types present the same basic properties at the top, labeled CCNode, as seen in Figure 2-15. Figure 2-15. CCNode properties are used by all nodes www.itbookshub.com36 CHAPTER 2: Laying the Groundwork The Visible check box is self-explanatory, and the Name text field can be used to give a node a custom name to identify it in code. The Position setting is in points, not pixels. A Retina and non-Retina iPad, for instance, have the same point dimensions of 1024 x 768 points. This makes the position universal for all devices. To further support alignment and perhaps personal preference, you can change a node’s reference corner. (See Figure 2-16.) By default, it is set to Bottom-left, which means the node’s position is relative to the lower left corner of the root node. Change it to Top-left and the node’s position will be the same as that of a UIView, which also considers views to be positioned relative to the upper-left corner of the view, layer, or screen. Figure 2-16. The Corner Alignment settings for the Position property The position’s scale type can also be adjusted individually for each axis. By default, coordinates are considered to be X in Points, but always scaling up on the iPad. This has the effect that when you change the document to Document➤ Resolution➤ Tablet, the relative position of the node remains the same on tablet devices. By default, SpriteBuilder assumes that Universal apps will want to treat the iPad screen essentially as a roughly two times larger screen—the 1024 x 768 iPad point extents are 1.8 times wider and 2-4 times higher than a widescreen iPhone 5C/5S dimensions of 568 x 320. If that is not what you wish, you’ll have to change node positions to X in UI Points (see Figure 2-17) to actually allow you to cram more nodes onto the larger screen real estate. In other words the player would actually be able to see more of the same world on an iPad. Figure 2-17. The Position Type settings The same UI point scaling type can also be applied to a node’s scale property. Finally, the percent of parent container settings is the most important and the most frequently used setting for positions. It allows you to completely ignore most resolution-dependent considerations. The most common use is to quickly center a node on the screen regardless of the target device being a 3.5” or 4” iPhone or an iPad. Simply set the position types for both coordinates to percent of parent container and enter 50% x 50%.