Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
Portables (Games) Wireless Networking Hardware

John Carmack's Cell Phone Adventures 109

Posted by Zonk from the poking-tiny-space-marines dept.
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."
This discussion has been archived. No new comments can be posted.

John Carmack's Cell Phone Adventures More

John Carmack's Cell Phone Adventures

Comments Filter:

  • Time consuming (Score:5, Funny)

    by kryogen1x ( 838672 ) on Monday March 28, 2005 @11:44AM (#12066655)
    Apparently mobile gaming on cell phones has consumed a large portion of his time of late

    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.

    • Well, don't expect it to get any faster, but I'm sure Carmack will add some kick-ass per-pixel lighting and dynamic shadows to the board and pieces!
      • Imagine playing Chess in dark and you can't move your pieces until you put down the flashlight becasue you only have one hand. I can't wait for the fun.

    • It's outsourced. (Score:5, Funny)

      by AtariAmarok ( 451306 ) on Monday March 28, 2005 @11:59AM (#12066818)
      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.

      • Re:It's outsourced. (Score:5, Interesting)

        by dougmc ( 70836 ) <dougmc+slashdot@frenzied.us> on Monday March 28, 2005 @12:49PM (#12067266) Homepage
        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
        I know you're joking, but you could very well be giving the future of cell phone chess games too.

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

        • 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 think the amount of battery required to power th
          • The only way we are going to satisfy the Turing Test is to have a small sweaty man inside a silver-painted cardboard box, with a typewriter, feeding answers to the test questions to the outside through a slot in the cardboard. Lots of flashing lights and a cool-looking "CYBERCOMPUVAC" logo on the side helps the effect.

          • I think the amount of battery required to power the transmitter long enough to make a connection and transmit data from your phone would be far greater than running the phone CPU to compute that move.

            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

        • I don't think it would not hard to port a FICS [freechess.org] client to J2ME (its one of the little projects I have on the "prob. never get round to doing"-ToDo list). But at £x per kb, it will not be a cheep game.

          • But at £x per kb, it will not be a cheep game.

            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

            • Glancing over FICS, it *seams* to send an ASCII board each turn (designed to be able to play over telnet). You might be able to change that thou.

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

      by ShamusYoung ( 528944 ) on Monday March 28, 2005 @12:30PM (#12067060) Homepage
      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.

  • 'I don't really like talking to most people' (Score:5, Insightful)

    by arcanumas ( 646807 ) on Monday March 28, 2005 @11:51AM (#12066732) Homepage
    I don't really like talking to most people

    A true geek :)

  • Are you not suppose to be working on Quake 4 or something? Don't tell me you will release Quake 4 on the phone!
    • Quake 4 is handled by Raven, not iD. Carmack should be concerned with Doom 3 patches at the moment (for example that sound problem in multiplayer) and perhaps the expansion pack.

      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...
      • If you look at the post from December 2004:

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

    by Anonymous Coward on Monday March 28, 2005 @11:53AM (#12066753)
    ..how long will it take him to color the entire screen black and call it Doom 3 for mobiles?
    • "how long will it take him to color the entire screen black and call it Doom 3 for mobiles?"

      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.

  • If I weren't for Bejeweled 2 on my Mypal A620, I'd be consuming my morning commute with Push Push on my Samsung.

  • That's gonna give the Java fanbois an aneurysm (Score:5, Interesting)

    by Anonymous Coward on Monday March 28, 2005 @11:53AM (#12066759)
    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.

    • Re:That's gonna give the Java fanbois an aneurysm (Score:4, Interesting)

      by TheRealFoxFire ( 523782 ) on Monday March 28, 2005 @12:12PM (#12066918)

      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.

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

      • Re:That's gonna give the Java fanbois an aneurysm (Score:5, Insightful)

        by jilles ( 20976 ) on Monday March 28, 2005 @12:58PM (#12067353) Homepage
        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.
        • John Carmack is one man, and a fairly intelligent programmer. But there are also several others who write programs, and you'd be naive to assume them all as talented and knowledgable about programming vulnerabilities as The Man. Normally this isn't a problem, as any program you write only affects your device. But being connected to a network changes all this. One bluetooth virus exploit unleashed during CES (probably the largest orgy of mobile devices known to man) turns that deal with Motorola to provide y

        • Re:That's gonna give the Java fanbois an aneurysm (Score:4, Informative)

          by Screaming Lunatic ( 526975 ) on Monday March 28, 2005 @04:10PM (#12069708) Homepage
          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.

          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.

        • 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 w

    • Re:That's gonna give the Java fanbois an aneurysm (Score:5, Insightful)

      by dtfinch ( 661405 ) * on Monday March 28, 2005 @12:28PM (#12067034) Journal
      4mhz was good enough for the super nintendo.

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

      • And I'm sure that if something were hardcoded to the particular model of cell phone it would be nice and fast too. But coding a mobile game in assembly would be the stupidest thing you could do. Mobile phones don't last long on the market, and newer models are released all the time. You need to be able to right a program to a platform spec such as the Java J2ME so that it will be able to run (or run with minor modifications) on the next generation of phones or on phones with different processors.

    • Apples and Oranges (Score:5, Insightful)

      by Dr. Bent ( 533421 ) <ben.int@com> on Monday March 28, 2005 @12:37PM (#12067135) Homepage
      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.
      • 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.

        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)

        by 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 fa

        • I had to "fix" our VM to ignore System.gc() if it gets called a lot.

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

        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.
    • 1. Carmack's '4.77 mhz pc' comparison is waaaay out, at least for any reasonably recent J2ME phone. Some of the phones available in Europe and Japan today (and in a couple of cases in the US also, the US market seems to be closing the gap on Europe, slowly) are an order of magnitude faster than some of the ones still shipping on US networks. And this is just phones with software JVMs.

      2. Write-once-run-anywhere: Not a problem with Java per se, more like the fault of two dozen handset manufacturers developin
      • You're right, there has been an enormous increase in J2ME execution speed as well as feature set in the recent past. I've been doing some J2ME developement some weeks back - it really is very easy to get into once you have an IDE running - and I was surprised. For instance, the popular Sony Ericsson T610 is just awful wrt to Java: it only supports the very basic MIDP1, and it's extremely slow. My own Nokia 6230 supports MIDP2 and is more than 10x as fast. But it doesn't end there, today's phones are still 2

        • Re:That's gonna give the Java fanbois an aneurysm (Score:5, Informative)

          by John Carmack ( 101025 ) on Tuesday March 29, 2005 @03:08AM (#12074071)
          I did try running that benchmark, but it won't load on the i730 (score one more for run-anywhere...).

          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 ..." comparisons from the benchmark are against purely interpreted java on the P3, which is about 1/10th the speed of a native implementation, and benchmarks that focus on expression and control operations will overestimate relative performance for applications that are array access heavy. Still, if a java app on that phone performed like a P3-100mhz, it would be pretty impressive.

          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
    • Been there, done that. Java != Java on various cellphones, there are two specs currently in usage. Midp 1.0 and Midp 2.0 Midp2.0 enforces a JIT midp 1.0 had that optional and unfortunately Midp still is/was the most widely used spec and many cellphones did not have jits in them. Newer ones have. You still will not get stellar performance, but definitely pretty much the same as on an Amiga with an 68020 processor which is not too bad given the fact that you have a low powered arm processor in the phone and l
  • you could play quake 3 with just a keypad...

  • Laugh if you want... (Score:5, Interesting)

    by dhakbar ( 783117 ) on Monday March 28, 2005 @11:58AM (#12066802)
    ... 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.
    • Well yeah, if you can get morons to continue to pay $3/month for something they no longer use, you're a success story no matter what the media.

      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)

      by Hast ( 24833 ) on Monday March 28, 2005 @12:08PM (#12066884)
      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.
      • I do remember.

        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)

        by jbolden ( 176878 ) on Monday March 28, 2005 @01:29PM (#12067721) Homepage
        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.

  • Cell Phone (Action/Adventure) Games Are Terrible (Score:4, Insightful)

    by DeckerEgo ( 520694 ) on Monday March 28, 2005 @12:00PM (#12066823) Homepage
    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.

  • The best part is... (Score:5, Insightful)

    by BW_Nuprin ( 633386 ) on Monday March 28, 2005 @01:38PM (#12067847)

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

    • ...Carmack is way over-estimating performance of most phones.

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

      But he's doing a 3D game, which puts the GBA in the exact same boat. Minus the no-direct-framebuffer-access thing.

    • Since I think his past efforts have influenced quite some companies/hardware/products, the same will apply if he will be working on mobiles.

      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.

    • BREW doesn't support threading, globals, or even static variables.

      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)

    by El_Muerte_TDS ( 592157 ) on Monday March 28, 2005 @01:39PM (#12067857) Homepage
    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]
  • As a Texan, am I the only one that noticed the error in that Carmack spells the city of Amarillo, "Armadillo?" Most people don't realize the difference.
    • 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

      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
    • Armadillo Aerospace is the name of his company and it is located in Mesquite, TX which is near Dallas. I don't think he is misspelling Amarillo.
    • 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*
  • Interesting. I hate fantasy themes in games with passion, so it's something i would love to check. Haven't seen one since the days of Fallout I/II.
    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.

  • 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

    • So are you saying that there are some secrets of J2ME technology that you need to know before you can write J2ME apps effectively? What are the secrets, and, more importantly, why are they secret?
    • I'm in the trenches, and I know the ins and outs of J2ME, and do quite well on both Java and BREW. That being said, you have to be on crack to think the current generation of J2ME phones is anything to be happy about. I currently have four makefiles to hit every target on BREW, and 30 for our J2ME builds and that is still only a fraction of the Java ports for our next game.

      There are phones that leak memory everytime you play a sound file or deallocate an Image, others where they break if you do something
  • In my day, playing on the phone meant asking random people if their refrigerator was running.
  • 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 targe
  • There really isn't wrong with Java it is just a language. There is no reason Sun can't find people to spend the time and find ways to allow Java to compete with C in terms of performance. I think this would be a good starting point for them to realize Java gaming could be a possibilty if they only spend the time to find ways to implement faster code. Hopefully Carmacks influence is enough for them to add ablility to do lower level things in Java.
  • Setting: A static old-school DnD first-person dungeon view is displayed on the mobile screen, with two Chainsaw Zombies going through a "chainsaw swipe" attack animation periodically:

    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

Slashdot Top Deals

Put your Nose to the Grindstone! -- Amalgamated Plastic Surgeons and Toolmakers, Ltd.

Close