cocos2d

Eradicate Week 12: New Menus and Messages

For this week's update on our Eradicate iPad game at Skejo Studios, I wanted show a bit of the direction we are head with the art assets.

First we have received an initial scan of a possible load screen. We might mess with it a bit, cropping or framing it, but it is done. The example below also shows the improved game setup screen where you can cycle through the commanders photos, instead of just their names. Colorized version of all assets will be delivered shortly.

Cocos2d Menus and arguments

I was toying with the idea of writing a post about why I went independent, but I figure that wasn't appropriate for the wider audience of iDevBlogADay.com. Check my blog for those posts. So I decided to post a more technical piece regarding cocos2d menus and how to pass arguments through the Cocos2d menu system. But I was facing two issues. One I hated rewriting similar code over and over again. Second to make menu items more reusable, I needed to be able to pass arguments to the selector of the menu, which wasn't readily apparent how to do this. Also, checking the cocos2d forums and other places I saw that many others have had this issue.

So my goal is to create a reusable button factory which allows for the passing of arguments to the selector (read check this tutorial to get the basics for Button and Text Menu Items in Cocos2d).

For starters, here is a very typical pattern for adding a text menu item:

-(void) addMenu {
    //Create the label for the menu
    CCLabelTTF *label = [CCLabelTTF labelWithString:@"Button Text fontName:@"Arial" fontSize:12];

    //Add label to a menu item.
    CCMenuItemLabel *menuItem = [CCMenuItemLabel itemWithLabel:label target:self 
                                                      selector:(menuItemPressed:)]; 
    //Add menu item to a menu.   
    CCMenu *menu = [CCMenu menuWithItems:menuItem, nil];
    menu.position = ccp(0,0);

    //Add menu to a layer.
    [self addChild:menu];
}

//Method to receive button pressed action
-(void) menuItemPressed: (id)sender {
    [self doSomething];
}

As you might have noticed, the argument for the menu select is automatically supplied as a CCMenuItem of some sort or another, but generically it is just an id object. The question is how do you forward some information to the menuItemPressed method, from the menu item you created, and to no have to go through the effort of creating this sequence of code over and over again.

Example, this is ugly.

//Method to receive button1 pressed action
-(void) menuItemPressed1: (id)sender {
    [self doSomething: 1];
}
//Method to receive button2 pressed action
-(void) menuItemPressed2: (id)sender {
    [self doSomething: 2];
}
//Method to receive button3 pressed action
-(void) menuItemPressed3: (id)sender {
    [self doSomething: 3];
}

I wanted something like this.

-(void) menuItemPressed: (id)sender {
    [self doSomething: sender.passedVariable];
}

Gladly, all the CCMenuItem classes and subclasses all have a userData property that you can use to assign data to like this:

menuItem.userData = someObj;

To use the userData, and to make sure there weren't warnings or error in XCode, I explicitly cast the object to what is should, and assign it to a temp variable.

Update the code a bit and it becomes:

-(void) addMenu {
    //Create the label for the menu
    CCLabelTTF *label = [CCLabelTTF labelWithString:@"Button Text fontName:@"Arial" fontSize:12];

    //Add label to a menu item.
    CCMenuItemLabel *menuItem = [CCMenuItemLabel itemWithLabel:label target:self 
                                                      selector:(menuItemPressed:)]; 
    //Add menu item to a menu.   
    CCMenu *menu = [CCMenu menuWithItems:menuItem, nil];
    menuItem.userData = someObj;  //Of type SomeObj.
    menu.position = ccp(0,0);

    //Add menu to a layer.
    [self addChild:menu];
}

//Method to receive button pressed action
-(void) menuItemPressed: (id)sender {
    (SomeObj*) tempObj = (SomeObj*) sender.userData; 
    [self doSomething: sender.userData];
}

So now, we have a passed variable being used in a receiver of a pressed menu item. Great. Now write this code over and over again. OR, create a button factory that does the heavy lifting for you. Since I wanted to pass the position, and have a general layer to use, this method returns a CCLayer, but you could just return a CCMenu instead.

Here is my final button factory code, and an example usage (subject to improvements in the future, I will try to keep this article up to date).

-(CCLayer*) actionTrayButtonFactory: (NSString*) text withPosition: (CGPoint) pos withUserData: (id) userData selector: (SEL) selector {
    
    CCLayer *layer = [CCLayer node];
    
    CCLabelTTF *label = [CCLabelTTF labelWithString:text fontName:@"Arial" fontSize:13];
    label.color = ccc3(255, 255, 255); //Set your own color.
    
    CCMenuItemLabel *menuItem = [CCMenuItemLabel itemWithLabel:label target:self 
                                                      selector:selector];
    menuItem.userData = [userData retain];
    
    CCMenu *menu = [CCMenu menuWithItems:menuItem, nil];
    menu.position = pos;

    [layer addChild:menu];
    
    return layer;
}

Usage:

        CCLayer *layer = [self actionTrayButtonFactory: @"Button Name" withPosition:ccp(100, 200) withUserData:[NSNumber numberWithInt:1] selector:@selector(menuItemPressed:)];
        [self addChild: layer];

I would use this inside a loop where I am incrementing the button name, position height and the userData passed in.

Next, I will be making a similar button factory that takes in images and will create CCMenuItemImages instead. The same format will work. Also, a further extension would be to add in another argument for button type incase you wanted to adjust the size/shape/color of the manufactured menu item.

Also, if you are making a localized app, the button factory method can update the 'labelWithString:text' portion to 'labelWithString:NSLocalizedString(text, nil)', which is what I am doing in my game.

I am not sure if I needed to use objects in the userData property, instead of just integers or floats, but that is what was need when I got it to start working. I also at times needed to place a 'retain' on the object to maintain the data. Not exactly sure why. Any help from my readers on why that is the case will help clean up this code long term.

This code will show up in the Skejo Studios Outbreak project. Check out the game development diaries. This post is a part of the iDevBlogADay series. Check out some other recent posts including Who is an Indie Dev and What's my motivation.

Eradicate Week 2: Panning, Pinch Zoom, Stock Images and Stubbed Layers

I wish I could say I spent the whole week working on this project, but past contact was extended, and I worked on my other non-game project, the Dog Park Finder. We are updating the logo branding and adding thousands more dog friendly locations with new filters and map icons. But this is a dev diary about our Outbreak project (view all posts here). Also visit Skejo Studios to see all we are doing.

For this update, instead of working on a ton of under the hood methods, I hours I did spend on I used on some UI elements. Or more precisely, stubbing out the UI.

Below is one of out UI sketches we made. Partially we were just brainstorming on what a player would need to, prioritizing frequent interaction and highlighting them above less frequent actions. Though we in no way consider the sketch as perfect, we wanted to get something on paper, and then get it in rough for into the game. This way we are getting closer to a fully playable demo, as well as interactive with device and testing user and action flow.

Book Review: Learning Cocos2D

When I was making the transition into iOS development from Internet engineering, I grabbed two 500 page iPhone app development books, read and worked the examples over a Christmas vacation, coded nights and weekends for three months and produced an app that Apple highlighted as New and Noteworthy, the Dog Park Finder. So, now when I decided to make the leap from iOS development to iOS game development 18 months later, I wanted to grab a great intro book and go from there.

First I had to determine the tools I would use, and landed upon Cocos2D (this isn't a game platform review, so I am not going into the pros/cons of Cocos2D or other platforms, that is a different post). Following that decision, I grabbed Learning Cocos2D by Rod Strougo and Ray Wenderlich. The other obvious choice was Learn iPhone and iPad Cocos2D Game Development. Honestly, I came across Learning Cocos2D first, which is why I bought it.

Learning Cocos2D is a great book to use as an on-ramp to the Cocos2D platform, as well a giving good best practice insight into general game development, and design pattern to follow. If are a long term game developer, well versed in texture map optimization, OpenGL programming or physics modeling, then you probably should just read the Cocos2D API documentation. But if not, Learning Cocos2D is a hands on book for getting up to speed quickly (if you are altogether new to Objective-C and iOS development, the a read through an basic iPhone programming book before working through this book).

The book uses working example of building a Space Viking game (free at the app store). Through the examples you will be shown how to make a splash screen, menu pages (including credits and options pages), how to move and animate sprites, spawn enemies, scroll the landscape, create gravity puzzles and joy ride in a mine cart across an alien landscape. Among other things. All the while, Rod and Ray skillful introduce support tools and mix in programming best practices for optimizing memory and speed up the game.

Like many of books of this nature, all the sample code viewed in the book, is also available for download. It is a great help see and interact with an entire XCode project when a concept is eluding you. Also, the authors have given full permission to use the code in any manner to help accelerate your projects.

The book's 17 chapters are broken into five sections. Instead of highlights and review each chapter's content, I will do so at the section level.

The four chapters in the 'Getting Started' section give a steps the reader from a installing Cocos2D into XCode, to simple 'Hello World' program, to making your first game scene with a hero, a villain, some animations and basic collision detection. These chapters define the basic Cocos2D vocabulary of scenes, layers and sprites, along with batching sprites for performance, definition animation sequences in plists instead of in the code, and spells out some of the workflow and time saving API calls for handling sprite movements and scene updates.

The next short section involves chapters 5 and 6 where some decent amount of computer science concepts of class hierarchy, interfaces and other concepts are written along side instructions about sprite and layer affects, generating text labels, and other font usage. The authors also help guide you to a quick debugging layer for better testing of your games.

'From Level to Game', is the third section of the book. Chapter 7 deals with Cocos2D's menu items, which can be used to create dynamic menus, directing to new scenes for viewing credits, as well as creating options for defining game settings. Chapter 8 is dedicated to all things audio. Including different tools for importing sound and asynchronous loading of sound/music for a better user experience. Lastly Chapter 9 deals with larger levels than one screen can hold. Both scrolling, and parallax scrolling are covered as well as the efficient way to create and reuse time maps.

The most cerebral of sections, is 'Physics Engines' sections. I spent a little less time working the examples of the Physics chapters 10 through 13, but Rod and Ray extensively introduce both the Box2D and Chipmunk Physics engines. Starting a bit easy with gravity, mass and simple collisions to setting up a fully actuated Viking to throw and rag-doll around, these chapters lay a solid foundations for you to explore physics in the Cocos2D world on your own.

Lastly, a ragtag section is used to wrap up the basic particle system in Cocos, while giving pointers for toll in creating your own particle effects. A chapter is also dedicated to Game Center integration, including login/sign up, creating leader boards, setting achievements, and how to save updates when an Internet connection is not available. Besides the conclusion, the last chapter deals with general performance tips, debugging and profiling guides and some quick tips to loading your sprites faster.

Too sum up, Learning Cocos2D is not just a book on how to use Cocos2D, but really a how-to guide to making your first iOS Cocos2D game with good technical architecture, with many best practices and how-to's thrown in. At over 500 pages, it isn't a quick read, but I would recommend it to anyone looking for good book for iOS Cocos2D development

Before signing off, I thought I should also introduce myself, as this is my first post for iDevBlogADay.com. My name is Greg Holsclaw, and I am the founder of Skejo Studios, a new iOS shop. We have already produced two apps for ourselves (one is the Dog Park Finderwith over 200K downloads), and two more for clients. Since completing a BS in computational mathematics, I have been creating websites and backend engineering for 7 years, and creating iOS apps for the last two years.

My hobbies sites and weekend work has blossomed enough that I recently was able to resign my engineering lead role at a successful internet startup to create Skejo Studios, and there is no looking back. Look for more posts at www.tech-wanderings.com concerning the intersection of Drupal (a web CMS) and iOS apps, as well as development diaries for the games we are developing. Until next time. -Greg

Eradicate Week 1: Starting the Project

Today, I am kicking off the development diary for the project that inspired Skejo Studios to get started. We may have a second project in parallel (to fill any down time this project might have), but most of our energy will spent on this project.

I plan on making weekly project updates, at least on any week that I spend work on a particular project. This first update reflects about two weeks of elapsed time, but less than a week's worth of dedicated time. To set expectations, some updates will be technical in nature, where others might focus more on the design, UI or business side of things.

Currently, the in-house name is Outbreak, but that is of course subject to change at any point right up to launch. We are aiming to create an iPad evolution of a table top strategy game concept. A co-operative type game where there are two to four players who are trying to beat back four regional outbreaks. Most likely we will play a zombie theme for these outbreaks, but for now we are just working on the game mechanics. This project is being built on the Cocos2d game platform.

Leverage Existing Tools

From my years in industry, I know that re-inventing the wheel, just so I can say it is my wheel is a huge form of waste.

Going iOS native, Skejo Studios coming

With Drupal being my main technology for the last 5 years, I have been working on numerous iPhone projects for 18 months. During the last 4 months, I have been contemplating a career move. T2Media has been a great company for me, as well as giving me some financial options I didn't have a few years ago.

So I decided to resign my position a lead architect (yeah, crazy given the current economic climate) and start up my own iOS studio. I have enough internal projects lined up to keep me busy for a while, with design and artistic freelancers helping me out as needed.

I imagine that I will be making many more entries now that a steady paycheck isn't in the mix. I will still be making Drupal post now and again, but I will also start writing posts concerning my iOS development, mostly around some game ideas I have been popping around in my head.

Check back for more posts coming soon. Mostly on Cocos2d for iOS, http://www.cocos2d-iphone.org, as that is the framework I will be using going forward.

Syndicate content