Box2D-ing my brain in

It's funny how something so simple as adding an extra class to a project can cause everything to go mental, but it happens. In my case I was adding a new class... a menu... to my Cocos2D project with Box2D testbed, everything did run ok, but all of a sudden I was getting hundreds of Box2D compilation errors that looked a bit like this:

Now, I already knew that Box2D requires be part of Objective C++ files, but after a bit of research I found out that the entire project needs to be c++, well, actually it doesn't, it just needs to be run as c++. The easiest way to accomplish this is to select all of your .m files an in the right panel, under identity and type, change the File Type to be Objective-C++ source.

Problem solved...

Fragmentation is for Androids - or is it?

I won't get on my soapbox quite yet (although I do have a fair bit of natural height anyway) but all this talk of Android fragmentation seems fairly churlish when the iOS has 4 different screen resolutions and numerous specs of device (ok, I know technology moves on and devices have to be left behind at some point, I'm just making an ill conceived point), ahem, but how do we deal with all these different devices?

I feel a bit bad actually, up above I mentioned 4 screen resolutions but technically its only two resolutions, but with different pixel densities. We have the iPhone (480*320) and it's big brother, the twice as big iPhone Retina display (960*640) running at a screen ratio of 3:2. Then we have the iPad (1024*768) and it's double trouble super res Retina version (2048*1536) running at an annoying 4:3 ratio.

We can account for standard - retina displays very easily, in fact, cocos2d does it for us by using "points", but accounting for iphone - ipad displays are a bit more difficult before of the difference in screen size and the annoying problem of the different screen ratio. This post here helps us think about our positioning a bit more, but the simple fact is tat you are going to have to think long and hard about how different your game is going to look between the two devices. Bordering? Repositioning? Showing or hiding more of your play field? I couldn't possible offer one single piece of advice because everyone's game is different. I think we're going with repositioning UI elements and showing more horizontal space on the iPad to the iPhone.

Ok, we haven't fully finished with repositioning, that was just food for thought, but now is not yet the time for more of that, I will be coming back to it later though.

One good thing about all these 4 resolutions over Androids method of any res fits all, is that we can really target each res making our games look great, we do this by creating assets for each resolution. Now, I have been researching this for hours and have had to trawl through pages of forum posts, blogs and bad documentation, most of it out of date, so before you start taking what I'm saying as gospel, look at the date of this post and decide if the time difference means things could have changed, if so time for more research... rule of thumb, if you own a flying car and your dinner consists of a meal in a pill, then stop reading.

It is also important to say that this advice is only useful if we are on the same page, the page being "Cocos version 1.1 beta 2b" anything before this and we are talking different languages. I say that because all the early forum posts I found were discussing hacks and dark art methods of loading in images based on the hardware you are running. From version 1.1 beta-2b everything has got a lot more clear.

Essentially to target a particular screen you simply have to append your image filename with certain suffixes, the file loading doesn't change, just the names of your files.. so here we have a line of code to load a background image:

CCSprite *bg = [CCSprite spriteWithFile:@"MainMenu/mainmenubg.png"];

and here we have a list of files in the foler, MainMenu:

mainmenubg.png
mainmenubg-hd.png
mainmenubg-ipad.png
mainmenubg-ipadhd.png

See the pattern? Each suffix is good for loading a particular file. Now what you put in those files is up to you, nothing will be scaled or repositioned, just shown as is. In this case each image is the same size of it's counterpart resolution meaning I get crystal clear display, which looks very special, trust me.

