The JVM – a viable platform for (mobile) games?

This post is about the technical aspects of crossplatform game development. For an excellent read on the design aspect, read Kev Glass’ post

The last few weeks were interesting. I’ve been contemplating where to take libgdx and my personal endevours next. Our struggle to bring libgdx to platforms like iOS and HTML5/WebGL made me think about whether the JVM is a viable platform for what i’m spending most of my free time on.

Managed languages, Mono and Unity

Managed languages seem to be on the rise for game development, Unity has shown us that. Unity is based on Mono (.Net on Windows), the same thing we use to target iOS, and deploys to desktops, Android, iOS, Xbox360, PS3, Wii U. For the web they have a custom plugin, and they also offer a Flash backend (though i heard from an insider, that it’s not quite there yet). Each platform comes with an additional license cost of course.

I’ve been playing around with Unity for quite a bit over the last few weeks, prototyping a few things, diving through their entire API etc. so i can get a feeling for what it does well and what it doesn’t do well. Procedural generation seems to kill any benefits you get from the editor (let me use a script to populate my scene!), you don’t have a lot of control regarding memory managment, object update order, and other low-level things you need to be able to tune if you work on mobile. Interestingly enough, Unity actually recommends not using quite a few of its features when working on mobile, and instead rolling your own manually. This makes sense, but if you are supposed to handroll a lot of things, then you have to ask yourself at what point it doesn’t make sense to use Unity anymore. Also, you will be confined to Unity’s runtime API when rolling your own solutions, without access to the underlying implementation, which might complicate things further.

Regardless, Unity is nice. A metric ton of successfull games on mobile have proven it to be an excellent tool for game development. It’s definitely worth checking out.

If i thought it was the end-all be all of game development, i wouldn’t spent my time on libgdx, so excuse my little stab at it above. I’m also under no delusion that libgdx can approach Unity in terms of features. Our goals are different, we want to provide a flexible, modifieable framework, not a full fledged engine.

So, an engine based on a managed runtime successfully snatched a large portion of mobile gaming. That’s especially interesting as any old game dev with experience would have told you that that’s a silly idea on such restricted devices (including myself). You don’t hear any such voices though, nobody questions Mono’s usefullness on those platforms, even if it shares most “unfit for games” properties with the JVM: a GC (erhmagerd, micro lag), memory overhead (less so if you can exploit the better primitive datatype support in the CLR), and all those other things people usually point to when they dismiss the JVM as a game development environment.

Mono as a runtime has one clear advantage at the moment: it runs pretty much everywhere.

Who’s to say that motivated entrepreneurs or maybe even OSS couldn’t build an alternative to Unity on the JVM if it catches up in terms of portability. And for many games, solutions like libgdx, PlayN, or jMonkeyEngine are more than sufficient.

What about HTML5 on Mobile?

I’m not ruling it out. After all, my crazy mind proposes the JVM as a potential solution. At the moment, “HTML5” doesn’t seem to be there yet. On iOS you don’t get a JIT JavaScript VM (you can get V8 to JIT on Android), WebGL is in its infancy, especially on mobile, Web audio even more so. On the desktop, Chrome’s and Firefox’ adoption help spreading WebGL around, and there’s quite a few interesting projects targeting that platform, like three.js. On mobile you’ll have to create bindings to native alternatives, getting rid of the DOM, in which case you are just using JavaScript as a scripting layer, and a slow one at that at least on iOS.

JavaScript VMs only know one thing: JavaScript. There are amazing projects like emscripten or mandreel that allow you to compile C/C++ (or most LLVM output) to plain JavaScript, with quite good performance. Mozilla has recently put forward asm.js, kind of like an assembly language to get non-Javascript languages on JavaScript VMs. The compiler geek in me is super excited about this, the software engineer has a weird, uncomfortable feeling in his guts. In any case, i’ve seen crazier things, and if it works, more power to them. For this to have any kind of acceptable performance, you need a JIT VM though. There are also other options like CoffeScript, Dart or TypeScript, which have received some attention in the web community.

Regardless of my opinion on HTML5, you can target it via our GWT-based backend (provided the browser supports WebGL).

What about Corona, Gamemaker, …

