How often do you request on twitter while the game engine is running?

Your reality tweet feature is amazing reminds me of scribblnauts. How many type of tweets does your game support?

Can I ask if your events drawn in real time or do you have them all in spritesheets?

I dont think it matters whether you use Game Center or OpenFeint. I mean not many users care as long as you have one of them; however, I personally prefer Game Center just because I like the look of it better and it has some really useful features (such as playing online). I doubt you need any of the features but leader board though so if you like Open Feint better just go with open feint. I mean Stick Wars used Open Feint and a lot of the leading apps do use Open Feint. So, to answer your question, no, dont ditch open feint purely because you feel GC is preferred by evreyone, for there is no real proof of this. Some people can prefer GC while others may prefer open feint. Unless you have some statistics saying the 80% of the people prefer GC or something I really dont think you need to change it.

What an awesome game!

I take it you are using XCode4, which certainly isn't bugfree yet. Main problem - as I see it - is, if you do things "not as intended", which is relatively easy if you poke around. XCode4 will then often work in mysterious ways. Try ex to add localization, and then move, rename or replace localized files. It gets really messy, with all kinds of weird warnings and errors.

Thanks! Nope, we didn't use Gamecenter at all. Requests to twitter thingies were done via URL requests on a separate thread which is maintaining an internal database. This database is what makes the game be able to be played both online and offline!

One question to you fellow devs, should I integrate Game Center as opposed to OpenFeint? We integrated OpenFeint initially because I had experience with it and we figured it would take a bit less on a learning curve. Some users have commented about this and say that they base some of their purchases upon GC integration. Is this true? Should I just ditch openfeint and move on to GC?

Clearing the user settings did help, it removed all the 240+ errors about conversion types - but I am puzzled by how it got changed in the first place. :/
On the other hand, the error about an unknown class in the .xib remains the same.

I'll try moving the files into another project and reconstruct my .xib/.nib then get back here with the results.
Thanks @birkemose for the help :)

Or perhaps these are the works of... (You know it is terrible to mention ' name, or even to refer to ' with a pronoun) .

I'll try that - thanks. :)

That sounds scary :)
My guess would be that you somehow messed up the project.
Maybe it is hoaxed? I have heard stories about hoaxed project files when we roasted marsh mellows over the camp fire. With shifty eyes, people spoke in low voices about "deep cleaning".
Anyways. You can reset all user data in a project. Copy your xcodeproj file ( for safety ). Then open the package and remove the folder named xcuserdata. While I doubt it will work, it is an easy way to check if your settings by accident broke anything.
Other than that, I would make a new project, and then add the old project files.

Yeah, I double checked all of that.
-----------------------------
GOODNESS GRACIOUS HELP ME.
The weirdest things have just happened in the past 45 mins:

I instead put the methods that save stuff directly in the HelloWorldLayer class and linked them to the MainMenu.xib file.
I deleted the old class 'SaveController' because it was not needed.

Every time I build now I get BIZARRE warnings - first that there was an unrecognized class in the .xib - which there isn't because I supposedly removed all the references.
Things just started going all wrong with the weirdest errors, so I went back to a restore of the project I did before changing the methods and ran a clean build, now my project has about 240 warnings and they almost all go something like this:

%d format specifier expects type 'int' but type is 'NSUIInteger', replace with %ud?

-There are just hundreds of those with different values all over the cocos2d files and EVERYTHING, 240!!!!
Cleaned build, quit Xcode, restarting Mac now...

Any advice? D:

Hmm .. are you sure you are calling init on super on all overridden classes?
It sounds like you are missing some basic class functionality ... or sumthin'

I know, for all those that are/aren't reading this that it is lengthy and annoying.

But it gets weirder:
-I can't access any of the variables from inside the class or they will be nil/NULL
-I can read the classes variables and such from outside, inside the HelloWorldLayer.

...

Questions are:

a) If I can't store any variables, how on earth can I send messages to anything?
b) How the heck did this happen in the first place?
c)How do I fix this lack of ability to retain/store data?

...
This is the stupidest problem I have ever encountered.