So, what can you take away from all of this? How about... upgrade to 1.1 beta2b NOW, think about ratio differences, think about scaling your positions between iPhone and iPad, make sure your assets are big enough for that MAHOUSIVE iPad Retina display (hope you used PNG's) and get used to having your iPhone version being a lot bigger in size to the Android version.

Upgrading Cocos2D

Ok, this may seem like a bit of an insane post, but as I'm blogging about iOS development I thought I may as well document all my findings, no matter how inane or insane.

Ok, so after getting my brand new 3rd gen iPad (not showing off, honest) I looked into getting some lovely hi-res images on the screen (this will be covered in the next post). I found this to be possible through the new version of Cocos2D, which I wasn't rocking.

I downloaded it and installed it as detailed in the readme file which came with the download, but unlike LibGDX which just gives you the new libs to drop over the existing ones, Cocos2D had installed the files I needed to somewhere on my hard drive (and that could be ANYWHERE on a Mac!).

To make the process of upgrading easier, all I did was create a new Cocos2D project in xcode and then grab the libs folder from my new project and drop it over my existing libs folder. Jobs a good 'un. I could have found the original files for the libs by searching, but sometimes the stupid way is the best way.

For your information, I was upgrading to "1.1 beta 2-b".

A step in time

I decided to start my great iOS adventure by getting the menu system underway, the previous post points to an excellent article where menu's are discussed at a reasonable length, so I wont go over it again.

So I have a menu or two, yay. No I wanted to write a blog post about dealing with the 4 (actually, it's only really 2) resolutions you should be supporting on iOS systems, but after researching with how to deal with iPad screens for about an hour, I still haven't got anywhere near a proper conclusion. The only conclusion I have drawn is how much of a complete mess the iOS system and cocos2d is with regard to screen resolutions (please feel free to prove me wrong by proving a complete article on the perfect solution).

So to appease my sense of wanting to get something done, I decided to work on my main menu a bit more. In Critter Rollers, the logo on the main menu bounces up and down joyfully while waiting for player input (I hate, hate, hate, static main menu screens). To do this effectively I needed to implement a fixed time step.

If you are not familiar with a fixed time step then Google it, but the short version is that a fixed time step is a loop which will account for any discrepancies in your frame rate. I wanted to use a similar timestep to the one I employed on Android so I did a bit of searching and found a piece of information saying how to create a scheduled event, which will run as soon as the processor is available.

You call this in the init function and this will instruct the scheduler to call a particular function either after a fixed period of time, or asap. We want asap as the fixed time difference would cause slowdown (sorry for the misleading labelling)

[self schedule: @selector(update:) ];

Now this code would fire the "update" block

float fixedTimeStep = 0.03;//0.05;
float timeLeftOver = 0.0;
float timeAccumulator = 0;

-(void)update:(ccTime)dt {

float timeToRun = dt + timeAccumulator;
while(timeToRun >= fixedTimeStep)
{
//update physics perhaps

//do other stuff

timeToRun = timeToRun - fixedTimeStep;
}
timeAccumulator = timeToRun;
}

So what we have here are a few counters to keep track of time, the method the scheduler is calling and then all the gubbins to keep our operations on track. Now this code isn't perfect as far as fixed time steps goes, but as we are expecting to run our game on a fairly powerful device (and since Critter Rollers isn't too processor intensive) then we can happily get away with this.

In the //do other stuff, block, I am updating the position of my logo, for an idea of how to do that, check out Part 3 of Oscars tutorial below.

http://www.oscarvgg.com/your-first-game-in-cocos2d-part-3-the-gameplay/

Everything seems to work fairly well here, I'm still not sure if this solution is acceptable for my physics updates, but I will let you know if it isn't.

Anyway, that's me for tonight, I'm off to chill out and enjoy my bouncing logo a bit more. Andrew.

Getting started

Just so people don't get the wrong idea I thought I would clarify that this blog isn't a tutorial on how to start with iPhone development, there are plenty of good ones out there already. As I was a Cocos2D virgin I started with this excellent tutorial which is how I got started with iOS development.

http://www.oscarvgg.com/your-first-game-in-cocos2d-part-1-menus-and-transitions/

This will give you a start on menu's and how they are swapped out, moving onto basic gameplay concepts. I am hoping to expand on the gameplay concepts in my own way so keep an eye out for them, but the menu stuff is great, so pay attention.

Beginnings

Hi, my name is Andrew and I am the lead developer of the Rampant Mango Collective. We released our first Android game, Critter Rollers last year and it's been doing pretty well so we figured it was time to bring it to other platforms, the obvious choice being iOS.

I have had experience of iOS development in the past having created a couple of apps, but have never created a game in iOS. This blog will attempt to address some of my findings when porting across a Android game (built in LibGdx) into iOS (built in Cocos2D). I never pretend to use cutting edge or even best practice techniques, so please excuse me if I am using techniques which seem a bit insane.

I will be updating this blog whenever I overcome an obstacle in iOS you can look forward to seeing posts on Menu Systems, Fixed Time Steps, Cameras, XML Parsing, DB Management, local storage, differences between iPhones and iPads, Memory Managment plus other fun and strange things about developing for iOS.

Please feel free to add to the discussion in the comments, but keep it polite people, lets try to make the internet a nice place to play.