I’m frankly surprised that people shell out that much money for something like Corona. The development environment is horrible, and support does not seem to be their biggest strength. It promises super easy game development (“look, even kids can do it”), but as soon as you hit a roadblock, you are on your own. Unless you own the entreprise edition of course. Quiet honestly, if you have that kind of money, spent it on Unity.

Frankly, i was considering to replicate their API on top of libgdx, slap a scripting layer on it and put it up on their forums for free. We have quite a few refugees from the Corona camp, i guess with something like that we could get quite a few more…

The JVM, a better option?

In terms of portability, the JVM is not a better option at the moment, compared to Mono. It can get you on all desktop platforms (and Steam, Desura etc.), and on things like the Raspberry Pi, but that’s where it ends. There’s JavaME and Java SE embedded, but we can safely ignore those as they do not target any of the platforms game devs are interested in.

In terms of performance, i didn’t bother to come up with any contrived benchmark results. Fact of the matter is, that both Mono and the JVM are likely to be sufficiently fast for most games. I would assume that the decades of man power that went into HotSpots JIT (not relevant if the OS doesn’t allow setting memory pages to executable) and GC would probably trump Mono, but I can not substantiate this with benchmarks. Let’s assume they are even. If you need more performance you can always drop down to native code on both (it’s easier in C# land with p/invoke, not sure how the marshalling overhead compares to the JVM’s).

Where i personally think the JVM shines is its tooling. Compared to Eclipse, IntelliJ or even Netbeans, MonoDevelop just doesn’t cut it. One could argue that there’s also Visual Studio, but that’s confined to Microsoft land. IDEs may not be everyone’s cup of tea of course, looking at you crazy VIM/Emacs guys. On top of that, you have a huge set of instrumentation and profiling options, which are relevant to game development as well. Code hotswapping, facilitated by IDEs such as Eclipse, or even better, JRebel, can totally change the way you work on your games. Things start to feel as lightweight as in dynamic languages, and you can tweak everything at run-time, to your heart’s content.

Another area where the JVM has benefits over Mono is the vast amount of proven, stable 3rd party libraries. If you have a problem, you can be pretty sure that there’s at least one solution in Java land, maybe even an established Apache project.

The JVM is still a force on the server-side, which has become more important for games with the social game hype. Many studios already rely on the JVM server-side, being able to reuse some of that code on the client side is a nice-to-have. Besides your usual database and REST stuff, the JVM hosts many solutions that can help you with all the data a successful social game can generate. Hadoop and all its subprojects help with data warehousing and analysis. Twitter Storm can help with any real-time calculations you need to perform. Both projects allow usage from other languages, e.g. via Hadoop’s streaming API, or Storms thrift protocol, but JVM languages are first class citizens for them.

Finally, and i think this is one of the biggest arguments for the JVM, there are a metric ton of languages other than Java for every taste. For statically typed language friends, there’s Scala, Kotlin or Xtend. In the land of dynamic typing you have JRuby, JPython, Groovy, Nashorn and many more. For a more extensive list of languages on the JVM see this wiki article. Mono has a similar site. Overall, the communities around the major JVM languages seem a lot more vibrant, and fully integrated into the bigger JVM ecosystem. Many of the JVM languages are also making big waves in production, especially Scala.

For me, the JVM ecosystem seems a lot more mature and provides more diversity and options. Unless you want to target mobile or consoles.

The JVM on mobile and consoles

Fact: there are no “real” JVMs on iOS, Android or Windows Phone 8. However, there are alternatives.

I’m not interested in politics, so i won’t get into the whole Oracle/Google issue here. Android is not sporting a JVM, but Dalvik. Dalvik only speaks register-based Dalvik byte code, which is usually procuded by running JVM bytecode through a converter. A forked and modified version of Harmony serves as the runtime library. In its infancy, Dalvik was merely an interpreter, with a horrible GC. Starting with Android 2.3, Dalvik’s been beefed up with a tracing-JIT and a concurrent GC. It’s sufficient for games, but there’s still a lot of room for improvements.

On iOS there’re currently a couple of “solutions”. Avian VM by Joel Dice is an amazing little piece of C++, that can ahead of time compile Java bytecode to x86 and ARM, compatible with iOS ABI. It can use its own minimal runtime library implementation, but also supports OpenJDK’s class library, and recently also Android’s fork of Harmony on some platforms. Avian has additional features you don’t find in Oracle’s JVM, namely tail calls and continuations (something Mono also supports). Avian’s AOT is actually based on its JIT compiler. Put simply, for AOT compilation, it JIT compiles all the code, writes a memory image to an object file, which can then be statically linked to an executable. Avian’s GC is also pretty capable. What Avian lacks is an optimized JIT stage (they recently added VFP support for ARM) and debugging facilities. It’s also unclear how stable it is. If you run into issues, you usually get a nice segfault, and its not exactly simple for plain old Java folks to debug such a case. Joel is extremely active on Avian’s mailing list though, and ususally fixes any issues rather quickly.

Another option for iOS is RoboVM by Niklas Therning of Trillian. It’s another AOT implementation that leverages LLVM. It translates Java bytecode to LLVM IR, which can then be compiled to its final machine dependent form, either x86 (Linux, Mac, iOS simulator) or ARM (iOS device). RoboVM uses Android’s Harmony fork as its class library. RoboVM is still in its infancy, and needs a bit of work before it can be used in production. It uses the conservative Boehm GC, which is not exactly known for its performance. Mono has been using that for quite a while as well, and i think the Mono fork of Unity just recently switched to sGen. Things like virtual calls need optimization. Never the less, its a promising project, and especially the use of LLVM makes me all gigidy inside.

Yet another option on iOS is called XMLVM, you should go watch the Google Tech Talk on it. XMLVM takes insanity to an entirely new level, by using XML for representing a register based IR that’s constructed from Java bytecode, and then applying XSLT to convert it to a target language like Objective-C or more recently C. It also uses the Boehm GC, and last time i checked, i think they used Harmony as its runtime library. It’s the only option i didn’t take a closer look at. Kev Glass of Slick2D fame used and contributed to it a while ago, but eventually gave up on it.

Google put forward a solution for iOS called J2Objc. I elaborated on that quite a bit in this blog post. It’s a Java source code to ObjectiveC converter, with more limitations than you can shake a stick at. It may be an interesting approach for bootstrapping conversion of your business logic and domain objects to ObjectiveC, but it’s definitely not gonna help you in running a full Java app on iOS. I’m also not a big fan of source code translators. It seems Google has a bit of a love affair with such tools, see GWT.

Oracle recently announced ADF for mobile, which should cover Android and iOS. Sadly, that effort consists of HTML5 for the presentation layer, and a trimmed down interpeter JVM for simple business logic. It’s not a full-fledged JVM, and it’s pretty much out of the question that its two components can run any game more complex than Pong (i exagerate of course). There was some recent news from the JavaFX camp that Oracle may have something going on beside ADF for mobile. Sadly, that hope was crushed by an update to the blog post, which stated that Oracle is currently not working on a JVM for these platforms.

Finally, there’s IKVM-monotouch by Michael Bayne of PlayN and Three Rings fame. He went through tremendous pains porting the original IKVM to the MonoTouch (now Xamarin.iOS) toolchain for iOS. This solution translates Java bytecode to CLR byte code, which then gets compiled to a single x86/ARM executable that works with iOS. This works surprisingly well, and is the solution we chose for libgdx (we contributed a tiny bit, JNI capabilities mostly). Everything from profiling to debugging works in this solution. It also allows you to directly write against the iOS APIs from within Java, so you can integrate things like Game Center or ads. You can also talk to C# code if you need to. The only downsides are suboptimal JNI call performance, and some missing classes in the runtime library, namely all of the networking stuff (fear not, we have an API for that in ligbdx) and locale related things. Xamarin has been very kind to us and supported this effort with a few licenses for core developers. They where also very reactive to any issues we encountered along the way, even taking their time to respond here and on Twitter. In that regard, it almost hurts me to say, that eventually we’d like to get away from this solution.

Out of all these options, none helps us to target consoles or Windows Phone 8 (but who wants to do that?). A case could be made for Avian as a potential option for some consoles, but that would need quite a bit of work.

Final Verdict

The JVM is a viable game development option should you want to target the desktop, and relevant app stores like Steam or Desura. It won’t work for the Windows 8 store, which has yet to demonstrate that its a profitable market. You can also target the Mac OS X app store, provided you bundle a JRE, just to be save.

On the browser, there’s really only GWT. PlayN and libgdx both let you target that if you want, with an additional restriction for libgdx, which requires WebGL.

On mobile, you can go full Android, just keep in mind that you are working on Dalvik, not HotSpot. On iOS, there are a few workable solutions, but they all come with their drawbacks. Libgdx covers you there with the IKVM/Mono based backend, but that comes at the cost of 299$ per Xamarin.iOS license (or 79$ if you are a student). Xamarin offers quite a bit for that price tag though, so consider it. Note that using MonoGame will not save you from that license cost, as much as they hate talking about that. Read the fineprint.

On consoles there is no JVM, period (unless you count the Ouya as a console, but that’s really just Android with lip stick).

What does it mean for libgdx?

So far, we’ve always found a way to spread to new platforms. I’d also say that our current solutions are suprisingly robust and mature, and looking ahead, say 5 years from now, we’d still be in good shape with the platforms we are supporting at the moment. Unless FirefoxOS or Windows Phone 8 take off. I let you guesstimate the probability of that happening. I will continue working on libgdx regardless, i enjoy the community we build, i love the people i meet and have the privilege to work with, and i like the challenges we face due to clinging to our toolset of choice. That may be crazy, but hey, it’se me.


I’d love to see Oracle realize that there’s an oportunity there. It’s hard to tell what their strategy is. One day JavaFX and with it a JVM for mobile seem to be about to be released. The next day an interpreter JVM plus PhoneGap are presented as the final solution. And then you stumble across this JEP and don’t know what to think. Could this indicate an AOT solution? Or a less useful Zero based solution?

I still believe that the JVM could be a strong player in the mobile domain, for both apps and games. The community that build around the JVM would go to great lengths to guarantee that with both open-source and commercial contributions.

Nate and I talked about all of this for quite a bit. We actually assembled a large portion of the Java gaming community, including folks from LWJGL, Jogamp, jMonkeyEngine, as well as figures like Caspian Prince and Michael Bayne. We had some intense discussions on a mailing list we setup, on what could be done about the current state.

Whatever the result, we can always move forward, with or without support from the JVM’s stewards. It seems to be in the DNA of our community πŸ™‚

I’d love to hear your thoughts on this matter. Leave links or feedback in the comments below.

40 thoughts on “The JVM – a viable platform for (mobile) games?

  1. You got me scared for a second, big wall of text with the words JVM and viable in the title! πŸ™‚

    Good to know you guys choose to continue with the current toolset.

    Your letter to Oracle was a smart move, one can only hope they start looking closer to our community. Arguments like yours will surely have at least a bit of an impact. But I don’t know… can’t figure out Oracle’s strategy for Java either…

    Thanks for your excellent insight on this matter.

  2. That’s how i make people read this wall of text πŸ˜€

    Thanks for making it through it and for providing feedback.

  3. I’m glad to see you’re enjoying your week off πŸ˜‰

    I guess that’s just looking at tradeoffs- if you could only create a “Mario 1” type game, stressing out most phones with JVM, but create crysis 3 quality graphics programming completely using binary… I’d still stick with ‘Mario 1’ type graphics πŸ˜‰

    But what are the alternatives? Anything that’s unbelievably fast compared to using JVM, that would be comparable in terms of being able to deploy to multiple platforms quickly? It’s interesting that C# is even a player in cross platform development languages, being developed by Microsoft….

  4. Awesome article, Mario.

    Now, my two cents.

    I think that the JVM and its derivatives (dalvik) are here to stay, in the spotlight, for a long time.
    The jvm is an amazing piece of software that federates a huge community and an insane amount of tooling/libraries.

    Java in the spotlight ? I’m not so sure.
    The language feels dated (compared to Ruby, or even C#) and the slow and opaque pace of updates (I’m looking at you JCP and Oracle) got everyone bored or – worst – worried.

    There is a real expectation about a strongly typed modern efficient JVM languague : Xtend, Ceylan, Kotlin, Mirah/Duby…

    As soon as one of these newcomer will gain traction (and tooling support) I won’t be surprised to see the small/medium shops leaving java in droves.
    (and will win over all the rubysts tired of writing unit tests to enforce type safety. And introduce them to refactoring tools πŸ™‚ )

    Sun missed a lot of opportunities with java (mobility, desktop and web – applets are a failure).
    And Oracle is no better, I’m afraid.

    As far as Apple is concerned, I feel that we are very near (one year away) to see a first class iOs solution for jvm language.
    Many projects are tackling this goal.
    I wouldn’t be surprised to see a crowfunding effort to help one of those projects to really take off.
    There might be an opportunity to start a xamarin company clone but for java (jamarin? πŸ™‚ )

    To sum up, I feel that your investment in the jvm is a sound one.
    And that libgdx is getting on something bigger here : a company, a consulting firm ?

    Unless …
    Unless appmachine (1) is the future and kills development as we know it πŸ™‚


  5. Interesting read and nice to see you thinking about the future Mario.

    I know you did a lot of testing on unity but have you tried shiva 3d? It has most if not all the benefits of unity, the community is smaller but the apis are easier to work with and there are some really good documentation. One of the main draw is the fact that write one code and publish to a gazillion platforms, well not really but pretty much all major platforms but personally the biggest draw is the price.

    Right now the store is down but the usual 400 dollars you can publish to those gazillion platforms, no yearly fees. I’d like to get your thoughts on shiva 3d.

  6. The Haxe/NME framework is also growing more competitive these days. Haxe 3 entered its release candidate stages recently – a big milestone release with a lot of additions. NME is also starting to grow beyond the Flash API emulation that it began as, into a more well-rounded gamedev platform.

    However, it’s a language-centric approach, not a VM-centric approach. I think there are benefits and downsides to both, and JVM’s maturity isn’t to be undersold.

  7. Honestly, I did a whole game with the Corona trial (so no support whatsoever) without much effort, and it’s so easy to use I actually use it for prototyping sometimes. There are lots of code examples and one way or another you will find an example of what you want (unless it is highly specific)

    On the other hand, even though your code is well documented, there is an extreme lack of examples on how to do stuff on libgdx. I very much feel the same way I felt when I tried Marmalade SDK, which is kind of lost.

    And don’t get me wrong, libgdx is clearly powerful, lots of games prove it, but the learning curve is extremely steep. AndEngine had almost no code documentation but had an example repository with pretty much everything you will ever need for a simple game, no trial and error was needed.

  8. Iam really proud that guys like you exist. All those major companies should definatelly take a look at your effords and maybe realize that in the end it would be nice to screw all the politics shit and work together for a unified-better-for-all-solution. I think everyone will benefit from it including google/apple/oracle/microsoft etc

  9. My problem with the JVM as a game development application is lack of memory control. GC is a problem that can be somewhat surmounted, but we do that with hacks by having mutable objects and all that. It would be nice to do things more elegantly.

    And I hate the Dalvik memory limitations. Only having 16MB of Java heap is silly for games, and I am not sure why Google doesn’t allow applications to install with permissions that allow them to grab a much bigger chunk of memory. So you end up having to implement a bunch of stuff in native code to get around that, which means cross-platform is a fantasy for any application doing anything relatively interesting. Which equals most games.

  10. Ah if only Oracle would open their eyes… Well JVM has its problems, but I think that it is a viable solution going to the future.

    I don’t think Java or JVM is going anywhere soon, so LibGDX can continue its endeavour safely. You guys have contributed a lot to this gaming community, and the fact that we can use it at no cost is incredible (and respectable).

    So I have to say: Thank you and keep it up! πŸ™‚

  11. Actually Flash SHOULD be the platform of choice for this currently, but there are too many sheepish and stubborn so-called “developers” out there with an irrational fear of anything plugin or Flash associated.

    The usual response to such a suggestion (which I’m sure is why many feel the fully JIT VM platform is “dying”) is to boo, hiss, and throw your poop at the offending code monkey.

  12. I should say, JVM/Java is in the same boat as Flash (whether rational non-Apple worshiping developers like it or not), for many of the same reasons. I’ve thought about and researched this topic quite a bit over the years (beyond just mobile), but unfortunately since too many bought into the HTML5 hype too early. I don’t think any obvious choice will be emerging anytime soon.

    HTML5 spec, estimated to be complete around 2022(?) or so, and it’s yet to be seen whether all these browser/mobile devs can implement it consistently enough for it to solve the standardization problems without some kind of software VM (Flash/Java) solution (like they’re doing with vmware). After over a decade of such failed standards promises, I’m still skeptical.

  13. Great summary of the state of JVMs for (mobile) game development. I’d love to see the ahead-of-time (AOT) compile efforts get more attention. Most (mobile) games don’t really need run-time compilation of a JIT (they tend not to add code at runtime), and the “run anywhere” problem is generally addressed by having multiple builds of your app (witness all the native C/C++ games available on all the targeted platforms). That said, AOT has never been a first-class project, and has never really caught up with “complete Java” since its such a moving and growing target.

    It seems like Libgdx which is already something of a “least common denominator” of many different environments (Android, Desktop, GWT) that hides and simplifies (or outright ignores) many Java APIs might be a really useful target for some of these AOT projects.

    All that said, the real benefit of Libgdx for me has been the ability to rapidly develop for Android on my desktop! (And that’s sufficient!) All the new backends and experiments have been huge, huge bonuses on top of an already useful project.

  14. I can guarantee WP8 will take over. You know why? Because Windows has the authority when it comes to supporting zillions of companies. Microsoft lives because of those companies. And soon a tablet/iPad/Surface will replace the laptops. Who do you think the companies will go for? A tablet or a Surface? Of course a Surface because their machines run on Windows. They trust Windows. So they will trust Surface. This trust is inevitable. Then boom! WP8 is the friendly guy. We all like the friendly familiar guy.

    Mario – this is an amazing write. Thank you.

  15. @Zairon – but there is such option from what I remember. It’s called big stack or sth like that. OUYA guys wrote about it, gives you more than 300MB.

  16. First thing is when I started looking at engines Unity I came across first and then AndEngine and PlayN etc, and LIBGDX I found rather late on.

    I have looked in detail at engines and really only found two that are good for me which are LIBGDX for android and MonkeyCoder for IOS although with the RoboVM backend I may stick to LIBGDX only if that option is free or nearly free.

    Unity was too expensive for the no splash screen option for me and I like to code stuff rather than use an interface.

    Keep on the good work on it please.

  17. That is a great blog post with a lot of insight from a guy who knows his trade. As they say “no good deed goes unpunished” but I do think that by giving libgdx to the world many many aspiring game developers managed to actually start their own projects which they wouldn’t had have and some’s career and life got change for the better.

    As with everything that requires labour and time, game development is getting commoditized. If one is really into performance and works on triple AAA games, then of course will go native and use one of those monster engines like unreal or roll their own. It’s not done overnight mind you.

    Unity brought game development or better said game making to non developers and no game made with unity is that cutting edge that can’t run on a VM because it loses performance.

    Libgdx made game development accesible to programmers who wanted to make games (like me) and didn’t have time. The effort and understanding that went into the whole research for this post to clarify these things is something that most people who make games are not capable of. The contribution to a JVM, to overcome serious android limitations and to give it away for free is really something amazing. This is why the tooling in the java ecosystem is so great, because people contribute and share. It’s open an offers challenges. It challenges people to improve things and I see innovation comes from the outside rather than from the holding companies.

    Libgdx helped me in many ways to understand how powerful the JVM is actually. Every feature I use, I go through its source code first. It’s a great manual as it is a great tool.
    And no-one is required to pay 2k $ to get rid of the splash screen and to use shaders.

    Thank you again and your effort is much appreciated.

  18. +1 for all the support Mario. I just want you to know as a loyal Java/JVM user myself, I’ve come to the exact same conclusions as you have. It’s not perfect, but the platform is the best for a variety of factors, portability, productivity and performance being only part of the amazing benefits. Thank you a million times over for putting so much into it.

    I know sometimes it’s frustrating going to some marginally technical just to see people spam the internalframe meme anytime someone mentions Java, but you should know there are a ton of devs who think just like you and are very glad they’re working with Java/JVM with libgdx.

  19. I used libGDX very briefly for my first Android game. I found it to be a really great API with a nice clean design. I still recommend it to people who prefer Java.

    I’m not really a Java programmer though, so I went the MonoGame route. I’m a much faster developer with C# and there are many things I prefer over Java. However, I do miss some things about libGDX, like WebGL support and the ability to have 99% of code in one project (MonoGame does this a bit differently, it works, but it’s more cumbersome).

    In terms of performance, I think you’ll find Mono to be just as good most platforms. Although, I don’t really want to argue about that because it often doesn’t matter. Most indie games will run just fine on either.

    It’s an interesting mult-platform world we live in these days and our options are growing thanks to these fine projects. I’ll continue to follow libGDX as a C# developer.

  20. There are quite a few Flash developers who are out looking for answers to these questions as well. We recognize that Adobe is stepping back more and more from the platform, but we don’t feel like there is yet an adequate solution to replace what we’ve had in Flash and AIR. Adobe essentially never came around to trying to monetize the platform (beyond selling tools, which weren’t required), and now, miraculously, find it isn’t making them enough money.

    We’re looking at solutions like Xamarin, MonoGame, Cocos2d-x and libGDX. They all offer things we don’t have with AIR, but thus far we’re missing the overall complete solution, from the platform support to the ability to handle both game and general application development, with good design and coding tools available for both. I think many of us are hoping against hope that Haxe gets established and grows, but for those of us needing to build our skills for the job market now that Flash has faded, it’s not really a smart bet. I’m currently reading your book on Android game development with the intention of getting into libGDX afterwards. From what I’ve seen, it’s about as close as anything to what we’ve had. It’s a game right now, watching the trends and trying to pick a winner to get involved with. I certainly appreciate your work.

  21. @aaa Yeah, I have tried the large_heap option in the Android manifest, but at least from my experiments it appears to be up to the discretion of the OS to do anything about it. I believe it is basically limited to Android tablets or devices like Ouya. Kind of a bummer if you wanted to do something graphically low-fi but memory and CPU intensive (think Dwarf Fortress) on a phone. Hopefully I am doing something wrong and I can get at that memory!

  22. What about LuaJIT with some C/C++-Wrappers for libraries instead? Its performance is better than V8…

  23. LuaJIT doesn’t work on iOS, at least not the code generator. What you get there is interpreted Lua, though LuaJIT’s interpreter is one of the fastest things i’ve ever seen.

  24. I want to echo what IKIGames stated in their blog: It’s libgdx that’s fantastic, but there are no strong reasons for me to particularly prefer Java as my language of choice as a game developer (and several not to). I think tying libgdx to Java would be selling it short; what you’ve chosen to implemented libgdx in is not really interesting to me as a game developer except as a detail.

    Can you imagine there being nice libgdx bindings for Xamarin in their new Component Store, similar to how there’s already adMob and Google Analytics and other libraries? I would switch my future games to C# in a heartbeat, and use libgdx for the presentation layer exactly as before (texture atlases, sprite batches, input, sound, scene2d, etc.) So the libgdx library is IKVM converted to CLR bytecode before put to the Xamarin Component Store? Who cares.

  25. Great post. I also would love to see more support from Oracle in targeting browser and mobile platforms with a single code base, before it’s too late.
    The libgdx story is very compelling for desktop/mobile apps, but to make a multimedia app that should also run in a browser without WebGL, I’m contemplating Three.js or LycheeJS ( The latter project is a new and serious contender in the multiplatform (desktop+mobile+browser), single code base, open source game library. There’s also an ADK (App Development Kit) which “uses a custom V8 based JIT runtime that gives JavaScript the power of using OpenGL, GLU, GLUT and WebGL directly with custom data types, Polyfills for required loading mechanisms and many more features.”
    So I’m looking at 3 paths forward:
    1. libgdx (destop/mobile/webgl browser) + three.js (browser)
    2. libgdx (destop/mobile/webgl browser) + lycheejs (browser)
    3. lycheejs for all targets
    Which one is the best I’m not sure yet, I’ll have to experiment a bit. I’ll may go for 1 or 2, and decide upon lycheejs later, as it’s still in development. But since I’m biased towards using Clojure+ClojureScript, I’d rather use an entity-component-system rather than an object based scenegraph, in which case lycheejs and Artemis look more appropriate. So maybe I’ll just do 2 and see how it goes…

  26. While I use and really like libgdx to write games; I have to say .NET has taken over in almost every aspects of byte code languages.

    C# is better, constantly updated, the .NET runtime has incredible performance and works really well with native code with marshalling/unsafe methods. It has also access to lower level stuff that are great for games (structs, unions, direct access to pointers, “by ref” modifier, more control over the GC, you name it).

    The JVM might be viable but is 5 years behind .NET.

  27. Great work, it means so much and you’ve helped people in ways you most likely don’t even realize.

  28. The JVM may be viable, but there are a lot that needs to be done. If the community are ready to do it then we have a chance, but just waiting for Oracle to solve it… it may happen but most likely not.

    Problems with using JVM:
    1. Lack of support for exotic platforms, including consoles and Android. Some platform can not be supported due to their proprietary status, this include but are not limited to iOS (unless its rooted). However Android should be supported and porting OpenJDK to Android should not be that difficult.

    2. Browser integration/plugin. I actually use Java Applet technology a lot, but it have a lot of disadvantages. The icedtea plugin are quite buggy, and the official plugin have had a lot of security issues. There are the “applet2” aka JNLP technology, that does not work much better. Neither of these have good support for Chrome. The community really have to step in and do something here, icedtea are the point to start. Icedtea should be a priority project, and it should also be able to use Java SE and other non-OpenJDK packaging of the JRE.

    3. Third party extensibility. There have to be a way to drop jar:s in lib/ext and make them work with the browser plugin. JNLP can do stuff like load JOGL but that requires per application security privileges and trough user interaction. The Icedtea plugin should be able to load JAR:s signed by third parties, as long as their certificate are installed in the right place, or they are white-listed in some other way.

    4. Bindings. JNI are a real pain in the ass. GlueGen are a nice tool but its far from perfect. I do not see the need for a Java-only binding tool. I would rather see something that allows generic bindings to be translated into Java, python, ruby etc binding. The reason for this is that such a tool would have more quantity and quality in its binding as it removes redundancy in these projects. There are 16 projects that creates Qt bindings and about 40 projects that are implementing OpenGL bindings for many different languages. There should be one project of each. Being a former Windows developer I do remember the value of COM and how OLE/ActiveX created bindings that where usable in most languages. There where never any problems in finding bindings for whatever native library you wanted to use, as long as your language supported COM.

    5. Bindings. While there are bindings for OpenGL the bindings for Qt where dropped and many other useful libraries have no bindings to Java.

    6. Stable 3D and multimedia API:s. It does not matter if such API:s are shipped with the official Java or if they are installable extensions to put in the lib/ext folder. What matters is that they MUST be usable from APPLETS or otherwise the entire web spectrum is lost. JOGL is nice, but it cant be used in Applets – and no JNLP which have to bee authorized by the user is not an option. Also JOGL can not be exposed by dropping it into lib/ext, it is to low level and gives us several security concerns.

    Some may think that no 6 is the most important issue to solve, however it is dependent on all the above. Naturally there need to be a JVM for the platform to run at all. In order to expose itself to the web, it needs a sufficient Applet status. Unless it is included in Java, it needs third party extensibility so that it can install itself in lib/ext and be used by Java Applets without JNLP or any other ugliness. As it will depend on C++ code/libraries it needs a well-designed solution for bindings.

    It should be noted that JavaFX 3D is upcoming. However JavaFX cannot as far as I know be used in an Applet but requires JNLP. Also it have the same struggling with bindings that other projects have, which is likely a mayor reason for the slow progress for the JavaFX development. With a rich set of community-created bindings the process of creating JavaFX or something like it would likely be much shorter.

  29. Oh my, that got totally lost. Does this require AOT? Would be awesome to target Windows Phone 8 πŸ™‚

  30. This is the stupidest thing I have ever read… Microsoft supporting companies? nope. They buy them, and destroy them.

  31. I doubt anyone is going to sink their dev career on your “guarantee”. Broad assumptions and fanboy predictions don’t disseminate anything other than your own personal utopian fiction.

Leave a Reply

Your email address will not be published.