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."
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.
A true geek :)
Slashdot Sig. version 0.1alpha. Use at your own risk.
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.
..how long will it take him to color the entire screen black and call it Doom 3 for mobiles?
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.
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.
... 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.
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.
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.
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.
get a palm man, read some books!
I'll do the stupid thing first and then you shy people follow...
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.
...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.
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/
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.
He means Armadillo Aerospace
/ Ho me
http://www.armadilloaerospace.com/n.x/Armadillo
"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."
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.