New to Objective C and iPhone dev, but not programming or game dev

[whitey]

I hope this is the right place to put this, I'm new here

As the title states, I've been doing game dev in my home for years, and have used many programming languages, mainly but not limited to: C/C++, Java and AS3 (flash).
I'm new to Objective C, and have been reading around, searching and following tutorials, and of course messing with code myself. I've got a good grasp on the language now I think, but still not general iPhone dev.

I'm mainly interested in game development (which is why i put this here), and for now just 2D. I know of API's such as Cocos2D, however, whether I decide to use them or not, I'd like to understand all the basics going on in the background, and get some hands-on experience with them first.

With that said, I have a bunch of questions I'm looking for quick, concise answers to all in one spot to help clear things up for me (and hopefully others that may come across this).

Alright guys, here goes :P

1. The whole NIB thing.. I haven't really used Interface Builder, and the whole concept makes things more confusing. I also find it to be overkill for games, since your app is likely to be less UI heavy, and menu's will be pretty straightforward (most of the time). I've found out how to dump nibs all together and define your views programmatically, which at this point I prefer. However I'm wondering if there are any advantages/disadvantages to using NIBs for game development specifically. I'm sure they'd be great for general apps with lots of indepth UI. For those you making games, which do you prefer?

2. While I'm getting used to Objective C now, I still am pretty clueless on the iOS APIs, the XCode IDE, etc. Lately I've mostly used Eclipse or Eclipse-based IDE's, which have amazing code hinting and code completion. You can document pretty much all of your code with clean comments (as are all the built in API's), which makes everything quick and easy. I know XCode has code completion, but it's not as robust. In Eclipse, you just type a class or instance name and . and wait a second and a list pops up with all the variables and functions, and you can go through the list and it displays all the details documents in the comments. This makes it really easy if you forget features, or if you're not used to a certain object and have no idea what it includes or what it's capable of. I was wondering if there a feature or plugin like this available for XCode?

3. From what I read, everyone seems to discourage using primitives, and use object such as CGFloat or NSNumber, for example, instead of just a regular float. The reason being cross-platform compatability (OS, processor, 32 vs 64 bit, etc). For the past view years I've used Java and flash, which run in VM's, so I never had to worry about this. I'd prefer using float, int etc because it looks way cleaner in my opinion. I was wondering, since the iPhone devices are available as-is, are there any differences in them that I would need to worry about such issues? IE. There's no need to worry about 32bit vs 64bit iOS's, correct. I've read they're all 32 bit, and don't even support double datatypes, so just using a plain old float should be safe?

4. GRAPHICS!! As I said before, I'm mainly interested in 2D right now, and on computers, OpenGL is still a great choice for 2D games. However, I was wondering if this is the best option on the iPhone, or is there a better alternative? My games will be pretty graphically intensive, so the power of OpenGL would be great, but I'm not sure how well it is handled. If you're doing 3D, it's the only choice, but is the intensity of running an OpenGL based app on iOS devices more of a drawback if you're only rendering in 2D? Or does it provide better acceleration even with just 2D? I'm mainly looking at this from a performance perspective.

5. The best way to run a game loop? The only thing I'm aware of right now for accomplishing this is by using and NSTimer. Is this the best option? If so, how accurate and consistant is it? Can I rely on it for a fixed timestep? Or should I correct it or use a variable dt?

6. Using the game loop and views (menus). It's clearly best to take advantage of the built in UI to handle GUI and menus/etc, but from what I understand so far, each view (menu/state) needs it's own view controller. I'm used to having a general loop, and a state switching system, which just calls update/draw on the current state every frame, so the main loop/timing system isn't just incorporated in the game "view." This seems to be different for the iPhone though, as most tutorials I see have an NSTimer within the gamestate view controller, however, most tutorials only have the 1 game state view. So what is the best way to handle state switching (views/controllers) and the main loop? Do I even need a running loop to handle simple game menu's if I'm using the built in UI?

7. I haven't really looked into this yet, but I figure I'll put it in here. I have never really used multithreading, but it seems it is a must for iOS apps, especially if you're handling button events, touch events, and rendering a game at the same time. Is this true? If so, what is the most common way of splitting processes up?