Ha. Darn. @birkemose - I bet you can help me with this, I think I have found the problem - but it is pretty weird.

It turns out my subclass of NSMenu can't retain anything. At all. Even C type variable like integers.

If I create an NSNumber* and set its value to 7 in the init method with [NSNumber numberWithInt:7] and set the normal integer to 5, both print out as zero in any other method.

Odd, no?
Have you heard of this before?

I know that is a pretty stupid name, but I didn't really care at the time of writing it.
I know my code LOOKS fine - hence why I am so confused that it doesn't work.

I've gone over and over all the code that uses this array and I am just baffled by how utterly futile my attempts to repair the situation are.

Have you got ANY idea as to what could possibly be going wrong?

Basically what's happening is:
-Initialize pointer to array (and create arrayWithCapacity:)
-Send pointer to SaveController, breakpoint says that the instance variable NSMutableArray pointer is the same data value as when initialized in the init method of HelloWorldLayer
-I retain this pointer, I log the retain count and it says something like '3' for some reason (?)
-I access this array from another method in the class and it reports (via Breakpoint) that the data address is now 0x0 (nil).

I hate these problems. Been holding me up for DAYS now...

I was a little confused that you use the same name "blocks", but apart from that, I don't see anything wrong with your code.
You must be doing something wrong elsewhere.

Really stumped here. I cannot figure out what is going on after hours of browsing my code.
I thought that maybe using a fast enumeration while saving could have caused the error so I changed all my

for (MovableBlock* block in blocks)

methods, to:

for (int i = 0;i <[blocks count];i++)
MovableBlock* block = [blocks objectAtIndex:i];

Still no change :/

The weird thing is, if I breakpoint the creation of the array and read its data value (e.g. 0x899c24) then it is the same as the array of data in the SaveController class, but as soon as the program exits the init method the array changes to value '0x0' - nil, I guess.

I am retaining it properly, I am pretty sure.
I also tried changing it to a property, no change.

Please, does anyone have a clue as to what I could do to fix this?

Hey dude this looks like an awesome game! How did you manage the network data though? As in did you use gamecenter?

Thanks man. The game is actually quite fun, I hope you get a chance to try it out. The networking stuff was quite surprisingly easy to pull off, and framerate was never an issue during the development of the game (except loading stuff but that's expected).

Thanks again!

Any ideas?

Also, if it relevant or not I may add that the class 'SaveController' is imported by 'HelloWorldLayer' - SaveController does not import HelloWorldLayer.
Save controller is a subclass of NSMenu.

Thanks...

Thanks mavrik5150, I do something similar for sprites. Do CCLabelAtlas's need cleanup?

Looks fantastic. It's really polished. And the trailer is well done too. My concern with the "wow that's an awesome idea" kind of game, is that very often it's not as fun as it sounds at first. A bit like AR games. But the first reviews seems to be very good. Anyway congrats, that's a impressive achievement to complete such a game; maintaining a descent frame rate while loading network data must be a bit of a nightmare.

Introduction:
What would happen if what people share on Twitter turns real? And best of all, if you could play with that? Welcome to the first game that turns tweets into reality. Get ready to jump into your race-car, drive on Route 140 and live the most innovative adventure of the moment, escape from tsunamis, zombies, meteorites, motorcycle gangs, and many more events that are really happening on this precise moment.

But, you are not alone!
You will also be able to defend yourself with powerful weapons and cool events that will get you out of trouble and let you arrive safely to your destination. All of the events will be generated by people around the world that will create a new experience every time you play!

Why developers will find my game interesting:
Very interesting way to create events based on real tweets.

Why gamers will find my game interesting:
It uses real life tweets to schedule content, so it's pretty cool when you can see social networking being used as an input to a game.

Screenshots:

Tweet Land Trailer:
http://www.youtube.com/watch?v=6PXibEMngTM

You can read more about Tweet Land here:
http://www.tweetlandgame.com

Development: Tree Interactive

Publishing: Why Ideas

You can download Tweet Land from iTunes here:
http://itunes.apple.com/app/tweet-land/id491102570?mt=8

Please write an honest review on the app store and report directly back here about any bugs.

I've been implementing a File > Save/Open menu into my Cocos2d-MAC iPhone game level editor.

I created a class called 'SaveController' of which I created an instance variable in my 'HelloWorldScene'

SaveController* saveController;

.m init method -

blocks = [NSMutableArray arrayWithCapacity:60];
[blocks retain];

saveController = [[[SaveController alloc] initWithBlocks:blocks] autorelease];
[saveController retain];

'blocks' is supposedly a pointer to the NSMutableArray that stores the level editor 'block' (tile) data.

NSMutableArray* blocks;

So I instantiate 'saveController' with a pointer to the array, and make sure it is retained. (and released is dealloc).

Inside the SaveController .m :

-(id)initWithBlocks:(NSMutableArray *)b{
if ( (self = [super init]) ) {
blocks = b;
[blocks retain];
}
return self;}

In another method of the save controller, the one that responds to the NSSavePanel, there is a method I wrote to parse the data into JSON:

for (int i = 0;i < [blocks count];i++) {
MovableBlock* block = [blocks objectAtIndex:i];
... }

Despite the array of objects 'blocks' in HelloWorldLayer being full (e.g. 27 objects), when I access them through this loop the array is always blank.

Any clues as to what is going on?

Although not exactly the same as what you have listed I have a part of the game in which multiple sprites continue to show on the screen, but like you once they either make contact or leave the screen I want to remove that sprite instead of just having it hang out in memory. I did this below, maybe it can give you some ideas on what to do

NSMutableArray *objectsToDelete = [NSMutableArray alloc] init];

