I spent a while thinking about what would actually make a good game for the platform, which is a very different design space than PCs or consoles.
Very true. You really can't simply think of, say, a cellphone as just a "tiny PC". As he said, the screen is smaller, the processor is slower, the memory is tighter, and the input controls is pretty lousy for action games.
What he doesn't point out is that the fundamental role of the thing as an entertainment device is often much different. People generally expect games that are suited for play in short "spurts" (while waiting for a bus, or for a meeting/class to start, etc.), and that can be interrupted and returned to (and looked up from temporarily while it's still running) with little damage to the gaming experience. Not only is it not as capable as a PS2, people don't really even use it in the same way, under the same circumstances.
I started my "mobile programming life" on the Palm (it was "Pilot" back then), and that's what the general consensus wound up being. Puzzle games, turn-based RPGs, card games, quiz games, and that sort of thing translated a lot better than full-on action games. I'd say that's even more true for cellphones, owing to the poor controller and smaller screen.
And, of course, the other caveat with cellphone programming is the trade-off between portability and sophistication. That's just a fact of life, and that goes for a lot of other cross-platform things (like web page design).
Anyway, I don't know exactly what sort of game he wound up doing, but it sounds like, despite his own admission that it's a different design space, he still came up with something ill-suited for a J2ME game.
Is the JVM slow? Maybe. But that's his fault for designing a game that needed a fast JVM.
Is it a pain having to tweak 100 different versions to run on all the different cellphones? Sure. But again, that's his fault for not designing the game to a lower common-denominator. I guess he's used to mono-platform programming, and it's a big paradigm shift when you move to something like this, where you have no clue what hardware it will wind up on.
Personally, I sort of perversely enjoy these limitations.
[ March 30, 2005: Message edited by: Jeff Jetton ] [ March 30, 2005: Message edited by: Jeff Jetton ]
I was disappointed though, to see his inital positive thoughts turn negative. I especially hate the 'java is slow' generalisation. Maybe we should let the Unreal (or Halflife more recently) people try their hand at it. I always preferred them to the Carmack crowd
One point John Carmack mentioned really resonated with my own beliefs. MIDlets on cellphones are a great way to introduce people to programming.
Writing programs for Windows is just too daunting. MIDP 1.0 allows you to easily create UI forms that do interesting things with just a little bit of code. Furthermore, you can run your programs on a device you probably already own and carry in your pocket.
Java is a decent first language to learn. It gets you started on OO design right away. Strong type checking catches most mistakes at compile time. The MIDP API is rich yet small enough to comprehend.
The problem with J2ME is all the ancillary crap you have to learn just to deploy your application. Where do you get the SDK? How do you install it? How do you package a JAR? How do you get it on to your phone?
Writing the program is the easy part!
I'm taking steps to remove some of the barriers to entry but I want to go beyond cookbook recipies for getting started. I imagine a system where users can enter code in a text box form on a webpage. The server would package the jar and send it directly to your phone. You shouldn't have to install anything. It should work from any web browser.
The first program wouldn't be much; just a simple "Hello World" MIDlet where neophyte programmers could make simple changes ("Hello John"). That would allow people to see some results instantly. That gets them hooked enough to install an SDK/IDE for real programming.