John Carmack discusses RAGE on iPhone/iPad/iPod

rageiphoneblog2.jpg

This month we’re privileged to share a special diary from the legendary John Carmack, technical director and co-founder of id Software. In addition to his current work on RAGE — coming to Xbox 360, Games for Windows, and PlayStation 3 on September 13, 2011 — and id Tech 5 technology, John has been working on an iPhone/iPad/iPod touch version of RAGE that will introduce gamers to the game’s story and world.

Round of applause for John Carmack…

RAGE for iPhone

Our mobile development efforts at id took some twists and turns in the last year. The plan was always to do something RAGE-related on the iPhone/iPad/iPod touch next, but with all the big things going on at id, the mobile efforts weren’t front and center on the priority list. There had been a bit of background work going on, but it was only towards the end of July that I was able to sit down and write the core engine code that would drive the project.

I was excited about how well it turned out, and since this was right before QuakeCon, I broke with tradition and did a live technology demo during my keynote. In hindsight, I probably introduced it poorly. I said something like “Its RAGE. On the iPhone. At 60 frames a second.”  Some people took that to mean that the entire PC/console game experience was going to be on the iPhone, which is definitely not the case.

What I showed was a technology demo, written from scratch, but using the RAGE content creation pipeline and media. We do not have the full RAGE game running on iOS, and we do not plan to try. While it would (amazingly!) actually be possible to compile the full-blown PC/console RAGE game for an iPhone4 with some effort, it would be a hopelessly bad idea. Even the latest and greatest mobile devices are still a fraction of the power of a 360 or PS3, let alone a high end gaming PC, so none of the carefully made performance tradeoffs would be appropriate for the platform, to say nothing of the vast differences in controls.

What we do have is something unlike anything ever seen on the iOS platforms. It is glorious, and a lot of fun. Development has been proceeding at high intensity since QuakeCon, and we hope to have the app out by the end of November.

The technical decision to use our megatexture content creation pipeline for the game levels had consequences for its scope. The data required for the game is big. Really, really big. Seeing Myst do well on the iPhone with a 700 meg download gave me some confidence that users would still download huge apps, and that became the target size for our standard definition version, but the high definition version for iPad / iPhone 4 will be around twice that size. This is more like getting a movie than an app, so be prepared for a long download. Still, for perspective, the full scale RAGE game is around 20 gigs of data with JPEG-XR compression, so 0.7 gigs of non-transcoded data is obviously a tiny slice of it.

Since we weren’t going to be able to have lots of hugely expansive levels, we knew that there would be some disappointment if we went out at a high price point, no matter how good it looked. We have experimented with a range of price points on the iPhone titles so far, but we had avoided the very low end. We decided that this would be a good opportunity to try a  $0.99 SD / $1.99 HD price point.  We need to stay focused on not letting the project creep out of control, but I think people will be very happy with the value.

The little slice of RAGE that we decided to build the iPhone product around is “Mutant Bash TV”, a post apocalyptic combat game show in the RAGE wasteland. This is the perfect setup for a quintessential first person shooter game play experience — you pick your targets, aim your shots, time your reloads, dodge the bad guys, and try and make it through to the end of the level with a better score than last time. Beyond basic survival, there are pickups, head shots, and hit streak multipliers to add more options to the gameplay, and there is a broad range of skill levels available from keep-hitting-fire-and-you-should-make-it to almost-impossible.

A large goal of the project has been to make sure that the levels can be replayed many times. The key is making the gamplay itself the rewarding aspect, rather than story progression, character development, or any kind of surprises. Many of the elements that made Doom Resurrection good the first time you played it hurt the replayability, for instance. RAGE iOS is all action, all the time. I have played the game dozens of times, and testing it is still fun instead of a chore.

Technical Geek Details

The id Tech 5 engine uses a uniform paged virtual texture system for basically everything in the game. While the algorithm would be possible on 3GS and later devices, it has a substantial per-fragment processing cost, and updating individual pages in a physical texture is not possible with PVRTC format textures. The approach used for mobile RAGE is to do the texture streaming based on variable sized contiguous “texture islands” in the world. This is much faster, but it forces geometric subdivision of large surfaces, and must be completely predictive instead of feedback reactive. Characters, items, and UI are traditionally textured.

We build the levels and preview them in RAGE on the PC, then run a profiling / extraction tool to generate the map data for the iOS game. This tool takes the path through the game and determines which texture islands are going to be visible, and at what resolution and orientation. The pixels for the texture island are extracted from the big RAGE page file, then anisotropically filtered into as many different versions as needed, and packed into 1024×1024 textures that are PVRTC compressed for the device.

