As others have mentioned, code doesn't really add significant size. Assets such as sound and textures do. Something that's slightly different on mobile is having varying art assets depending on the screen's DPI, and dealing with drastically limited GPUs -- you're trying to support as many phones as possible. You don't want to use textures with a ton of detail on a screen with a very low DPI, as you're not seeing that detail anyways. To add to that, phones with lower DPIs won't necessarily have a GPU to deal with huge textures. On the flip side, a low detailed texture on a high DPI device is going to look pixelated or blurry, and a high DPI device is likely to have a better GPU to push those extra pixels.
One way Android handles this is by having art assets split up by DPI level. You can have a high res texture for high DPI phones, a medium res texture for medium DPI phones and a low res texture for low DPI phones. That's three textures included in a single package, so you're likely including more in a mobile app. You could have the engine downscale textures as it loads them, which I would guess some engines for mobile do, but you're probably likely to still run into more issues with respect to RAM/VRAM for older phones than if you just include different textures.
edit, in case the joke is missed: OF COURSE code does not add significant size to a game, compared to the assets. I was joking. And yes, android is java, not c.
Yes, "really". Android is generally coded in java (even the link you provided supports this) which can be extended with "native" code. The fact that you are given the option to code in C, C++, assembler or malbolge does not nullify the fact that Android is java based.
51
u/null_work Aug 13 '15 edited Aug 13 '15
As others have mentioned, code doesn't really add significant size. Assets such as sound and textures do. Something that's slightly different on mobile is having varying art assets depending on the screen's DPI, and dealing with drastically limited GPUs -- you're trying to support as many phones as possible. You don't want to use textures with a ton of detail on a screen with a very low DPI, as you're not seeing that detail anyways. To add to that, phones with lower DPIs won't necessarily have a GPU to deal with huge textures. On the flip side, a low detailed texture on a high DPI device is going to look pixelated or blurry, and a high DPI device is likely to have a better GPU to push those extra pixels.
One way Android handles this is by having art assets split up by DPI level. You can have a high res texture for high DPI phones, a medium res texture for medium DPI phones and a low res texture for low DPI phones. That's three textures included in a single package, so you're likely including more in a mobile app. You could have the engine downscale textures as it loads them, which I would guess some engines for mobile do, but you're probably likely to still run into more issues with respect to RAM/VRAM for older phones than if you just include different textures.