5 ms·

Android is Java and the SDK is but the NDK (native) allows C/C++ since Android 2.3. Most games are built using that now with Java wrappers where needed for UI

Android is Java and the SDK is but the NDK (native) allows C/C++ since Android 2.3. Most games are built using that now with Java wrappers where needed for UI if any needed. Most are straight C/C++ using OpenGL ES. Also tools like Unity convert to C/C++/Java for Android and C/C++/Objective-C for Apple/iOS. But yes you can do a game in Java since is will be Android and the SDK supports it. Most games though are C/C++ for porting reasons, that can get you desktop and all mobile platforms. Windows Phone 8 also recently allows native finally (they really messed up not allowing this in Windows Phone 7 and lost lots of market share due to difficult ports).

pjmlp 13y ago
However C and C++ developers are forced to either reach for a middleware solution, or spend quite some time wrapping Android APIs. For anything outside graphics, sound, hardware sensors and sockets wrapping Java APIs via JNI is required. The new Games API released at this year's Google IO is Java only and the bug request for providing a NDK version of it was closed. Also at the same Google IO, Google was advocating using Renderscript for CPU intensive tasks. The NDK bug tracker is full of broken code generation issues and the move for Android Studio still does not offer a path for C and C++ developers. Developers targeting iOS, WP8 and Blackberry have a much better vendor support in terms of C and C++ tooling.
- drawkbox 13y ago
  True but have you tried to port an engine to run on consoles Xbox360 or PS3? 10x worse with special hardware hooks, crappy apis, older apis (dx9, custom opengl), strange requirements for async and networking and a host of other problems including compliance + approval costs, devkits, and platform lock-in. This all leads to insurmountable costs and lessens the chance of successful games. PS4 has solved lots of this moving to more standard architecture (http://www.gamasutra.com/view/news/189368/Inside_the_PlayStation_4_with_Mark_Cerny.php http://www.gamasutra.com/view/news/189368/Inside_the_PlaySta...) but Xbox you still have to port in DirectX/3d and they all have strange requirements like requiring a publisher in this day and age of self-publishing and open app stores. Many times these wrappers try to get developers locked into engines and result in older, crappier outcomes. Leading to situations like recreating the string class, threading libraries, graphics libraries, memory managers etc 15 times. All of that focus on tech takes away from gameplay development. So I agree middleware like Unity allow companies to focus on making games rather than building the same tech everyone else is building on each iteration and years of development hours. Building in C/C++ with wrappers is still the way to go and the most portable. Unity uses this underneath, cocos2d-x also have ports of tech, so many tools to help with this now instead of going full custom although if you do go custom it is still C/C++ core, with wrappers and platform specific code for file handling, threads, graphics, audio etc etc.
  - pjmlp 13y ago
    I have had a foot in the games industry since a long time, being a IGDA member and attending a couple GDCE conferences, but never managed to really get in. So I do know some stuff how the industry works, but your comment provided valuable information. Thanks. As I do value my private time, I might never get in anyway. Currently for my hobby game programming, cocos2d-x is the way to go.
  - pandaman 13y ago
    >True but have you tried to port an engine to run on consoles Xbox360 or PS3? 10x worse with special hardware hooks, crappy apis, older apis (dx9, custom opengl) I have, have you? Compared to the zoo of vendors and drivers on PC - console APIs are especially streamlined and beautiful. When porting from PC to 360 you essentially remove code or replace kludgy procedures with few lines. PS3's API is nothing like PC (no, it's not "custom OpenGL") so it takes a bit more time but, nevertheless, fixed HW platform beats generic APIs any day.
    - drawkbox 13y ago
      Yes indeed I have worked on 2 but they were the longest, most un-rewarding experiences I have had. You can read my bio and probably figure out which games. Web, mobile and desktop games have been more fun and had less hurdles and were much cheaper to get launched. No TRCs, SPUs, devkits, rough/costly approvals that were hard to share in a game company and more (we had 3 PS3 and 2 Xbox devkits and lots of developers, so it was a pain point for testing). PSGL/libGCM and an obscured version of OpenGL ES 1.0 is indeed a 'custom opengl' on PS3. And yes XBox360 is stuck on dx9 version. I have to say complaining about custom platforms then backing consoles is a strange vector to be on though. Have you made mobile/web/desktop games after console and really had a harder time? Also, if you were running a small studio which would you develop for considering the entry cost on console runs upwards of 50-100k just to get started? And you need to have a publisher on both platforms that take additional revenues since you won't be able to launch 4+ titles a year to qualify as a publisher on the consoles. My guess is you'd be developing for open markets and platforms like mobile, web and PC. You admit it takes more time, well I have yet to see a console game take less than a year minimum and meanwhile the longest mobile timeline has been 3-4 months. If you have 3-4 years of development would you rather launch 2-3 console games if that or 10-15 mobile/web/desktop titles with same resources? The risk on console games/markets today is immense. Mobile, web and desktop games are extremely more approachable than console development and extremely more affordable (leading to more time spent on gameplay and fun). Even Mark Cerny who designed the PS4 acknowledged this and went with more x86 architecture and shared memory to get rid of the complaints of difficulty when building for the PS3 (http://www.gamasutra.com/view/feature/191007/inside_the_playstation_4_with_mark_.php http://www.gamasutra.com/view/feature/191007/inside_the_play...). PS4 will also allow self-publishing which will make it more affordable. XBone, well, they'll support publishers over developers it seems.
- mark_l_watson 13y ago
  I used NDK yesterday, but just playing around and having fun: used mocl Common Lisp example. Compiled Common Lisp to C and then compiled with NDK. Imported project into Android Studio. The process was smooth, but not quite agile since kicking off a build using mocl and NDK might take 30 seconds.

pjmlp 13y ago

However C and C++ developers are forced to either reach for a middleware solution, or spend quite some time wrapping Android APIs. For anything outside graphics, sound, hardware sensors and sockets wrapping Java APIs via JNI is required. The new Games API released at this year's Google IO is Java only and the bug request for providing a NDK version of it was closed. Also at the same Google IO, Google was advocating using Renderscript for CPU intensive tasks. The NDK bug tracker is full of broken code generation issues and the move for Android Studio still does not offer a path for C and C++ developers. Developers targeting iOS, WP8 and Blackberry have a much better vendor support in terms of C and C++ tooling.

drawkbox 13y ago
True but have you tried to port an engine to run on consoles Xbox360 or PS3? 10x worse with special hardware hooks, crappy apis, older apis (dx9, custom opengl), strange requirements for async and networking and a host of other problems including compliance + approval costs, devkits, and platform lock-in. This all leads to insurmountable costs and lessens the chance of successful games. PS4 has solved lots of this moving to more standard architecture (http://www.gamasutra.com/view/news/189368/Inside_the_PlayStation_4_with_Mark_Cerny.php http://www.gamasutra.com/view/news/189368/Inside_the_PlaySta...) but Xbox you still have to port in DirectX/3d and they all have strange requirements like requiring a publisher in this day and age of self-publishing and open app stores. Many times these wrappers try to get developers locked into engines and result in older, crappier outcomes. Leading to situations like recreating the string class, threading libraries, graphics libraries, memory managers etc 15 times. All of that focus on tech takes away from gameplay development. So I agree middleware like Unity allow companies to focus on making games rather than building the same tech everyone else is building on each iteration and years of development hours. Building in C/C++ with wrappers is still the way to go and the most portable. Unity uses this underneath, cocos2d-x also have ports of tech, so many tools to help with this now instead of going full custom although if you do go custom it is still C/C++ core, with wrappers and platform specific code for file handling, threads, graphics, audio etc etc.
- pjmlp 13y ago
  I have had a foot in the games industry since a long time, being a IGDA member and attending a couple GDCE conferences, but never managed to really get in. So I do know some stuff how the industry works, but your comment provided valuable information. Thanks. As I do value my private time, I might never get in anyway. Currently for my hobby game programming, cocos2d-x is the way to go.
- pandaman 13y ago
  >True but have you tried to port an engine to run on consoles Xbox360 or PS3? 10x worse with special hardware hooks, crappy apis, older apis (dx9, custom opengl) I have, have you? Compared to the zoo of vendors and drivers on PC - console APIs are especially streamlined and beautiful. When porting from PC to 360 you essentially remove code or replace kludgy procedures with few lines. PS3's API is nothing like PC (no, it's not "custom OpenGL") so it takes a bit more time but, nevertheless, fixed HW platform beats generic APIs any day.
  - drawkbox 13y ago
    Yes indeed I have worked on 2 but they were the longest, most un-rewarding experiences I have had. You can read my bio and probably figure out which games. Web, mobile and desktop games have been more fun and had less hurdles and were much cheaper to get launched. No TRCs, SPUs, devkits, rough/costly approvals that were hard to share in a game company and more (we had 3 PS3 and 2 Xbox devkits and lots of developers, so it was a pain point for testing). PSGL/libGCM and an obscured version of OpenGL ES 1.0 is indeed a 'custom opengl' on PS3. And yes XBox360 is stuck on dx9 version. I have to say complaining about custom platforms then backing consoles is a strange vector to be on though. Have you made mobile/web/desktop games after console and really had a harder time? Also, if you were running a small studio which would you develop for considering the entry cost on console runs upwards of 50-100k just to get started? And you need to have a publisher on both platforms that take additional revenues since you won't be able to launch 4+ titles a year to qualify as a publisher on the consoles. My guess is you'd be developing for open markets and platforms like mobile, web and PC. You admit it takes more time, well I have yet to see a console game take less than a year minimum and meanwhile the longest mobile timeline has been 3-4 months. If you have 3-4 years of development would you rather launch 2-3 console games if that or 10-15 mobile/web/desktop titles with same resources? The risk on console games/markets today is immense. Mobile, web and desktop games are extremely more approachable than console development and extremely more affordable (leading to more time spent on gameplay and fun). Even Mark Cerny who designed the PS4 acknowledged this and went with more x86 architecture and shared memory to get rid of the complaints of difficulty when building for the PS3 (http://www.gamasutra.com/view/feature/191007/inside_the_playstation_4_with_mark_.php http://www.gamasutra.com/view/feature/191007/inside_the_play...). PS4 will also allow self-publishing which will make it more affordable. XBone, well, they'll support publishers over developers it seems.
mark_l_watson 13y ago
I used NDK yesterday, but just playing around and having fun: used mocl Common Lisp example. Compiled Common Lisp to C and then compiled with NDK. Imported project into Android Studio. The process was smooth, but not quite agile since kicking off a build using mocl and NDK might take 30 seconds.