The packing into the textures has conflicting goals – to minimize total app size you want to cram texture islands in everywhere they can fit, but you also don’t want to scatter the islands needed for a given view into a hundred different textures, or radically change your working set in nearby views. As with many NP complete problems, I wound up with a greedy value metric optimizing allocation strategy.

Managing over a gig of media made dealing with flash memory IO and process memory management very important, and I did a lot of performance investigations to figure things out.

Critically, almost all of the data is static, and can be freely discarded. iOS does not have a swapfile, so if you use too much dynamic memory, the OS gives you a warning or two, then kills your process. The bane of iOS developers is that “too much” is not defined, and in fact varies based on what other apps (Safari, Mail, iPod, etc) that are in memory have done. If you read all your game data into memory, the OS can’t do anything with it, and you are in danger. However, if all of your data is in a read-only memory mapped file, the OS can throw it out at will. This will cause a game hitch when you need it next, but it beats an abrupt termination. The low memory warning does still cause the frame rate to go to hell for a couple seconds as all the other apps try to discard things, even if the game doesn’t do much.

Interestingly, you can only memory map about 700 megs of virtual address space, which is a bit surprising for a 32 bit OS. I expected at least twice that, if not close to 3 gigs. We sometimes have a decent fraction of this mapped.

A page fault to a memory mapped file takes between 1.8 ms on an iPhone 4 and 2.2 ms on an iPod 2, and brings in 32k of data. There appears to be an optimization where if you fault at the very beginning of a file, it brings in 128k instead of 32k, which has implications for file headers.

I am pleased to report that fcntl( fd, F_NOCACHE ) works exactly as desired on iOS – I always worry about behavior of historic unix flags on Apple OSs. Using this and page aligned target memory will bypass the file cache and give very repeatable performance ranging from the page fault bandwidth with 32k reads up to 30 mb/s for one meg reads (22 mb/s for the old iPod). This is fractionally faster than straight reads due to the zero copy, but the important point is that it won’t evict any other buffer data that may have better temporal locality. All the world megatexture data is managed with uncached reads, since I know what I need well ahead of time, and there is a clear case for eviction. When you are past a given area, those unique textures won’t be needed again, unlike, say monster animations and audio, which are likely to reappear later.

I pre-touch the relevant world geometry in the uncached read thread after a texture read has completed, but in hindsight I should have bundled the world geometry directly with the textures and also gotten that with uncached reads.

OpenAL appears to have a limit of 1024 sound buffers, which we bumped into. We could dynamically create and destroy the static buffer mappings without too much trouble, but that is a reasonable number for us to stay under.

Another behavior of OpenAL that surprised me was finding (by looking at the disassembly) that it touches every 4k of the buffer on a Play() command. This makes some sense, forcing it to page the entire thing into ram so you don’t get broken sound mixing, but it does unpredictably stall the thread issuing the call. I had sort of hoped that they were just eating the page faults in the mixing thread with a decent sized mix ahead buffer, but I presume that they found pathological cases of a dozen sound buffers faulting while the GPU is sucking up all the bus bandwidth or some such. I may yet queue all OpenAL commands to a separate thread, so if it has to page stuff in, the audio will just be slightly delayed instead of hitching the framerate.

I wish I could prioritize the queuing of flash reads – game thread CPU faults highest, sound samples medium, and textures lowest. I did find that breaking the big texture reads up into chunks helped with the worst case CPU stalls.

There are two project technical decisions that I fretted over a lot:

Because I knew that the basic rendering technology could be expressed with fixed function rendering, the game is written to OpenGL ES 1.1, and can run on the older MBX GPU platforms. While it is nice to support older platforms, all evidence is that they are a negligible part of the market, and I did give up some optimization and feature opportunities for the decision.

It was sort of fun to dust off the old fixed function puzzle skills. For instance, getting monochrome dynamic lighting on top of the DOT3 normal mapping in a single pass involved sticking the lighting factor in the alpha channel of the texture environment color so it feeds through to the blender, where a GL_SRC_ALPHA, GL_ZERO blend mode effects the modulation on the opaque characters. This sort of fixed function trickery still makes me smile a bit, but it isn’t a relevant skill in the modern world of fragment shaders.

The other big one is the codebase lineage.

