NOOB :( How do you program a game...

Well you do have the gist of it, yes.
In practical terms however it is not as easy as it sounds. You have to hook up the code to the interface, learn Objective-C + the Cocoa framework etc.

I'd say that iPhone is not the best platform to start programming on.

 

Well, that would be one aspect of game programming in a nutshell I suppose -- specifically, getting something to move and animate on the screen. There's a lot more to actual game programming than that, but you've more or less touched on the tip of the iceberg.

Without getting technical, game prorgamming is a very, very in-depth subject that can cover a great deal of ground depending on what sort of game you want to write, and for the solo programmer there are a number of disciplines that all come into play when designing it. Much of it you can farm out if you don't have the talent -- graphics, sound effects, music, that sort of thing -- but those are the easiest parts anyway. Coding is the longest and most difficult part.

To get a thumbnail sketch you can read this Wikipedia article on game programming to get a rough idea of the typical steps involved game design and programming logic. If you're at all comfortable with that you can move on to learning how to program your own game through books, online tutorials and such. The iPhone also has a fantastic dev community who are often willing to help out with programming questions and issues as well, though don't expect them to hand you everything on a platter. You have to do your part, but if you're stuck there are many developers more than willing to lend a hand when you need it.

 

Then you have to program enemy collision, what happens when certain characters pick up item, program the AI, respawn locations, where the character dies, HP, the landscape...a lot harder than most people think.

+1.

 

I'm going to second the notion that programming in Cocoa/Obj-C is not the easiest place to start. If you really want to make games you should start with flash, you will be able to make progress right away, there are tons and tons of examples out there that will also teach you the basics of how games are put together, and that is knowledge that you can translate directly into iPhone programming when you are ready to make that leap. Google a guy named Emanuele Feronato to read his blog and learn some basics of making games in flash.

 

But before that you need to be able to load in the 3D character and textures. So you have to pick a 3D format that works with your 3D package, and an animation system that also works with it.

 

Your artist should stick to artisting. Graphics are only drawn in the code if you're creating special algorithmically-generated visual effects -- explosions, glow effects, blurring, depth of field, etc. Characters, ships -- anything in the foreground is almost always going to be straight up bitmaps. Even many effects, such as glow, light maps, and such, can be done with transparency overlays and light maps. You could create the sprites in real time if you really wanted to, but why would you waste all of that CPU time on such a thing when the same thing is achieved in a single blit with a bitmap image?

The majority of the time the character animations and most background animations are done with bitmap images, one image for each frame of animation. That's the simplest and most basic method. Multiple parts of a single character that can have independent animations can be done with individual bitmap images for each segment of the character that is to be animated independently. (Pocket God uses this method, for example.) Background animations are usually the same because it's the most memory-efficient method; you wouldn't do whole-screen animations because you'd be using up gobs of memory. Instead you create a background from a set of tiles, animating the ones that call for animation. You can sometimes get away with large single-bitmap backgrounds but it eats memory like a pig. There's a game I'm beta testing now that uses this method because the developer wants nice detailed levels, but he's probably going to have to convert it all over to tile-based to save memory, 'cos he's hitting pretty close to the magic 20 as it is.

 

Anyone who tells you he doesn't want to learn how to code and then goes on to explain how something works in code should be deemed to have a larynx in his sphincter. Just tell him to draw you some frames of animated things and stop flapping his glutes.

Depends on who you ask. I'm old school, so I still call them sprites. (I could really betray my age and original platform of choice and call them player/missiles, but I won't.) I don't even know if that term is still in use, but the concept is familiar I think to most programmers. You can call them bitmaps or tiles or whatever you want, really.

 

The term sprite is still very much alive and in use.