//after the sprite collision detection is ran I add that sprite to the array
[objectsToDelete addObjects:sprite];

//then in the end of my update area I have this part of code

for (CCSprite *object in objectsToDelete) {
[self removeChild:object cleanup:YES];
}

[objectsToDelete release];

You would probably want to change the CCSprite to CCLabelTTF but basically all I'm doing is for every sprite that needs to be removed from the screen I add that sprite to my array and then let the array determine how many objects need to be removed from the screen. Since my spawn method just adds a new sprite object to the scene when needed this seemed to be the best option both visually and performance wise.

Another scheme I was thinking of was to define an array in my header file and alloc/fill it up when my menu is showing and release it when it goes away.

I'm eventually going to make the switch to a bitmap font. But in the lifetime of a scene, the best way I could figure out to get rid of a label is to just give it a string value of " ".

I'd like to know more as well. From initially looking, the CCLabelTTF creates a texture for the text but it doesn't look like it makes its way to the shared texture cache (am I wrong on this?). If it doesn't, the texture should discard once the label is destroyed. If you're keeping several hundred instances, then you'll probably have several hundred textures sitting in memory (1 for each label).

With that many, is it possible you can use a font atlas (bitmap font) to cut down the textures? I stay with the CCLabelTTF because I need to control the font size dynamically, but I don't carry very many at any one time.

In my game now I have plenty of CCLabelTTF's. Names of labels point to it in my header file, and that design makes sense to me. I'm at a point now where I sometimes have a menu display over the paused game, and it will have x amount of labels. There may up to 40-50 of them, who knows. I'm not really sure how to proceed with this in the most organized way, but I'm confused whether or not CCLabelTTF's could ever be temporary and then all be released when that menu goes away. The way I handle getting rid of the labels now is just setting the string to a space " " which I know is probably really ghetto and not the proper procedure. Furthermore, those labels still exist. I know they don't take up a lot of resources, but if I'm going to have an upward of 200 of them or more (not all displaying all at once of course), I don't just want them hanging around.

If you're using a synthesized retain @property, releasing in dealloc can be done:

[hud release], hud = nil; // assigning nil isn't required, but habit to ensure its nil

or

[self setHud:nil]; // I prefer this when using properties, the retain/release are synthesized in the getter/setter

With that said, if your hud layer has been added to the scene, you don't need to retain it. You can simply use (assign) instead of retain and not worry about the dealloc. The layer object will be retained when you call [self addChild:hud] or where ever you add the layer.

Generally retaining the object too long creates a memory leak, so I'm wondering if your crash is related to something else? Do you have more details on where your crash is happening?