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."

'I don't really like talking to most people'

[arcanumas]

I don't really like talking to most people

A true geek :)

Cell Phone (Action/Adventure) Games Are Terrible

[DeckerEgo]

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.

Re:It sure gave you anti-java zealots a hard-on

[Anonymous Coward]

Java's not a programming language.

It's a platform that happens to be centered around a programming language.

There exist compilers that can compile the Java language to native code. But this article is about the Java platform - specifically, the Java platform for embedded devices.

Re:Laugh if you want...

[Hast]

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.

Re:It sure gave you anti-java zealots a hard-on

[Anonymous Coward]

Surely anyone - no matter how capable (legendary) they are - must be plain stoopid if they use "bad" and "java" in the same sentence.

In my reasonably extensive experirence, java fanbois don't know any better - or any worse - just java.

Re:That's gonna give the Java fanbois an aneurysm

[dtfinch]

4mhz was good enough for the super nintendo.

Re:Time consuming

[ShamusYoung]

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.

Re:That's gonna give the Java fanbois an aneurysm

[T-Ranger]

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.

Apples and Oranges

[Dr. Bent]

The Java platform that runs on most cell phones is J2ME [sun.com], which is a completely different animal than J2SE [sun.com], 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.

Re:That's gonna give the Java fanbois an aneurysm

[jilles]

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.

Re:Laugh if you want...

[jbolden]

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.

The best part is...

[BW_Nuprin]

...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.

The good old shareware days

[El_Muerte_TDS]

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/ [monkeystone.com]

Changing times...

[Rob T Firefly]

In my day, playing on the phone meant asking random people if their refrigerator was running.

Re:Apples and Oranges

[Anonymous Coward]

For example, some J2ME VM's don't garbage collect. Ever.

Indeed. I work on a mobile Java VM implementation, and when it came time to look at running midlets from "out in the wild", we were surprised to find there was more than one that called System.gc() incessantly, to the point of making performance come to a crawl (it spent more time gc'ing than running).

Later, I mentioned this to a friend of mine whose job is porting games between different cellphones (much of it java-to-java), and he said he in fact did stuff like that all the time to work around broken JVM gc implementations which at least knew how to gc but wouldn't do so unless told, preferring instead to crash.

The tragedy, of course, is that, in order to be "compatible" with existing apps, I had to "fix" our VM to ignore System.gc() if it gets called a lot. This is just one example of the kind of brain damage that ends up spreading from one VM to another. Sure I could get all high and mighty and say "Our VM is pure and correct" but that won't make Joe Schmoe's favorite game run.