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: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:In Objective C??

[mmkkbb]

If you were porting something that's been written in C to Objective-C, you wouldn't need to change much. Only the points where your code absolutely must call objective-C library calls, really.

Re:In Objective C??

[larry bagina]

Quake and Doom were developed on NeXTStep 3.3. On hardware with less computational power than an iPhone.

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

[Fulg]

Further proof that this is possible: it's already ported. Jailbroken iPhone/iPod required though.

It's impressive to see it run that fast (30+ fps) on a phone, but quite honestly I find it unplayable due to the controls. Still, it's very cool :)

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:Finally a creative game from iD

[jandrese]

You're pretty close on what the Doom RPG was like. Carmack wrote about it some time ago, and the big point in his article was that although a lot of mobile phone hardware is actually pretty powerful, all of the carriers have ridiculous restrictions that prevent you from using it effectively. Most importantly, the maximum memory size was restricted down to a fraction of what was available on the phone and limited you to a very small palette of sprites/textures.

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.

Re:I don't see FPS being that fun with out a butto

[WiseWeasel]

Yes, the tilt sensors are very precise, but you do get some random noise that you have to account for in your software. Current tilt-based games such as Labyrinth (marble table game) and Super Monkey Ball are very playable, and the motion detection is incredibly sensitive and quite realistic. An anonymous EA developer actually commented on the iPhone's accelerometer's characteristics as an input device in this story, where it is compared with the Wii remote minus the Motion Plus additions.