Guest User

Untitled

a guest
Mar 6th, 2013
576
0
Never
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
text 7.38 KB | None | 0 0
  1. Hi,
  2.  
  3. my name is Mario Zechner, I'm one of the creators of libgdx [1], a crossplatform (Windows, Linux, Mac OS X, Android, HTML5/WebGL, iOS) Java game development library. I CC'ed Nathan Sweet, co-creator of libgdx.
  4.  
  5. I'm writting to add to the pool of Java developers that have a commercial intersted in JavaFX/Java SE embedded on mobile and other platforms, as per [2]. I know that you are likely not the one i have to persuade, so the following is meant as a supplement for any internal discussions you have. Here are the key points, more details in the sections below.
  6.  
  7. 1) Games do make up most of the revenue in mobile app stores [3], it's a multi-billion dollar business
  8. 2) Java/JVM can/should be a serious platform for game development, especially on mobile
  9. 3) Game developers lack a JVM and crossplatform UI toolkit on key platforms like iOS, Android, Windows Phone 8 and consoles.
  10. 4) JavaFX/Java SE embedded can fix this, please make it a reality
  11.  
  12. === (Mobile) Games are a multi-billion dollar business ===
  13. Not a lot needs to be said here, the numbers speak for themselves. Development Studios want to tap into that market, especially on mobile, using tools that are cross-platform and fast enough for games.
  14.  
  15. === Java/JVM is a serious platform for (mobile) game development ===
  16. Java's not been in use for desktop game development much. Notable, successful, exceptions to this are games by Puppy Games [4], ThreeRings [5], Jagex [6] and Mojang [7] with the breakthrough success Minecraft. Traditionally, desktop game development has been dominated by C/C++. A general "fear" of managed languages due to the initial suboptimal performance of the JVM made game studios not consider Java as a relevant platform.
  17.  
  18. This changed somewhat with the rise of mobiles, first with JavaME, and more recently with the introduction of Android. Java's been a valuable technology stack on these platforms (not getting into the politics of Java/Dalvik/Android here, that's a different story...).
  19.  
  20. With libgdx we managed to cut into this segment by providing a cross-platform Java-based solution that works on all desktop operating systems, Android, HTML5/WebGL and iOS. We are powering thousands of commercial games on Android [8], with many making it into the top grossing section. We easily trump other non-Java frameworks when it comes to adaption, and are competitive [9] with Unity [10], a popular .Net/Mono based game development tool.
  21.  
  22. Managed languages are on the rise for game development on mobile, Unity and libgdx are proof of that. Companies like Ironhide [11] use libgdx to port their games to Android and iOS, Google uses libgdx to power their augmented reality game Ingress [12], and some libgdx games are making it onto Steam [13] as well.
  23.  
  24. We attribute much of this success to a) the familiarity of Java to most developers and b) the excellent tooling and platform around the JVM, which make development less of a burden and more productive as compared to C/C++.
  25.  
  26. One of the key benefits of the JVM for libgdx is the ability to develop on the desktop for the most part, without needing to wait for slow device-deployments to finish before a tweak can be tested. Hotswaping of code allows even faster iterations, which is key to game development.
  27.  
  28. Additionally, a libgdx application is written once, and runs on all supported platforms without modification. On desktop platforms, this is due to the JVMs excellent crossplatform support, on other platforms we have to jump through a lot of hoops to get things working.
  29.  
  30. Libgdx itself is entirely OSS, licensed under Apache 2.0, as many libraries in the Java ecosystem do. Crossplatform software is hard to test, having a huge user base helps immensely to iron out device specific issues. Libgdx has ~60 individual contributors working on it. We've been ranked among the top 5 most forked [14] C projects on Github, beating native options like Cocos2D.
  31.  
  32. Wait, C projects? Yes, 36% of libgdx are written in C/C++, using JNI. And all because there is no proper JVM stack on mobile.
  33.  
  34. === Lack of JVM and cross-platform UI toolkit on key platforms like iOS, Android, Windows Phone 8 and consoles ===
  35. Contrary to the smooth ride on the desktop, we had to invest quite a bit of effort to get libgdx working on Android and iOS. And all of this can be attributed to the lack of a proper JVM on these platforms.
  36.  
  37. Android's Dalvik is a slow immitation of a JVM. The GC is primitive, resulting in extreme GC pauses, the JIT is a tracing JIT and nowhere near the capabilities of HotSpot. For this very reason, a lot of our code is written in C/C++, simply to circumnavigate all the performance issues that come with Dalvik. End users of libgdx do not deal with C/C++ and can comfortable stay in Java land.
  38.  
  39. On iOS, we use IKVM [15] to compile JVM bytecode to .Net CLR, which is then compiled to native ARM7 assembly via Xamarin.iOS [16]. Not only is this a sub-optimal technical solution, it also relies on a commercial entity. Key parts of Xamarin.iOS are not open-source, relying on such a technology stack is a gamble, especially given the volatility and size of Xamarin.
  40.  
  41. For our HTML5/WebGL target we use GWT [17] to compile Java code. Suffice it to say that this is a painfull experience, especially given the limited nature of GWT. It's not a perfect solution, but has served us well so far. We build this backend as a way to stay future proof, should HTML5 ever become a valuable technology for game development (it is not yet there).
  42.  
  43. There are also no WORA UI toolkits that could make development less of a pain. Some attempts like PhoneGap are laudable, but suffer from poor performance and a not-native look. Games do rely on native UI for parts of their functionality, like In-App purchase dialogs, integration of social media, login masks, chat functionality and so on. Having a cross-platform solution for this would keep a lot of game developers from ripping their hair out.
  44.  
  45. === JavaFX/Java SE embedded can fix this ===
  46. Java SE/JavaFX embedded could solve these issues (save for HTML5, which is an imature technology for games anyways) and make Java and the JVM a potentially leading technology stack in (mobile) game development. No more hoops and excellent tooling and performance, as we are used to on the enterprise side of things.
  47.  
  48. It is a quick win for Oracle in my opinion, an easy way to gain traction on mobile and other new platforms. There's simply no reason not to do it.
  49.  
  50. Richard, i want to thank you and your team for all the hard work you've put in. We have literally thousands of developers, with business interests, eagerly waiting for some good news from Oracle.
  51.  
  52. With kind regards,
  53. Mario Zechner
  54.  
  55. [1] http://libgdx.badlogicgames.com
  56. [2] https://forums.oracle.com/forums/thread.jspa?threadID=2448461&start=15&tstart=0
  57. [3] http://www.gamesindustry.biz/articles/2012-12-14-games-dominate-app-store-revenue-in-2012
  58. [4] http://www.puppygames.net/
  59. [5] https://www.threerings.net/
  60. [6] http://www.runescape.com/
  61. [7] http://mojang.com/
  62. [8] http://www.appbrain.com/stats/libraries/details/libgdx/libgdx
  63. [9] http://www.appbrain.com/stats/libraries/dev
  64. [10] http://unity3d.com/
  65. [11] https://itunes.apple.com/gb/app/clash-of-the-olympians/id590049663?mt=8
  66. [12] https://play.google.com/store/apps/details?id=com.nianticproject.ingress
  67. [13] http://store.steampowered.com/app/207710
  68. [14] https://github.com/languages/C
  69. [15] http://www.ikvm.net/
  70. [16] http://xamarin.com/monotouch
  71. [17] https://developers.google.com/web-toolkit
Advertisement
Add Comment
Please, Sign In to add comment