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."
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.
... 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.
get a palm man, read some books!
I'll do the stupid thing first and then you shy people follow...
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.)
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*
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.
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.