Carmack to Bring "Graphical Tour de Force" to the iPhone

Apparently developer John Carmack loves his iPhone and is still kicking himself for not having something ready to go at launch time. However, he has announced plans to bring a "graphical tour de force" to Apple's popular device. "But as for which one, the company isn't saying just yet, though given that the recently launched id Mobile division already has Doom RPG and the forthcoming Wolfenstein RPG to its credit, we wouldn't be at all surprised if Carmack will bring Quake or some flavor of Rage to the small screen as well. What's more, he's apparently considering the idea of tackling the MMO market on the iPhone down the line, though he admits that he's being 'conservative' and doesn't 'want to be in a bet-the-company situation' just yet."

Comments

Link to actual article..

[bigbigbison]

Here's the actual Forbes article rather than a link to a website that links to the article.

Re:Link to actual article..

[A little Frenchie]

here the print one without pub http://www.forbes.com/2008/07/24/doom-iphone-morris-tech-personal-cx_cm_0725doom_print.html

Re:Link to actual article..

[Anonymous Coward]

Here is a Wikipedia article about the joule:

http://en.wikipedia.org/wiki/Joule

I don't see FPS being that fun with out a buttons

[Joe The Dragon]

I don't see FPS being that fun with out a buttons. A RTS / TBS may work good but not MMO / FPS / driving games.

heroes of might and magic type games should work fine.

Finally a creative game from iD

[Chris Burke]

I gotta say I really like the idea of a game that combines the Star Wars universe with the world's most famous bike race. If they can pull it off, that is, and I have to wonder if the iPhone is really going to be the best target for this... wait...

Doom RPG, Wolfenstein RPG? Okay, since I can't really imagine what that would look like ("you shoot the pinkie demon with the rocket launcher and hit for 100 damage"?), it does sound somewhat creative. Maybe, I guess. Not nearly as cool as "Tour de Force" though... :(

iPhone Job Loss

[writerjosh]

How about a game where you stand in line for hours in front of the Apple store waiting to buy the new iPhone? You can watch your character sit for hours doing nothing in the hot sun looking at his other Apple gadgets. The more time that goes by, the more chance he has of losing his job because he played hooky from work to sit in line all day. When his "hooky" bar gets depleted, he loses his job.

"Oops. You just got fired!"
Play Again?

Re:What I'd like to see.

[InfinityWpi]

I had a game like that for my Treo 650 called Arcade Reality. It was a FPS (First-Person Space) game, like Star Raiders (god, I just dated myself, didn't I) that used the camera as a) a backdrop for the ships flying at you that you needed to shoot and b) to determine what direction you were moving in, since the phone didn't have one of those new-fangled accelerometers which are all the rage with you kids these days. Nifty bit of coding, that camera-used-to-sense-motion bit.

Fun game, too. Got me some funny looks tho.

Re:In Objective C??

[argent]

The only part that needs to be converted to Objective C is the part that creates and manages the game's viewport. THe existing game logic and models can remain in C or C++ (or Fortran=Fortran+1, or "ADD ONE TO COBOL GIVING COBOL"), and the user interface would be rewritten from scratch for the iPhone regardless.

Re:Best quote ever?

[timster]

Is it just me, or did you just divide the entire Earth into two categories:

1. Places where you're likely to get robbed, and
2. in front of your PC?

You can't know much objective C

[SuperKendall]

Uggh, I'd hate to be the guy having to port all of that old C code to Objective C

First of all, Objective-C is a pretty nice language with a lot of good features. It's hardly torture to use it.

But I doubt you'd know much about it, given that you do not realize you can mix C and objective C freely. Only the UI has to be objective C. Even that doesn't really have to have much objective C, just the bits where you make use of the UI frameworks... in a game you'd be doing mostly OpenGL anyway.

Re:You can't know much objective C

[SuperKendall]

I don't know about you, but as a one-time C programmer, 12 year Java programmer, I HATE Objective C.

I was a Java developer for about that long (or perhaps longer, I was doing some Java back around 1.0), and prior to that also had a lot of C and C++ and Lisp (mostly elisp) along with Scheme. The iPhone SDK is the first time I've done anything serious with Objective C, and I really like it.

For an example of a design "feature" of Objective C, you can extend/override a class. Any class. A class you don't even have source code access to. A class you don't even have package access to - it happens dynamically. Scary, important classes such as the base class. And you don't even do it IN the class, just another random file somewhere. Before anyone says that's useful, that rather destroys the whole concept of encapsulation.

This in NO WAY breaks the concept of encapsulation. It only enhances it. By being able to wrap ANY class in code of your own choosing, or adorn a class with new methods - you provide a powerful new range of composition abilities you don't easily have in Java (though you can do something similar with reflection trickery and interfaces).

It's also what allows for private method definitions that cannot be seen through your header file.

Yes it's dynamic. All of Objective-C is dynamic to the hilt, and that means there's a lot of stuff the compiler will not warn you about. But that can be OK, because the tradeoff is extreme flexibility and that is useful too. It means you can express some ideas in fewer lines of code and the less code there is the less room for error.

I'm sure the rest is that I don't like XCode either, but reading through the docs and writing some simple iPhone apps has been painful mostly because of the language and the lack of documentation (it really lacks a "here are all the tools you'll need to use to make an iPhone app", eg I completely found the UI editor by chance)

To me that says you are not reading the right documentation. I have found the documentation fairly extensive, and at least one of the introductory iPhone programming tutorials on the iPhone developer website builds a Hello World from scratch using Interface Builder. That aspect is well explained in at least a few documents, you have not read enough if you did not know about IB apart from accidentally launching it.

I would read ALL introductory material on iPhone development on the iPhone dev center, including the UI guide. You need those as a grounding. Skimming some books on Cocoa to understand the Foundation classes (which the iPhone also uses) is a very good idea to know of the capabilities of things like NSString or NSDateFormatter.

And if you use properties for a lot of stuff, even the syntax will not be so unfamiliar...

Also I would look around for introductory material on XCode. Try watching some of these videos, especially the XCode ones (in fact probably only those). If possible, try to find an iPhone Dev Camp near you and attend (it's this weekend, there are seven satellite locations). There are also a number of books on using XCode, one of those might be good to go through.

Lastly I recommend totally understanding the retain/release model, and coming up with a set of procedures that you always follow. In my case for any class local variable, I always make a property for it and mark it as "retain". Then I always use that to set the value, even inside the class - that way I know dealloc can clean it up, and I'll never forget to call retain when I need to. There are times when you'll need to release an object as a result but it's better to leak a little memory than to have unstable references lingering in code - the performance tools can track down leaks pretty well. Just be consistent in your approach and you will not make many mistakes.

Re:Best quote ever?

[_Sprocket_]

Damn you once again, Earl Grey.

Re:In Objective C??

[Graff]

Objective-C is a strict superset of C, any C code will work just fine as part of an Objective-C project.

C++ is not a strict superset of C, although a lot of the incompatable C++ syntax has been added back into C as of late. Even with that there are still a lot of gotchas when switching between C++ and C code.

Honestly I've found Objective-C to be very powerful, intuitive, and easy to use. C++, although powerful, has a lot of tricky syntax and ideas behind it. It's a great language for experts and because it is a statically-typed language it is fairly quick, but I think Objective-C is a much better programming language overall. Oh and even though Objective-C is a dynamically-typed language you can still run it fairly quickly by "freezing" some of the method calls and making them static. This gives you the freedom of choice between the ease of a dynamic language and the speed of a static language.

Apple has also worked it so that you can use C, C++, Objective-C, and several other languages fairly transparently in a single project.