Slashdot Mirror
John Carmack Not Enthused About Android Marketplace
An anonymous reader writes "During an in-depth and informative interview, Doom creator and id Software co-founder John Carmack opines on iOS game development, the economics of mobile development vs. console development, why mobile games lend themselves to more risk-taking and greater creativity, and finally, why he's not too keen on the Android Marketplace as a money-making machine. '...I'm honestly still a little scared of the support burden and the effort that it's going to take for our products, which are very graphics-intensive.'"
Carmack's Rage for iOS has been done alright, now I am eager to see whether it is even possible to port such a demanding 3D game to Android. There are lots of obstacles like the crippled NDK, hardware fragmentation, poor native audio support and boatload of other issues. If Carmack is taking a stab at it then I am really excited see the results. Also, pity the WP7 devices' capable hardware is DOA for such a development due to lack of native code support.
Google, are you listening? .. DO SOMETHING ABOUT THIS !!!!
There should be no reason for to be grumbling about things like this - I would at least hope Google should be listening to when people like John Carmack have something to say. Particularly when there is so much of an opportunity here when other Android devices start hitting the shelves eg: GoogleTV may be a much more viable gaming platform. I say Fix this Meme - as soon as possible - a little brown nosing might be in order.
N.
Electronic Music Made Using Linux http://soundcloud.com/polyp
John Carmack's head would not only be on it, it would have the highest polygon count.
Umm, what about Shigeru Miyamoto?
Ahh, wait, no, his head would be built out of sprites.
You got it, but because the rest of /. is too busy doing submission compatibility testing on their Androids.
From what I could understand from TFA, the problem is with the limitations of the Marketplace, not Android itself.
If a distribution service with support for games' specific problems is needed, wouldn't there be a market opportunity in developing a Steam-like app with its own distribution service and game library management?
The only problem I can see is that apps can't install other apps, but they can download the APK and call the installer for it, so it might not be that problematic...
Dilbert RSS feed
That which apply to both Android and iPhone.
In that touch screen interfaces are a burden to game design.
"You're somewhat hampered by the touch interface—there's a lot of places where tactile controls really are better—but you can definitely do a lot."
Its possible to get creative - but it doesnt matter how many polygons NG smartphones can push - a touch screen is not a good interface for Doom 3 for example.
Electronic Music Made Using Linux http://soundcloud.com/polyp
For games that need more performance than a Java-like environment can offer ...
iOS has two advantages. A single native binary can target all iPhone, iPod touch and iPad devices. There is a single digital distribution channel, the App Store.
With Android handset/tablet manufacturers are free to use different CPUs, GPU, etc. They may also be using different versions of Android. Different versions of the game may be necessary for the different permutations. This complicates the coding and testing. Having to deal with manufacturer specific stores might add to the overhead. These sort of problems are the "cost" of having an open platform like Android and there is not really anything Google can do about it.
High level languages need not be slower than low level languages?
Not that I believe that myself. I am actually a game developer who wishes to remain anonymous. I code strictly in native code. But is there even Android hardware that's not ARM based? I get that Google wants to keep the platform open (in both hardware and software). But it's really not that big of a deal to compile your code twice. I tend to code for x86 and PPC both all the time. The only difference in a well designed codebase is the extra compile time. Yes, it does complicate the cost of testing, but is it really any worse than the PC nightmare of having to code for nVidia, ATi, and Intel? (OpenGL 2, OpenGL 3, DX9, DX10)?
John Carmack talking in real life kind of reminds me of Adam Sandlers excited southerner without the stuttering.
Intel based devices are on their way. There are already two versions of OpenGL ES. And things will only get more fragmented over time. Hence the lower enthusiasm.
High level languages need not be slower than low level languages?
Not that I believe that myself.
Although in theory low level languages can always be faster, the real-world situation is that a high level language with good optimisation is likely to be faster than the low level language because tweaking of the low-level code is limited by cost and timescale constraints.
Quidnam Latine loqui modo coepi?
The issue is that if the platform is too open, none of the optional stuff will ever be supported, and thus you are only developing for the most common denominator of hardware. You see this all the time on game consoles and their accessories. They only support the controller that came with the system.
This is one of the problems prevalent with the non-Apple smart phones. Name one phone that I can copy "my data" , games and all from and have it work on a new device from a different manufacturer. Or even the same manufacturer. Good god, I'll never touch a LG, Samsung, Sony-Ericcson, or Motorola phone, ever.
but! say the words "DOOM and QUAKE!" to a 1,000 random iphoners and 1,000 random androiders and see how many insta-buys he gets from each group.
it'd be worth the pain mr carmack.
In my experience it's the other way around. In theory managed languages (stuff like C# and Java) can be better optimized since you have more information at runtime but in practice I've never seen any useful code written in those languages outperform similar stuff in C or C++.
Mada mada dane.
High level languages make design decisions that limit optimization potential. See: Java's garbage collection, array bounds checking, lack of stack allocation, enforced type safety, lack of unsigned types...
You can set what android version you are targeting in the market, I also belive that the latest version of android comes with a minimum hardware spec,
if (!signature) { throw std::runtime_error("No sig!"); }
It's the Computer vs Console battle all over again. In the end, someone came out with an API for games (Direct3d), and therefore the problem was minimized quite a lot. As handheld devices become more powerful, someone will introduce an API that makes game programming much easier for Android devices.
By "lower level" I was thinking of the native code that the message I replied to mentioned. Yes, the fastest is probably a couple of steps behind the leading edge. C used to be consistently slower than assembly. By the time C optimisers fixed that, C++ was out and everybody was complaining about the performance drag of exceptions. Now that C++ is pretty much up to speed we have managed code which, yes, presents a performance drag. At the moment. Expect that to be fixed in a couple of years, but expect the latest languages then to have something else that hits performance.
Quidnam Latine loqui modo coepi?
True, although Java is a particularly extreme example. Nothing on that list is a necessary feature of a high-level language except arguably garbage collection, or at least some form prevention of memory leaks. And the assembly programmer should be dealing with that too.
Quidnam Latine loqui modo coepi?
Download procedures that generate the textures. Then generate the textures on the target machine. This results in several orders of magnitude less bandwidth requirements.
Why do you assume Google cares? You are not their customer (unlike Apple). The carrier is Google's customer. You are just eyeballs for advertising.
Google wins when every crappy phone has Android on it, regardless of the end user's experience. They don't need quality, they need quantity. Being able to use different GPUs and CPUs is critical because that is why you can find Android phones for 1/4 the cost of the high end smart phones.
Since 1992, John Carmack hasn't been so keen on anything, regardless of platform.
iOS, Android, what's the difference: we'll never see Episode 7: The Universe is Toast! :(
And C++ is still getting more optimizations and continues to lengthen the performance gap. With the new C++0x and rvalue references, the resource management is getting even better. If the compiled code is already optimized with such detail, I'm not aware of what a runtime environment would be able to offer that a good compiler didn't already consider. And all the talk about garbage collection ends up being less than impressive when using the STL already handles it for you. Runtime can offer a little more protection in the event of poorly written code, but that's just another performance hit.
Fear is the mind killer.
Is Carmack even relevant in the game biz anymore, or is he a dinosaur fossil has-been that ought to spend his time playing with rockets instead?
High level languages need not be slower than low level languages?
Not that I believe that myself.
Although in theory low level languages can always be faster, the real-world situation is that a high level language with good optimisation is likely to be faster than the low level language because tweaking of the low-level code is limited by cost and timescale constraints.
These companies are paying that cost and spending that time though, and they have a lot of experience at it
"I am actually a game developer who wishes to remain anonymous. I code strictly in native code. "
Really you code in straight x86 assembly language?
You don't use any game engines?
Do you really?
"I tend to code for x86 and PPC both all the time. The only difference in a well designed codebase is the extra compile time. "
I guess not.
You probably code in c or c++ those are not low level languages. C++ sure isn't. I have heard c called a mid level language but low level means assembly as does native.
So now that we have established that you code in a higher level language what it comes down to is the compiler.
Here Android does have an issue. The java system on it has not in the past been all that optimized. I am not even sure that it uses a JIT compiler.
Your statment proves that a high level language need not be slower than a low level one. It all comes down to a problem of code optimization and in this case Android has been at a real disadvantage. If Google can get a really good JIT compiler added to Android it will really help them performance wise.
BTW just a bit of information on code optimization. C and C++ are terrible languages to try and do code optimization for. The syntax is so flexible that it is actually a rather difficult problem to write a good optimizer for them. That is one of the reasons that even today you still see a lot of HPC apps written in FORTRAN. FORTRAN really optimizes very well and that fact combined with the large number of really good HPC legacy libraries and software means that it still is popular in the HPC community.
See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
That's why every time we see Rage, it's being played with Xbox controllers.
By "Xbox controllers", did you mean original Xbox controllers (highly unlikely) or Xbox 360 controllers? Wired Xbox 360 controllers work with PCs out of the box, except games that haven't been updated to support XInput along with DirectInput can't read the sum of LT and RT, only their difference.
The hardware of latest iPhone is pretty similar to many high end android devices, in fact some Android devices actually have slightly higher specs in terms of horsepower.
But what Android device is comparable to the iPod touch 4? The more powerful Android phones typically aren't available in a non-cell-phone version without 3G and without a price tag set with the expectation of a carrier subsidy in mind.
Hell even the bottom of the line AMD machines have nice Radeon IGPs that play games just fine.
So can you recommend a make and model of bottom-of-the-line AMD machine in a slimline form factor that I can in turn recommend to friends and family? Google slim AMD PC pulled up this eMachines product as the first result; is it any good? Or this Compaq?
With the new C++0x
How long until an application targeting both GCC and Microsoft Visual C++ can use C++0x features?
Runtime can offer a little more protection in the event of poorly written code
Worse yet, code written by third parties. As I understand it, sandboxing of native code isn't yet to the point where one can just load in a DLL and specify fine-grained privileges on what it may access, but I'd love to be proven wrong.
low level means assembly as does native.
I thought native meant languages intended for an unmanaged environment, such as C or standard C++, as opposed to languages intended for a managed environment, such as Java, C#, Python, VB.net, or the verifiably type-safe version of C++/CLI.
The carrier is Google's customer.
If Google wants more customers, then why hasn't it made more of an effort to expand Android past phones? Google could compete with iPod touch by allowing access to its Market from portable media players such as those made by Archos.
but right now the costs of maintaining our own servers and doing our own marketing for our desktop app accounts for 40% of the costs.
App Store doesn't do all the marketing for you. Helping users find and choose your app from among the myriads of apps in the App Store is your job. If promoting your application with advertisements is 10% of the costs, then you're breaking even with Apple's cut.
if a Steam like app was developed, you could have one distribution point for all the mobile platforms except the iPhone/Pad, because Apple wouldn't allow it (it's competition to their store).
Not really. Like Apple, Google chooses not to carry Market alternatives to the store. So the user would have to turn on "Unknown sources" and install a Market alternative through an APK, but AT&T has customized the firmware on its Android phones, such as Motorola Backflip and HTC Aria, to keep "Unknown sources" permanently off.
touch screen interfaces are a burden to game design
Any more than gamepads "are a burden to game design" on consoles? Or small screens that only one person can comfortably fit around at a time "are a burden to game design" on desktop PCs? Different platforms have different favorite genres.
Android's biggest strength is also its biggest weakness - Java.
No sig today...
Have you completely missed all the Android-based tablets, or the Google TV?
Android is all over the place in embedded consumer systems.
Although in theory low level languages can always be faster, the real-world situation is that a high level language with good optimisation is likely to be faster than the low level language because tweaking of the low-level code is limited by cost and timescale constraints.
No. In the real world c/c++ is usually faster than assembly because most programmer are poor assembly language programmers. However good assembly language programmers routinely beat the compiler. I've added a couple of fps to a game by identifying a couple of key points in the code via profiling and replacing c/c++ code with about 100 lines of assembly. Its not simply a matter of optimizing the scheduling of instructions and memory access, its also the fact that the programmer has more information about what is going on than the compiler and can leverage that.
Not that I mind the negative Karma, but why on earth is this Off Topic? It's a response to a First Post (that *got* First Post), contextualized to the subject (referencing JCs fear of slipping back to the quagmire of feature phones with compatibility testing issues galore).
Or, to put it another way for the moderator in question......"wooosh"!
Uh, he specifically mentions fragmentation:
"Even in the old days of the feature phone world, we always had EA Mobile or JAMDAT to build the 300 or 400 SKUs that they had for all the worldwide feature phone splits that we had from our four base versions."
Steam for Android wouldn't magically solve that.
Have you completely missed all the Android-based tablets
The two Best Buy stores in my home town appear to have "completely missed all the Android-based tablets". Each store has the Archos 7 and one other 7" tablet, and that's it. No Archos 5, no Archos 43, and those that are there don't have official access to Android Market but instead have AppsLib, which has a far smaller selection. The fact that telephones have Android Market but tablets have AppsLib is part of the fragmentation that Mr. Carmack complains about. And as for buying an Archos tablet online before I have tried it, how do I know that I will like something so that I'm not out return shipping + 15% restocking fee?
I just wanted to point out that Android introduced a JIT compiler in Froyo (2.2). That and it has the Native Development Kit for developing using C/C++ which has been greatly expanded and improved upon in Android 2.3.
I own an Android phone and I love it but I'm not sure I could be bothered to develop for it. You can't guarantee what the user will have and you can't even rely on the store to show your product in the best light.
For instance, there was some fuss being made over Angry Birds. I decide to check it out. It shows up in my app market, there are no limits listed so I download it. It fails. No error message than it's not gonna happen. Was it a bad net connection or was my phone not up to it? Fuck if I know.
Google maps was updated and crashing constantly (like upon boot up) and as long as it went on I suspect it was only happening to older versions like mine (1.6). Another app bricked my Android and considering I mainly only use Google made apps and connect bot it's not like I'm downloading shit.
The hardware guys aren't willing to update my software and Google isn't doing enough to guarantee I only see apps I can run. That's shit and something like Rage would cause such a hassle for ID, imo, so I wouldn't bother if I were them.
Nokia smartphone to nokia smartphone, everything transfers just fine.
Interesting you should mention this... Carmack decided to go with OpenGL over Direct3d.
Thanks that is why I said I wasn't sure. I know that early versions did not use the JIT.
I am not a fan of the NDK concept. It seems to be a band-aid for short comings in the the Java system and now you need to worry about differences in the different CPUs.
Done correctly the NDK would generate fat binaries for the different levels of ARM. Maybe it does but I see versions of some of the NDK programs in the app store.
One should not have to know what ISA your phone supports.
See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
You don't have to. You can either compile to the lowest common denominator or you can compile for each available version and package together (kinda like when you download software and they come with the Windows, Mac, and Linux versions all together). When your code calls the System.loadLibrary("package") command it will load the appropriate .so file for the ISA you are running. Compiling for multiple ISA's is as easy as adding them to a text file list in your build file. =)
RockPlayer had different versions for each processor until the dev stopped being a dumbass and packaged them together.
if you aren't afraid to DIY [...] and don't mind DIY
Ultimately, I'm trying to recommend a PC for playing a specific PC game. It doesn't have to be absolutely tiny like a Mac mini or a Wii, but I'd prefer not much bigger than an Xbox 360. Most of the PCs with that kind of form factor that I've seen in Best Buy have had Intel GMA (Graphics My You-Know-What). Were I to go DIY, I'd have to build each box, sell it online, ship it to buyers (or give Amazon its cut for fulfillment), and handle any tech support issues myself.
without knowing the game it is just a shot in the dark.
The game currently exists only as design documents; I'm asking this as part of my market research to complete my business plan. But it will allow up to four players to play at once, and it won't be too much more graphically complex than WoW. Some scenes will use a split screen, but others will show all players in the same room in much the same manner as Bomberman or Street Fighter. I am aware of three options for such a game: running it on a console, running it on four PCs in one house, running it on four PCs in different houses, or running it on one PC.
He can be enthusiastic, but he cannot be "enthused".
"But but but it's in the dictionary, LLOOLLOLO!"
Most dictionaries are written by descriptivists who record how language is used, even if it is wrong.
Utilizing the synergization of benchmark e-solutions to pre-workaround action items!
Don't they call that OpenGL?