My personally written set of iPhone code includes the renderer for Wolfenstein RPG, all the iPhone specific code in Wolfenstein Classic and Doom Classic, and a few one-off test applications. At this point, I feel that I have a pretty good idea of what The Right Thing To Do on the platform is, but I don’t have a mature expression of that in a full game. There is some decent code in Doom Classic, but it is all C, and I would prefer to do new game development in (restrained) C++.

What we did have was Doom Resurrection, which was developed for us by Escalation Studios, with only a few pointers here and there from me. The play style was a pretty close match (there is much more freedom to look around in RAGE), so it seemed like a sensible thing. This fits with the school of thought that says “never throw away the code” (http://www.joelonsoftware.com/articles/fog0000000069.html ). I take issue with various parts of that, and much of my success over the years has involved wadding things up and throwing it all away, but there is still some wisdom there.

I have a good idea what the codebase would look like if I wrote it from scratch. It would have under 100k of mutable CPU data, there wouldn’t be a resource related character string in sight, and it would run at 60 fps on new platforms / 30 fps on old ones. I’m sure I could do it in four months or so (but I am probably wrong). Unfortunately, I can’t put four months into an iPhone project. I’m pushing it with two months —  I have the final big RAGE crunch and forward looking R&D to get back to.

So we built on the Resurrection codebase, which traded expediency for various compromise in code efficiency. It was an interesting experience for me, since almost all the code that I normally deal with has my “coding DNA” on it, because the id Software coding standards were basically “program the way John does.”  The Escalation programmers come from a completely different background, and the codebase is all STL this, boost that, fill-up-the-property list, dispatch the event, and delegate that.

I had been harboring some suspicions that our big codebases might benefit from the application of some more of the various “modern” C++ design patterns, despite seeing other large game codebases suffer under them. I have since recanted that suspicion.

I whine a lot about it (occasionally on twitter), and I sometimes point out various object lessons to the other mobile programmers, but in the end, it works, and it was probably the right decision.

John Carmack
10-26-2010

Reader Comments

  1. Thanks for the write-up John… so iirc, Rage iPhone will be using a modified megatexture approach and the game codebase from the Doom resurrection iPhone game. Love the price point–it’s very generous considering how much fluff is out there on the APP store. Very happy to hear that it’s planned to go live in about 1 month!

  2. excellent writeup. smartphones have completely changed expectations of mobile hardware, so i would except nothing less from id than to be constantly pushing the limits. (dealing with the amorphous state of iOS “multitasking” is not an enviable task, either.) i also enjoy this for a peek in to the use of real, honest-to-goodness computer science in video game development – it’s not all Ferraris, scooters, and beer.

    of course, things started whizzing over my head a bit in to the details section – after all, i am but a humble interaction designer – but i passed it on to our iPhone devs. the sound libraries in iOS are still a minefield of undocumented code and conflicts, so this information may have some use for them.

    thanks!

  3. It definitely looks good and I’m thankful for id to push the boundaries on mobile (and more specifically iPhone) gaming…

    On the customer side of things, I hope that id rereleases their products on the Mexican iTunes Store, where they disappeared over a year ago…

  4. I have no idea if you’ll ever read this but I hope so anyway now that I/we have a better idea of your opinions about (modern) C++ I’m wondering what your thoughts are on C++0x (which the ISO should be published in March) are. I’m pretty sure you’re not going to like what you see if you haven’t already lol good luck with rvalue references and move semantics…

    I was just reading one of your Twitts about you wished there was a mechisim to enforce side-effect free functions so I guess you’re aware of functional programming langauges. Did you learn any FP languages like Haskell? what’s your thoughts on them.

  5. Very cool write-up, as someone who has very recently delved into various programming langues it is pretty inspiring to hear from someone who has a amazing in-depth knowledge of programming and game design. Really interesting seeing how you managed to get something close to the original “megatexture” on an iPhone 4 and seeing how difficult it is to get a game working right.

  6. john carmack es un DIOS!!! es el mejor progreamador de todos yel mejor creador de juegos de todos!! gracias por crear doom y quake john!! sos un capo!!

  7. Why is John Carmack so awesome?

    he’s a space alien, ladies and gentlemen. let us bask in his otherworldly knowledge while he still sees fit to grace us with his luminous presence.

  8. This interview reminds me why John Carmack can be considered one of the few, honest to god genius programmers out there.

  9. John, really looking forward to Rage on the iPhone 4. I noticed that there has been no mention of Rage Mac only Games for Windows, I hope you will be releasing for Mac as well, I hate to only be able to play a very limited version on my iPhone and nothing on my Mac.

  10. “PVRTC can’t do this, PVRTC can’t do that.” If you weren’t wasting your time ogling the review samples 3DFX was sending you back in the day, PVRTC would be a much more versatile platform and you would know how to use it. Who’s laughing now? nVidia and ATI have to sell their products at a loss to Microsoft, Sony, and PC enthusiasts, and Videologic can dump loads of high yield product with impunity.

  11. Really enjoyed the ‘Technical Geek Section.’ I’ve been studying memory allocation and usage patterns recently, and it’s great to hear about some specific cases and challenges you’ve come up against on the iOS. Also, it’s good fun to read about your fixed function trickery. While much of the world has gone to shaders, I’ve seen and had my hands on plenty of projects that still use the fixed function. Whether for you it would be nostalgia, historical documentation, or both, I would love to see an article with more fixed-function trickery. Thanks for all you share, John.

  12. The smartphone devices is so fast in terms of hardware upgrades – for example the iPhone models upgrade cycle is every year – that if you want to have a very good quality game on this platforms which development takes at least a year – you will need to develop this project considering the future upgrade specification of next smartphone model which will be out when your game will be ready. The main thing which upgrades every year is the chipset, RAM and storage memory, maybe display.
    The integration of Apple App Store for mobile devices with desktop and notebook computers provides a very interesting opportunity for developers.
    For example if we will ever see Fallout 3 series game on Mac desktops in App Store for Macs – this product can be combine with a small but connected with big game application on the same App Store for iPhone – for example – the full Pip-boy device simulation experience on it. And if we will got desktop with Fallout 3 always connected by Wifi with iPhone/iPod where we have working Pip-boy – this integration will dramatically improve gaming experience for consumer.
    Fallout is great, but to change the gun there or use map you’ll need call the Pip-boy console on the main screen – this is distracting the user from the game.
    Integration of two devices – desktop/notebook with iPhone/iPod here will provide changing the weapons/map and etc. right on the fly without stopping the game process itself – which will be experience as real-life process which you can’t stop.
    ….

  13. Is it just me but I’m looking seriously at buying one of the new Android tablets (Toshiba or Samsung) and I hope as hell there’s a port for Rage for Android. It seems such a shame focusing on just one OS.

  14. Thanks for the write up, we are also working iOS and Android tablets with certain chips in them, we found the normal maps work great on an android tablet with certain gfx chip, but getting the same look on iOS is baffling us, we are almost just down to vertex lit shaders, any thoughts on how to squeeze a normal into iOS with out loosing quite a bit of frames. I notice from both Rage and Epic that it seems that a lot of stuff is prebaked in, which is great for static items but we dont have the luxury since we are allowing people to move objects around in our game.

    thoughts?

  15. Hi John,

    I was reading on gizmodo about how you felt that the on screen controls are not really the way to go for the iPhone/iPad. YES. Completely agree. Have you thought about using the GPS&Accelerometer on the device. Basically the user would actually walk around, Turn around, look around… Basically like an augmented reality app, but the augmented reality is your game…

    Just an idea, I’m sure there are lots out there. Great work on the game.

    Aaron (WiegerTheFarmer)

  16. This game is so good. It’s beautiful in grafix, It runs smothly on the iPhone 4, and the gameplay is superb. I’m very impressed. When I bought my iPhone it was for the phone and ipod, but if the quality of the games is this good, I must say I’m impressed.

  17. Listening to John talk about programming and technology must be how it was like to listen to Socrates talk about philosophy.

  18. Cheers John, technical innovation at its finest – as always.

    I implore you too get this up and running on other platforms through. We really need it. At least Android and hopefully Symbian if there’s enough flexibility.

    Thanks again,

    ~Ac

  19. found especially interesting the last bit, ‘…delegate that’ :D

    I’ve always wondered whether programmers use STL and Boost for games, and implement the Design Patterns in C++.

    Though they are great, while writing a game for my course I ended up studying how to use STL containers and port to different architectures instead actually working on the game, ‘overengineering’ did not pay up in the end!

    greets!
    m

  20. I just started playing this game on my iPhone but using the video out capability to play the game on my Vuzix Wrap920 video eyewear.
    Awesome, Awesome, Awesome!
    The phone becomes the game controller and I am seeing the game on a 67″ virtual screen!
    Come on idSoftware, do a stereo 3D version of this and all your games in stereo 3D!
    Just think of the fear when the goolies get closer and closer!
    These glasses completely decode the 3D signal and give a true large screen 3D experience from the iPhone!