That is all for now lol, thanks for reading such a long noobish post.

Any help is appreciated

[fiftysixty]

Wow, a lot of questions, and I see nobody has provided any answers. I'll do my best, hope I can help.

1. I've mainly used Cocos2D for games, and as you said yourself, there is little reason to use NIBs for games. Of course, the benefit is to be able to graphically build your interface, but IMO game UI design is so different from normal app UI design, as a process, that there is little value in using IB. My game artist is the one who actually does the work of building the elements of the UI, I don't really use anything off-the-shelf, and the UIs themselves are so simple that it is not a problem to create them programmatically. Usually, at least. Also, though the Core Animation is incredibly well thought out and powerful, it doesn't mix so well with the Cocos2D Action -model so I prefer to keep the code cleaner and use just one set of tools.

2. The code completion in Xcode has gotten a lot better as of Xcode 4. If you use brackets right, you usually get the right results. So, always start with (correct number of) [ before the instance variable and you should be fine. If you don't use the brackets, then Xcode really has no way of knowing which class you're referring to. In the autocompletion list, if you hover over items you get a question mark on the right and if you click that, you'll get quick docs for that method. Unfortunately I don't know if there is a keyboard shortcut for that. Also, option (alt) clicking a method name in source code brings up the short documentation for it, and option-doubleclick opens the full documentation for the method/class.

3. CGFloat is actually not an object, it's just a typedef and on all current iOS devices is defined as a float. However, because of cross-platform compatibility,
you're better off using CGFloat that just a regular float. Same for NSInteger and NSUinteger. NSNumber, however, is an object, and it's the best way to store numbers in collections etc. NSNumber covers all number primitives so you don't have different classes for each primitive type. Also, you're very likely to use CGSize and CGRect data types, so using CGFloat is actually keeping in line with the general programming style. IMO floats, ints etc. actually look out of place in Objective-C.

4. Since the fundamental compositing engine in iOS and OS X runs on OpenGL, you'll definitely want to use it for all your graphics coding. Or, use a library such as Cocos2D. There is no point in doing software rendering on the CPU unless you really absolutely need the extra precision. For games, that pretty much means never.

5. This goes a bit out of my comfort zone, to be honest. I rely on the scheduling mechanism of Cocos2D, which provides the dt on each update. You could also use the CADisplayLink and tie the run loop to the display refresh rate. But using NSTimer is definitely an option as well.

6. The Cocoa Touch frameworks very heavily use the MVC pattern, so that's why you need a separate view controller for each view. You can change the contents of the view freely, however, so you can implement pretty much anything you want with just a single view controller. If you implement the game menu/etc. UI with UIKit, then you obviously won't need a running loop until you actually launch your game view. You can handle all animations and transitions (well, most of them, if you don't go into complex 3D stuff) using Core Animation. The "problem", IMO, is just that you will end up having two different kinds of UI layers: the standard UIKit for everything outside the game view(s), and then something else for when you're within the game view and running the game. You can overlay UIKit objects in an EAGLView and put the controls there, but you could run into some performance issues because the UIKit event handling could block the game loop. I haven't experimented with that, so I don't know if that's a serious issue or something that is unlikely to cause any harm.

7. The way the UIKit (and AppKit on OS X) works is that it runs each app on a single thread. The standard UI event handling happens on the same thread, so you can easily cause unresponsiveness on the UI side if you don't run long tasks on a thread. And there are many ways to do that. Perhaps the simplest one is [NSThread detachNewThreadSelector: toTarget: withObject] which calls the specified method on the specified target object and spins it off on a new thread. Since iOS 4 you can also use blocks and the multiple dispatch queues. I would strongly recommend going the way of blocks and dispatch queues as it simplifies a lot of things, and it is future proof. Grand Central Dispatch is the way Apple is taking with the core libraries, and you'll run into blocks in many many places so it's best to learn to use them well. This is a whole subject on itself, so it's best to read the Apple documentation and some online tutorials to get up to speed.

Hope I could help you, at least it was helpful for me to write this because I had to think and check some things. I hope there are no big errors there, but if there are, I apologize in advance.