John Carmack's Cell Phone Adventures 109
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."
Time consuming (Score:5, Funny)
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.
Re:Time consuming (Score:2, Funny)
Re:Time consuming (Score:3, Funny)
It's outsourced. (Score:5, Funny)
Re:It's outsourced. (Score:5, Interesting)
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 [ibm.com] 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.)
Re:It's outsourced. (Score:1)
I think the amount of battery required to power th
Just remember (Score:1)
Re:It's outsourced. (Score:2)
It depends. Chess is probably an extreme example, but it wasn't me that first brought it up.
Sure, you could make a chess game that only looked forward one move and this could probably run on a cell phone just fine, and be pretty fast. But if you want a game that can beat almost anybody, you'll need a
Re:It's outsourced. (Score:1)
Re:It's outsourced. (Score:2)
Well, a chess move could be given in two bytes -- starting square (1 of 64) and destination square (1 of 64.) You're not using the entire bytes, but you'll also need to account for castling and maybe some other stuff.
If a game is 50 moves (and that's a long game) that's 50 * 2 (two players) * 2 bytes/move, or 200 bytes for the entire game. I believe a KB of data costs $0.03 on Cingular (which is ludicrously expensive for `normal use') but so this
Re:It's outsourced. (Score:1)
> I believe a KB of data costs $0.03 on Cingular
Thats nice, tis 0.73p a K on PAYG Vodafone UK.
I think they also round up to the nearest K. Assuming the game is under a K, and in a single GPRS session, you are looking at 0.73p.
Re:Time consuming (Score:4, Insightful)
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:Y'know (Score:2)
Re:Y'know (Score:1)
'I don't really like talking to most people' (Score:5, Insightful)
A true geek :)
Re:'I don't really like talking to most people' (Score:3, Funny)
nope.
Quake... (Score:2, Funny)
Re:Quake... (Score:1)
Or perhaps tweaking the engine for their next game. He said it'll be a new franchise so perhaps we'll even see some innovation this time...
Re:Quake... (Score:2)
" and the fact that the work I had been doing at Id for the last half of Doom 3 development was basically pretty damn boring.... but the work at Id is back to a high level of interest now that we are working on a new game with new technology."
While that could be the Doom 3 expansion, it doesn't sound like it. Maybe something new we'll see in '07 or so.
Yes, but.. (Score:5, Funny)
There too? (Score:2, Funny)
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.
Bedeviled by Bejeweled (Score:1)
Re:Bedeviled by Bejeweled (Score:2, Interesting)
Re:Bedeviled by Bejeweled (Score:1)
Re:Bedeviled by Bejeweled (Score:1)
Re:Bedeviled by Bejeweled (Score:2)
Re:Bedeviled by Bejeweled (Score:2)
And what do you think Mypal A620 is, an artificial vagina?
It is an Asus PocketPC, a slightly faster version of A600 I have, plus CF slot. Reading books is, BTW, one of my favorite uses of my PDA. It also runs DOOM fine and Quake just barely playable.
That's gonna give the Java fanbois an aneurysm (Score:5, Interesting)
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.
Re:That's gonna give the Java fanbois an aneurysm (Score:4, 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 [sourceforge.net]
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.
Re:That's gonna give the Java fanbois an aneurysm (Score:4, Insightful)
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.
Re:That's gonna give the Java fanbois an aneurysm (Score:5, Insightful)
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:That's gonna give the Java fanbois an aneurysm (Score:3, Interesting)
Re:That's gonna give the Java fanbois an aneurysm (Score:4, Informative)
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.
Re:That's gonna give the Java fanbois an aneurysm (Score:1)
Re:That's gonna give the Java fanbois an aneurysm (Score:5, Insightful)
Re:That's gonna give the Java fanbois an aneurysm (Score:2)
I thought we all knew that clock speed comparisons across platforms were pointless...
That said, with the SNES you could hand-code assembler to get every cycle out of the CPU, GPU, and SPU. Not quite the case with Java.
Re:That's gonna give the Java fanbois an aneurysm (Score:2)
Re:That's gonna give the Java fanbois an aneurysm (Score:1)
From my xp, I'd go with Visual Basic & some awk mixed in for good messure.
Re:That's gonna give the Java fanbois an aneurysm (Score:2)
Apples and Oranges (Score:5, Insightful)
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:Apples and Oranges (Score:2)
Quite honestly I reckon every Java programmer should have to learn to deal with the J2ME environment at some point. A lot of the software architects too. I say this because I have seen a lot of software solutions, written in Java, that create objects at a rate of knots and then people wonder why the system is so damn slow and memory hungry.
Java might have its issues, b
Re:Apples and Oranges (Score:1, Insightful)
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 fa
Re:Apples and Oranges (Score:2)
AFAIK a call to System.gc() isn't suppoed guaranteed to actually execute GC, it just tells the VM that you would like it to GC if it could, please. So you're not doing anything wrong by ignoring calls to System.gc().
Although since you're writing a VM I probably don't need to tell you this.
Re:Apples and Oranges (Score:2)
You suggest it's a warrantless comparison, and that it's unfair to expect portable JVMs to run as well as desktop/server editions. That might be true if Sun's advertising for Java wasn't so based on a myth of universal compatibility.
"Write Once, Run Anywhere" propaganda is a lie.
Re:That's gonna give the Java fanbois an aneurysm (Score:2)
2. Write-once-run-anywhere: Not a problem with Java per se, more like the fault of two dozen handset manufacturers developin
Re:That's gonna give the Java fanbois an aneurysm (Score:3, Informative)
Re:That's gonna give the Java fanbois an aneurysm (Score:5, Informative)
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
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
Re:That's gonna give the Java fanbois an aneurysm (Score:2)
Re:It sure gave you anti-java zealots a hard-on (Score:1, Insightful)
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:It sure gave you anti-java zealots a hard-on (Score:1, Insightful)
In my reasonably extensive experirence, java fanbois don't know any better - or any worse - just java.
Who knew.... (Score:1)
Laugh if you want... (Score:5, Interesting)
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.
Re:Laugh if you want... (Score:2)
Every game I've bought for a cell phone (we have a Motorola something or other and a Sidekick 2) has been a one time cost (or free). How many subscription-based cell phones games are out there?
Re:Laugh if you want... (Score:5, Insightful)
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.
A little more insight (Score:1)
What has changed is that there is now an immense market for scams. Used to be, you couldn't get away with many scams because there just weren't enough people that were susceptible. Normal, everyday folks would see right through it and probably turn you in! People used to be diligent and take proper care of their affairs. Nowadays most, truly >50% I think, are so greedy, so lazy, so ignorant, and so lacking in integrity that scammers have a huge target market.
Why do you think something as
Re:Laugh if you want... (Score:5, Insightful)
I really wish they would dig Harry Truman up and make him president again. I'm tired of living in a 3rd world corruptocracy.
Cell Phone (Action/Adventure) Games Are Terrible (Score:4, Insightful)
Re:Cell Phone (Action/Adventure) Games Are Terribl (Score:3, Informative)
Uploading new data files can be a lot more of a bother though I guess. I've never tried that.
Re:Cell Phone (Action/Adventure) Games Are Terribl (Score:1)
Re:Cell Phone (Action/Adventure) Games Are Terribl (Score:2)
Yet another reason why I'll never again buy a branded mobile phone. I'd rather pay another $100 or so upfront and get a phone that actually works like it should.
Re:Cell Phone (Action/Adventure) Games Are Terribl (Score:2)
Re:Cell Phone (Action/Adventure) Games Are Terribl (Score:2)
Not a big deal if you've signed on for unlimited kb as part of your plan, but a big deal if you haven't.
Re:Cell Phone (Action/Adventure) Games Are Terribl (Score:2)
Re:Cell Phone (Action/Adventure) Games Are Terribl (Score:1)
The best part is... (Score:5, 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.
Re:The best part is... (Score:1)
He's not estimating - over or otherwise - anything. Jamdat has told him that the file should be between 150 and 200k. Jamdat has made it clear that it's best to target the newest phones since the majority of games are bought on purchase (or just after) of the phone (according to them), and most of the newest phones can handle those file sizes (again, according to them).
Re:The best part is... (Score:2)
But he's doing a 3D game, which puts the GBA in the exact same boat. Minus the no-direct-framebuffer-access thing.
Re:The best part is... (Score:2)
I for one, hope he will be focusing on bringing a scaled 3d-engine to the mobile platform ; Hopefully opening a whole new scene of homebrewed mods.
Re:The best part is... (Score:2)
I'll suggest that the man responsible for programming the Wolfenstein 3d [3drealms.com] engine (for the distinctly non-threaded DOS on a weirdly crippled 80286) will find those limitations survivable.
The good old shareware days (Score:3, Insightful)
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]
Re:The good old shareware days (Score:2, Funny)
Re:The good old shareware days (Score:1)
Re:The good old shareware days (Score:2)
Armadillo = Amarillo? (Score:1)
Re:Armadillo = Amarillo? (Score:3, Informative)
Re:Armadillo = Amarillo? (Score:2, Informative)
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 o
Re:Armadillo = Amarillo? (Score:1)
Re:Armadillo = Amarillo? (Score:2, Interesting)
DoomRPG eh? (Score:2)
Even more, the MMORPG market is awfully saturated as it is, but if they turn it it into one it could work well on cellphones (Pocket Kingdoms, anyone?) - if done right, of course.
I would certainly give it a try.
Twiddling bits with J2ME technology (Score:1)
Just like others have found out with C/C++ on other platforms, you can twiddle bits and get faster performance with Java on cell phones too. You just have to know what you're doing ;-) which hopefully Mr. Carmack will continue to do to find the secrets of J2ME technology that some already have discovered.
Also, you can deride JIT compilers on message boards, but if you take a look at Jbenchmark numbers, you'll see there is a world of difference between different Java VMs with different kinds of JITs, jus
Re:Twiddling bits with J2ME technology (Score:1)
Re:Twiddling bits with J2ME technology (Score:1)
There are phones that leak memory everytime you play a sound file or deallocate an Image, others where they break if you do something
Changing times... (Score:1, Insightful)
Re:Changing times... (Score:2)
Re:Changing times... (Score:1)
try symbain phones then... midp sucks!!! (Score:2, Interesting)
Will John be able to change things? (Score:2, Interesting)
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 targe
Hopefully Carmack has enough power (Score:2)
Marine Hits ChainsawZombie_00 for 10 Damage! (Score:1)
You gain Right Circle Strafe!
ChainsawZombies_00 attacks. You dodged!
Your machine gun crits ChainsawZombie_00 for 20 damage!
Right Circle Strafe fades from you.
ChainsawZombie_01 hits you for 30 damage!
You gain Left Circle Strafe!
You switch to Rocket Launcher.
ChainsawZombies_00 misses you.
Your Rocket Launcher hits Chain