Slashdot Mirror


John Carmack's Cell Phone Adventures

Mr. Carmack has updated his blog with news of his latest interests. Apparently mobile gaming on cell phones has consumed a large portion of his time of late, and he has some witty commentary on programming for the emerging game platform. From the article: "I'm not a cell phone guy. I resisted getting one at all for years, and even now I rarely carry it. To a first approximation, I don't really like talking to most people, so I don't go out of my way to enable people to call me. However, a little while ago I misplaced the old phone I usually take to Armadillo, and my wife picked up a more modern one for me. It had a nice color screen and a bunch of bad java game demos on it. The bad java games did it."

35 of 109 comments (clear)

  1. Time consuming by kryogen1x · · Score: 4, Funny
    Apparently mobile gaming on cell phones has consumed a large portion of his time of late

    No kidding. When I play chess against the AI on my phone, the thing takes minutes to make a move. It usually takes 20 minutes to play a game that would take two humans to play in 5.

    1. Re:Time consuming by TheGuano · · Score: 2, Funny

      Well, don't expect it to get any faster, but I'm sure Carmack will add some kick-ass per-pixel lighting and dynamic shadows to the board and pieces!

    2. Re:Time consuming by ShamusYoung · · Score: 3, Insightful
      I'll bet developing for tiny mobile platforms is really rewarding for him. Think about it: He rose to fame by taking very, very limited early-90's platforms and making them render cool things. A lot of his work over the years has been focused on getting the most out of a given system, finding tricks to reduce memory usage, to speed up framerate, and to limit the size of the game itself. Over the years his goal hasn't been simply to "do more", but to "do more with less".

      Today the focus is not so much on those things (we have lots of CPU cycles and memory to go around) but to spend those cycles making the most attractive images as possible. There is far more focus on asthetics and art, and less on raw technological power.

      Developing for a limited platform like a cellphone has much more in common with his roots: Find a way to squeeze something special out of this system that nobody else thinks is even possible.

      --
      --This sig is in beta. Please let us know abut any errors you find.
    3. Re:Time consuming by Mr.Dippy · · Score: 3, Funny

      Imagine playing Chess in dark and you can't move your pieces until you put down the flashlight becasue you only have one hand. I can't wait for the fun.

      --


      -Dipster
  2. 'I don't really like talking to most people' by arcanumas · · Score: 5, Insightful
    I don't really like talking to most people

    A true geek :)

    --
    Slashdot Sig. version 0.1alpha. Use at your own risk.
    1. Re:'I don't really like talking to most people' by Anonymous Coward · · Score: 3, Funny

      ...and my wife picked up...

      nope.

  3. Quake... by alexandreracine · · Score: 2, Funny

    Are you not suppose to be working on Quake 4 or something? Don't tell me you will release Quake 4 on the phone!

    --
    No sig for now.
  4. Yes, but.. by Anonymous Coward · · Score: 5, Funny

    ..how long will it take him to color the entire screen black and call it Doom 3 for mobiles?

  5. That's gonna give the Java fanbois an aneurysm by Anonymous Coward · · Score: 5, Interesting

    The biggest problem is that Java is really slow. On a pure cpu / memory / display / communications level, most modern cell phones should be considerably better gaming platforms than a Game Boy Advanced. With Java, on most phones you are left with about the CPU power of an original 4.77 mhz IBM PC, and lousy control over everything.

    Heh - that should put the "Java is just as fast as native code" myth to rest. It won't, as people will claim that Just In Time compilation should solve it, but...

    Even compiled to completely native code, Java semantic requirements like range checking on every array access hobble it. One of the phones (Motorola i730) has an option that does some load time compiling to improve performance, which does help a lot, but you have no idea what it is doing, and innocuous code changes can cause the compilable heuristic to fail.

    Which ends that myth too.

    Write-once-run-anywhere. Ha. Hahahahaha. We are only testing on four platforms right now, and not a single pair has the exact same quirks.

    And there goes that Java myth, too...

    Cell phones already have a very low latency digital data path - the circuit switched channel used for voice.

    Actually - he's wrong. That channel has a good half-second or so latency. Try this - call up your home phone, and pick both up. Don't worry about feedback - there's way too much latency. Talk into your cellphone and listen to it "echo" on your phone. Or call up your friend on their cellphone and talk to each other, and listen to the good second between when they say something and you hear it.

    It turns out that this latency isn't enough to prevent you from having a conversation, but there is quite a bit of latency on the voice connection of a cell phone.

    1. Re:That's gonna give the Java fanbois an aneurysm by TheRealFoxFire · · Score: 3, Interesting

      No, it just means that those myths don't apply on the Cell-phone platform. Thats not surprising, I doubt Cell Phones do JIT compiling, and their hardware is so different from PCs and each other, that you're stupid to think you aren't going to get away without testing.

      And to reiterate, Java is nearly as fast as native code. Some of it's libraries aren't as fast as C equivalents though. I should know

      Still, Java is appropriate for those devices, since it allows the manufacturers to change their phones frequently without rewriting much software, and allows consumers to use the same software on multiple makes/models of phone.

    2. Re:That's gonna give the Java fanbois an aneurysm by dtfinch · · Score: 4, Insightful

      4mhz was good enough for the super nintendo.

    3. Re:That's gonna give the Java fanbois an aneurysm by T-Ranger · · Score: 3, Insightful

      Well, there is the J2ME standard. Java 2 Mobile Edition or something. As for the hardware being significantly different from a PC (or an UltraSPAC.. actually, being RISCy the sparc is perhaps closer then the PC), so what? Java apps do not run on a PC. Java apps do not run on a cell phone. Java apps run on Java. Java apps all run on the same "hardware".

      To prefute your argument, "ya, but this is the real world, it does matter" all I can say is: Java has failed at its primary goal. "But thats the fault of the VM implementors". BS again: since Sun is amazingly anal about the word "Java", the blame all lies with them.

    4. Re:That's gonna give the Java fanbois an aneurysm by jilles · · Score: 5, Insightful

      Not yet. The problem with j2me is that there are so many implementations (and some of them really suck) of it. Some have JIT, some don't. There are a lot of hardware/software combinations. And that makes testing really hard. Of course you have the same problem if you move to another language. Because of that, there is not a lot to choose from. Brew and J2ME are basically it. Brew is optimized for gaming and J2ME targets a wider variety of software applications. Brew is a traditional, proprietary solution whereas J2ME is much more open with free development kits, documentation, etc. As Carmack notes, it is much easier to get started with it.

      An additional problem is that the core J2ME specs don't cover much functionality. All the interesting stuff is in optional modules which may or may not be implemented on a J2ME phone. There's a whole range of J2ME specifications that may or may not be implemented.

      John Carmack reasons very simple from a game developer point of view. Basically anything that gets in the way of direct access to the hardware annoys him. This way of thinking about writing software is not really suitable for mobile development. The problem with writing software for mobile phones (and pdas) is that you need to target as much phones as possible because typically a phone will only be on the market for a short period of time (a few months) and there are a lot of different phones. So if you want marketshare, forget about native C, direct on hardware type solutions. You need to abstract from as much hardware (cpu, memory, screen size, network, storage, input) and software details (which j2me specs, native os, jit or no jit) as possible. That's what J2ME is all about.

      --

      Jilles
    5. Re:That's gonna give the Java fanbois an aneurysm by moonbender · · Score: 2, Informative

      You're right, there has been an enormous increase in J2ME execution speed as well as feature set in the recent past. I've been doing some J2ME developement some weeks back - it really is very easy to get into once you have an IDE running - and I was surprised. For instance, the popular Sony Ericsson T610 is just awful wrt to Java: it only supports the very basic MIDP1, and it's extremely slow. My own Nokia 6230 supports MIDP2 and is more than 10x as fast. But it doesn't end there, today's phones are still 2 or 3 times faster than that.

      There is an excellent resource available at a French Java website, very much required reading if you're interested into J2ME development I'd guess. It lists most available Java phones, their feature set and speed.

      Of particular interest in responce to Carmack is the comparison with P3 execution speed: "As fast as a PIII (without Java compiler) at 1,477.2MHz" (that's a Nokia 6630). That said, I don't see how even a 3G smartphone could equal the execution speed of a 1.5Ghz P3, so that kind of makes their whole benchmark a bit dubious. Unfortunately Carmack only mentions just one handy (Motorola i730) which isn't listed on the page (hey John, download their benchmark and send them the results!). The fastest Motorola they do list (V600) is as fast as, haha, a PIII 16.7 MHz (still twice as fast as a T610!), so maybe Motorola just stinks in terms of Java execution.

      --
      Switch back to Slashdot's D1 system.
    6. Re:That's gonna give the Java fanbois an aneurysm by xenocide2 · · Score: 2, Interesting

      John Carmack is one man, and a fairly intelligent programmer. But there are also several others who write programs, and you'd be naive to assume them all as talented and knowledgable about programming vulnerabilities as The Man. Normally this isn't a problem, as any program you write only affects your device. But being connected to a network changes all this. One bluetooth virus exploit unleashed during CES (probably the largest orgy of mobile devices known to man) turns that deal with Motorola to provide your software on the default firmware into a deal to provide a security exploit to Motorola.

      So not only do you need Java for your cross platform compatibility that is so very nessecary on mobile phone programming, but you need the JVM's enforced behavior checks so you don't run up a rather large bill on behalf of your paying users. It's very unlikely that a small gaming company can afford to defend its "NO GUARENTEES OF USABILITY FOR ANY KIND AND WE'RE TOTALLY NOT LIABLE IF THIS COSTS YOU A FORTUNE IN FEES" disclaimer in their EULA when that buffer check SHOULD have been implemented. Java provides them with a fairly strong guarentee that their buffers are safe, and that even if something else happens, you should be effectively quarantined from networking functionality. Ultimately, John Carmack is dissapointed, but writing games is probably a waste of his skills versus writing the JVM itself.

      --
      I Browse at +4 Flamebait

      Open Source Sysadmin

    7. Re:That's gonna give the Java fanbois an aneurysm by Screaming+Lunatic · · Score: 3, Informative
      John Carmack reasons very simple from a game developer point of view. Basically anything that gets in the way of direct access to the hardware annoys him. This way of thinking about writing software is not really suitable for mobile development.

      Bullshit. What Carmack is asking for is value types. That arrays of data be laid out contiguously. He's not asking for direct access to hardware. He's asking the runtime to not be so damn brain dead.

      Supporting value types will not destroy hardware abstraction.

      And this not a game developer's point of view only. For example, .NET/CLI supports value types.

      This is based on a fundamental principle of computing that contiguous data access is better than non-contiguous data access. Period.

    8. Re:That's gonna give the Java fanbois an aneurysm by John+Carmack · · Score: 4, Informative

      I did try running that benchmark, but it won't load on the i730 (score one more for run-anywhere...).

      One of our test platforms is a fairly high end Sony Ericsson, which is 10x as fast as our Motorola base platform. For a 128x128 screen, the Motorola renders about 4 fps and the Sony renders about 40 fps. Compare with Wolfenstein-3D performance (the DoomRPG engine has some extra graphics features, but it is still in that general class) at that resolution on older systems. A 386-16 would go significantly faster.

      Note that the "As fast as a ..." comparisons from the benchmark are against purely interpreted java on the P3, which is about 1/10th the speed of a native implementation, and benchmarks that focus on expression and control operations will overestimate relative performance for applications that are array access heavy. Still, if a java app on that phone performed like a P3-100mhz, it would be pretty impressive.

      It is true that a good JIT (which the phones don't have) can make java code go nearly as fast as C/C++ code that is written in the same style. The "in the same style" part is often overlooked -- in lower level languages you often have options for implementation with pointers and CPU tailoring that would make the code look very different, but go significantly faster.

      I still generally like java, and maximizing performance is only important in a rather limited subset of software engineering.

      John Carmack

  6. There too? by AtariAmarok · · Score: 2, Funny
    "how long will it take him to color the entire screen black and call it Doom 3 for mobiles?"

    It's bad there too? I remember "Doom" for Nintendo 64. You wanted to shine a flashlight at the screen, it was that bad. For those if you who have not experienced it, try playing your favorite game while wearing sunglasses 3 deep.

    --
    Don't blame Durga. I voted for Centauri.
  7. Laugh if you want... by dhakbar · · Score: 5, Interesting

    ... but mobile phone gaming is an IMMENSE market. The key is in the subscription model. People will download a game and subscribe, play it once or twice, and forget about it. They never cancel, so they continue to pay $3/month for the game.

    I worked on a few cell phone games for SOE when I was working there, and all I have to say is that the sales figures make me want to be a cell phone gaming tycoon. It's not a pipe dream.

    1. Re:Laugh if you want... by Hast · · Score: 5, Insightful

      I remember a time when scamming your customers wasn't a common business strategy.

      Actually I don't, but wouldn't it be nice if people tried to do things in order to make a good job instead of just ripping people off? Ah well, I can always dream I guess.

    2. Re:Laugh if you want... by jbolden · · Score: 4, Insightful

      It was the case 15 years ago. Back then decent business wouldn't do business with companies that ripped off their customers. So the game companies that did this couldn't get near a Verizon or a Sprint, now Verizon and Sprint are both part of the scams. The media would have crucified Verizon or Sprint for letting this stuff go on, now the media is owned by the same guys. People would have refused to do business with companies that lack ethics, now they all lack ethics.

      I really wish they would dig Harry Truman up and make him president again. I'm tired of living in a 3rd world corruptocracy.

  8. It's outsourced. by AtariAmarok · · Score: 5, Funny

    They were too cheap to complete a chess program with good AI. You are not waiting for a slow computer. You are instead waiting for a rather frazzled guy in Mumbai whose job it is to play the computer opponent in anywhere from 10 to 50 phone chess games at any given time.

    --
    Don't blame Durga. I voted for Centauri.
    1. Re:It's outsourced. by dougmc · · Score: 5, Interesting
      You are not waiting for a slow computer. You are instead waiting for a rather frazzled guy in Mumbai whose job it is to play the computer opponent in anywhere from 10 to 50 phone chess games at any given time
      I know you're joking, but you could very well be giving the future of cell phone chess games too.

      Cell phone cpus are slow, and suck up the battery while they're working. But an entire chess board layout is very simple, and it wouldn't take much bandwidth to transmit your entire chess board layout to a remote computer which could then calculate the next move and transmit it back. (And that's assuming that the remote computer keeps no state information. If it kept track of the chess board itself, the bandwidth needed per move would just be a few bytes.)

      I could see a cell phone company buying Deep Blue or some similar big honking box and reprogramming it to play lots of games at once. Then release a chess application for cell phones that uses the data capability to allow you to play chess `against Deep Blue.'

      Sure, Deep Blue would not be playing 1000 simultaneous world-class chess games (though for an extra fee, you could get more cpu dedicated to you giving you a better opponnent), but it could probably beat most people. (The only reason to use Deep Blue itself is for the name recognition. A number of racks of PCs would work too, but it wouldn't have the obvious marketing potential.)

      This is one case where having a remote server do most of the work makes perfect sense. (Having a PC play chess with a remote server doing the work makes less sense, as a PC has much more cpu to work with, so it's not as needed.)

  9. Cell Phone (Action/Adventure) Games Are Terrible by DeckerEgo · · Score: 3, Insightful

    He's 100% right. I got a Samsung a while back & purchased a copy of Baldur's Gate for it... wow. My expectation of quality was that of the original Game Boy... they didn't even go that far. Sprite collision detection was awful, load times were abysmal, game balance was horrid and bugs abounded (i.e. go to inventory screen, pause game, resume game, all your keymappings are scrambled). It's a damn shame, too, considering the possibility the platform holds. You could do something very nice with it... but alas. And developing on one is a pain too - transferring files over (or trying to sell games to other players) is so much of a headache I don't want to develop on them. Really, the SDK and API is there (since it's all J2ME), but transferring files to the phone in the first place is to huge of a barrier.

  10. Re:Cell Phone (Action/Adventure) Games Are Terribl by Hast · · Score: 2, Informative

    Transferring the MIDP program is hard? I just drag and drop it to the root in the Bluetooth folder and it is uploaded. I'd think you can do the same thing over IrDA or USB, but I don't know as I've never tried.

    Uploading new data files can be a lot more of a bother though I guess. I've never tried that.

  11. Re:Bedeviled by Bejeweled by afd8856 · · Score: 2, Interesting

    get a palm man, read some books!

    --
    I'll do the stupid thing first and then you shy people follow...
  12. Apples and Oranges by Dr.+Bent · · Score: 5, Insightful

    The Java platform that runs on most cell phones is J2ME, which is a completely different animal than J2SE, the one that's used on PCs.

    The differences are substantial. For example, some J2ME VM's don't garbage collect. Ever. That's because in some cases, it's not required.

    To say that the J2SE (or J2EE) plaforms suck because a particular J2ME implementation is slow is like saying that internal combustion engines suck because your go-kart can only go 15 mph.

  13. The best part is... by BW_Nuprin · · Score: 4, Insightful

    ...Carmack is way over-estimating performance of most phones. Only the highest-end Java phones support 200k jar sizes. The majority of consumer phones are limited to 64k - even many brand new phones have this limitation. On the other hand, he's not being 100% fair with his GBA comparison. Gameboy, GBC, and Gameboy Advance all have tile-based rendering that is easily capable of 60fps, while Java-based (and BREW-based) cell phones have only linear frame buffers that you don't get direct access to (usually). To aggravate things, many Samsung BREW phones have 250ms response rates.

    Carmack will also be disappointed when he begins experimenting with BREW. BREW doesn't support threading, globals, or even static variables. I'm not even going to get started on the bizarre latencies of the API.

    One of my jobs as a cellphone developer is to port Java games to BREW. Carmack's comments about how fast Java phones play like 4.77MHz IBMs is true, but the same is true for BREW phones as well. I've only managed to squeeze another 10% out of the performance on similar BREW phones. There are a lot of things limiting cellphone performance, but Java isn't one of the main culprits. Bad platform design and slow hardware are what kills it.

  14. The good old shareware days by El_Muerte_TDS · · Score: 3, Insightful

    Warning: what you are experiencing are the gold old shareware days. A lot of small, simple yet addictive games.

    John Romero and Tom Hall had that same feeling a couple of years ago when they erected Monkeystone Games: http://www.monkeystone.com/

    1. Re:The good old shareware days by BigBadDude · · Score: 2, Funny

      Please dont use John Romero and feeling in the same line. Brings back bad bad memories...

  15. Re:Armadillo = Amarillo? by Klowner · · Score: 2, Informative

    Carmack is a smart guy, he can tell the difference I'm sure. In his reference to "Armadillo", he's most likely referring to his cool rocket development group which is named "Armadillo Aerospace", iirc.

  16. Re:Armadillo = Amarillo? by Wyatt+Earp · · Score: 2, Informative

    He means Armadillo Aerospace

    http://www.armadilloaerospace.com/n.x/Armadillo/ Ho me

    "Armadillo Aerospace is a small research and development team working oncomputer-controlled hydrogen peroxide rocket vehicles, with an eye towards manned suborbital vehicle development in the coming years. The team currently consists of a bunch of guys, a girl, and an armadillo named Widget. Ourfearless leader, John Carmack, will lead us to space and, well, outer space. Please feel free to make yourselves at home and check out our journey."

  17. Re:Armadillo = Amarillo? by ReversEngineer · · Score: 2, Interesting

    Wow. I have heard of Armadillo Airspace before, but I guess I didn't make a connection there earlier. Go ahead, I deserve the bashing. *Hangs head in shame*

  18. try symbain phones then... midp sucks!!! by xshader · · Score: 2, Interesting

    john, you should be writing for symbian phones then. they have the largest fucking market share by far and all run basically the same binaries. oh, did i mention they have a C/C++ sdk avaiable for free? go look at the games already running on s60 series phones... sonic, doom, super monkey ball... and soo many more fast paced action games. so the question is... why the heck did you go with midp2? as you were saying, all that abstration sucks.

  19. Will John be able to change things? by jasenj1 · · Score: 2, Interesting

    So John Carmack, one of the semi-dieties of game programming, has set his sites on the cell phone market.

    What if he follows through on this attempt to make a cell phone game and does what he's done in the past with PC gaming? That is, pick the best, fastest hardware available at the time and then develop something that requires specs a LITTLE better than what's available to be really playable.

    Let's suppose he finds a phone with a good, "fast" Java implementation, with a decent amount of memory, and targets his game for that minimum spec. Once the game is released, will we suddenly see a shift in cell phone performance? As every Doom fanboi wants the game and dumps their current lame phone and provider for whoever supports/carries a phone good enough to run MobileDoomRPG.

    Will John Carmack be able to redefine the performance expectations of the cell phone industry? Will DoomRPG Capable(tm) become a new standard?

    I certainly hope so. If the state of the industry is as bad as some have indicated in this thread, there needs to be a compelling reason to get performance beyond "good enough".

    - Jasen.