libGDX 1.0
Everyone thought the day would never come. But here it is. libGDX 1.0 is officially released! Let me quickly run you through the most important changes:
We have a new Gradle-based project setup! Say it after me: no more binary downloads! No more jars in your repo! Simple packaging for all platforms! Simple updates of libgdx and other library versions!
All new docs in form of videos and Wiki articles. Each video has a reference to more videos at the end, make sure to watch them all!
We removed OpenGL ES 1.x support and added OpenGL ES 3.0 support
We removed a lot of clutter from the Android backend, and upped the minimally required version to Android 2.2
Box2D has been moved to an extension
A metric ton of improvements for Scene2D, like the viewport enhancement
Out-of-the-box support for Intel® x86 Android devices. As an Intel® Software Partner, the core team worked to get libGDX optimized on Intel’s latest platform while having access to Intel’s technical and marketing support centers.
Read the full CHANGES file for more goodies.
To try out our new setup, start here!
If you have a Gradle-based project, make sure to update the gdxVersion to “1.0.0″ and refresh your IDE project files! The new snapshot (==nightly) version is “1.0.1-SNAPSHOT”
Besides the usual bug fixing and enhancements, we also cleaned up our libGDX repo, website and wiki for the 1.0 release. The old setup UI has been deprecated, the audio and image extensions have been removed, and the demos have been gradelized and put into their own repositories. You can now also directly test the demos in your browser (or desktop, or Android device)!
Finally, we’ve setup a Patreon, that allows users to contribute to our infrastructure costs. This has been so successful, that we were able to move our build and website server to Hetzner. After the move and adding some build magic, the build now takes 10 minutes instead of 1 hour and 45 minutes. Thanks to all the patrons, you really made a difference in my life!
Going forward, we’ll try to have a much shorter release cycle (2 weeks – 1 month). The major version of libGDX will stay at 1 for the foreseeable future. The minor version will be increased when API breaking changes are introduced. The patch version will be increased in case of bug fixes and API additions. Releasing often allows you to stay as up-to-date as possible before freezing your libGDX version for a release.
What’s next? Consoles may be interesting. The 3D API needs to be benchmarked and optimized. More docs and tutorials need to be written. An In-App purchase extension would be useful. There’s many directions we can take libGDX. And you can be part of this!
I’d like to close this release post telling you how we came to this point and how it impacted my personal life.
A brief history of libGDX
I’ve been working on libGDX for a little over 4 years now. It’s been opening doors in my life i didn’t expect. It’s responsible for many of the best moments in my life. It allowed me to work with and learn from extremely smart people, some of which eventually became like family to me. libGDX began as a personal journey and became a movement. For that i’m grateful, so thanks to all of you out there that helped and help make it happen.
In the beginning – 2009
It all began with me wanting to write games for Android in mid 2009. That’s when the first Android phones hit the market. I got myself a HTC Hero, shortly followed by a Droid, which i loved to death. Naturally, i got them to write games for them. In my childhood i wanted to write games for my GameBoy. This was the closest i could get.
I started working my way through the early Android SDKs (1.x), get myself accustomed to OpenGL ES (i had a desktop OpenGL and DirectX 9 background) and started writing the first tiny demos and a framework called AFX (Android Effects). Deploying to Android on every change turned out to be a miserable experience (still is). So i modified AFX to work on both the desktop and Android. This eventually became what you now know as libGDX. I did a lot of different prototypes of games with AFX, from Super Monkey Ball clones (using a Bullet JNI wrapper), to a racing game and a lemmings kinda thing. I eventually settled on cloning and extending Gravity Pods in the form of Newton. Stef helped with level design, and the game even allowed users to create their own levels and share them (a first on Android?).
This all happened in 2009, Newton got published in December 2009. Along the way, i encountered a metric ton of issues in Android, one of my all-time favorites being the broken multi-touch support and the broken NIO libs in Harmony. I was an early adopted and posted regular updates talking about my findings and experiment (like early Bullet on Android, or MD2 rendering). This lead to my blog becoming pretty popular comparatively, there just wasn’t much like it on the web.
In early 2010 i started working on audio processing on Android. I wanted to create a music game on Android, where players could use their own music from which game content would be generated. That culminated in a huge tutorial series on onset detection. I eventually got contacted by Dylan, creator of the awesome Audiosurf. I did an evaluation of whether we could port Audiosurf to Android, based on the Zune version. It was written in C# with XNA, curiously GLSL was used as a shading language. I took my onset detection code (which i had ported to C++) and AFX and got to work. The hardware back then couldn’t really deal with all the things that went on in Audiosurf, especially the massive amount of full-screen blended quads. Due to this, and me being generally overworked, we eventually agreed to give up on this experiment. Audiosurf is still not ported to Android.
In March 2010 all that died down, and i found a bit more time to procrastinate. I decided to open-source my AFX framework, thinking i’d be super useful for others as well. This was additionally fueled by Google sending my a free Nexus One out of the blue!
Going OSS – 2010
On the 6th of March 2010, the world saw the first libGDX code. As you can see, that already looked very familiar: simple starter classes per platform, meaty code in a separate project shared across all platforms, simple interfaces for graphics, audio and input and file i/o, implemented for each platform. That’s the core principle of libGDX, and it works like this to this day.
Soon after, the first libGDX tutorial was published on my blog. I was surprised by the amount of comments that blog post received, so i kept publishing more and more tutorials. libGDX’s source was hosted on Google Code, which should become libGDX’s beloved home for years to come. The first few weeks were pretty frantic: the SVN repository was restructured time and time again to find an organization that’s good enough. New features arrived with high frequency. I wrote JNI bindings for OpenGL ES 2.0 for Android, cause the Android version was broken. I even rewrote all of libGDX so users can transparently use OpenGL ES 1.x and 2.0, a feature many of our users learned to appreciate over the years. And all of this happened in March. I have no idea how i found the time to do all this.
In early April 2010, libGDX got its first contributor, Christoph Widulle. He helped with various bits and pieces and was a nice wall to bounce ideas against. Christoph went on to write a little engine on top of libGDX, similar to AndEngine which entered the scene around that time. Eventually, Christoph disappeared. His involvement was a sign to other people that contributing to libGDX is a thing. The list of contributors to libGDX started to grow slowly but steadily. Using SVN on Google Code didn’t help: contributing code or wiki articles was rather clunky and required me to manually add contributors to the project.
In May 2010, the first big addition to libGDX happened: a manually generated Box2D JNI wrapper. This opened a lot of doors for libGDX users, as physics based games were on the rise. The Box2D wrapper attracted many new contributors like Moritz Post, who in turn started adding features and fixes. With more users and contributors, our device test coverage started getting really good. This allowed us to iron out pretty much all of the Android issues other game developers would encounter in the following years very early on, making libGDX a highly robust game development library for Android.
The rest of 2010 was spent on fighting the mythical Android fragmentation, opening up our forums, changing our license to Apache 2, bragging about performance, taking a break, writing a book, diving into assembler, seeing the first libGDX game released, adding nightly builds, and getting Nate on board. Nate contributed so much over time, that he’s now sharing the copyright with me.
We learned a lot in 2010. The project’s scale grew quite a bit, especially with the influx of new contributors and users. As such, we had to learn how to deal with API changes, how to react to and manage issues and how to nurse a community. Some of these experiences where rather painful, others where quite humorous. We welcomed new folk into our family, such as Dave, Obli, Tony, Eric, … just to many to name.
We almost released 0.9 at the end of the year. Yes, libGDX was already at 0.9 3 years ago. It’s kind of a running joke in the core team 
Incremental Improvements – 2011
In early 2011 we started working frantically on the 0.9 release. We replaced our desktop audio backend with OpenAL, much to everyone’s delight. We implemented our own cross-platform 2D bitmap manipulation library in C, added better camera classes, improved on scene2D, fought more Android woes, and finally released 0.9 at the end of February 2011. The period between January and March felt like a marathon at sprint speed. So many internal changes happened to libGDX, it was hard keeping track of what’s going on. But it paid off. libGDX 0.9 saw immense adoption, not only due to feature density, but also due to us starting to create video tutorials and making the setup process a lot easier.
People started doing more impressive things with libGDX, like Stefan Wagner, alias bompo, who wrote a couple of nice 3D demos. More and more games popped up that used libGDX as their basis, so many, that we opened up a showcase subforum and periodically showed off some of them on the blog.
While people were busy creating games and making actual money, i was busy designing and implementing our first 3D API attempt, including things like vertex skinning, a nice material system, and so on. Nate was working on scene2D and many of the utility classes for XML & JSON parsing. New contributors joined, like Eric and Tamas. In fact, we eventually stopped doing the intros on the blog because to many people started contributing.
libGDX was doing great, the community was growing, and the first libGDX games became hits on the Android store. Apparatus went on to sell over 500k units, something that’s not been achieved by many paid-for Android games. We also got our first libGDX logo and OEMs like NVIDIA took note.
For me, spring 2011 was a bit insane. I spent all my free time in equal parts on libGDX and the book, which i completed at the end of February as well (at 700 pages none the less…). I also started getting invitations to hold workshops and talks. My first ever workshop was in March 2011 at Droidcon. To add to the insanity, i formulated the first libGDX 1.0 roadmap. We all know how that went. In April i started burning out. I needed to put my mind on other things, so i started writing silly little music toys. The book was finally published. I also participated in my first Ludum Dare.
And then the book climbed the charts on Amazon. I discovered this during a break at work and something hit me. I was filled with joy, and it was as if a huge weight was lifted from my shoulders. Working on the book and libGDX at full speed for over 8 months had taken its toll. I needed a break.
Nate and the others soldiered on, but the 3D API stalled as i was responsible for it. I tried to actually create a 3D game together with Shiu (Soren Nielsen), who’s the artist behind Spine. During that time, people like Stefan Bachmann of Robotality fame, Gemserk (Ruben & Arielsan, now at Ironhide Studios) or Przemek Müller joined the libGDX effort.
2011 became the year of incremental improvements, such as adding a UI library on top of scene2D, adding more desktop related features, adapting to new form factors like tablets, refactoring and rewrites, updating Box2D and so on. Many of these new additions and changes were motivated our work for a San Francisco based game development startup, Nate, Tamas and I joined in August 2011. It helped us identify pain points in the API in real-world scenarios, much to the benefit of the overall quality of libGDX. It was interesting getting paid to work on libGDX, but ultimately all three of us decided that we’d be happier doing our own thing.
We released libGDX 0.9.2 in September 2011, and then went essentially silent for the next 3 months. Development of libGDX continued at the same speed as before, we just didn’t have time to blog about.
I quit the job in December 2011 and went on vacation for the first 3 months of 2012. Apparently i was so bored, i decided to create a new “improved” build system for libGDX.
New Worlds – 2012
Sick of writing JNI bindings manually, i created an abomination called gdx-jnigen. I spare you the details. It became an integral part of our native code development, making it a lot easier to integrate C/C++ libraries with libGDX. I spent another month on working on my Android Reddit client, powered by libGDX, called Timesink, which i use till this day. This toy had to be very battery efficient and needed to deal with a lot of dynamic images. I never released the thing on the market, i like to keep it secret and personal.
gdx-jnigen made creating new extensions a lot easier, so i was able to add an extension for audio processing and an extension for FreeType in a matter of days. I quickly got bored with writing extensions.
The year before, Google was pushing their own cross-platform game development framework called PlayN. It was able to deploy to the desktop, Android and the web. The interesting bit about the web deployment was that it didn’t require an applet. Instead, the Java code was compiled to JavaScript via GWT. Google made quite a fuzz about PlayN for a while, with games like Angry Birds using it for their web ports.
I got inspired by this and thought i could do the same for libGDX. Problem was that libGDX had a much bigger surface area than PlayN and required some features that GWT doesn’t provide, like reflection or a synchronous file system emulation. I figured i have another month before i start at my old company, why not give it a try. I took me a weekend to get our WebGL/JS backend up and running, based on PlayN’s code. OF course, that weekend job turned into a multi-week rampage to get almost full feature parity with libGDX’s other backends. This work included a custom file system emulation, reflection support, porting large bits of the NIO classes over to GWT, a custom JBox2D port, and doing many, many nasty things via the GWT emulation mechanism. In the end we had a lot more code in our GWT backend than PlayN, simply because we needed to so many more features. To this day, i think the HTML backend is one of the coolest and scariest things we’ve ever done with libGDX. Which is a weird combination.
2012 was also the year we started improving our documentation more actively. We called out to our community to help us make things better.
In April we had another big release with libGDX 0.9.3 that included many of the new additions we made in Q1 2012. Aurelien Ribon, aka Obli, joined to team and helped out with creating one of the most vital pieces of software driving libGDX adoption: Gdx Setup UI. It was also around that time, that AppBrain reported that 1.24% of all Android apps where made with libGDX. That figure placed us way ahead of other engines/frameworks like Unity, AndEngine or Cocos2D-X. Unity has since overtaken us in that ranking, but only after they made mobile development free (unless you need Pro features. Like sockets, or FBOs…).
The next big change came in June, when we started investigating iOS, again based on work done in the PlayN camp. Google had abandoned PlayN at that point in time. Michael Bayne of Threerings/Sega took over pretty much all of PlayN and added iOS support. The way this worked was hackish and amazing. Michael made IKVM work with MonoTouch (C#/.NET for iOS). That allowed him to translate Java code to .NET byte code and ultimately to iOS native code. We leveraged Michael’s work and began working on our own MonoTouch based iOS backend. A few days later we had a working prototype backend. It would take the rest of the year to improve the backend and make it fit for production. This work was largely done by Arielsan and Ruben of Gemserk (who used libGDX to port the Ironhide Game Clash of Olympians) and Christoph from Noble Master Games.
Meanwhile, Nate went on a refactoring frenzy. He changed scene2D for the better, multiple times. He refactored our own TexturePacker to be even more awesome. Kalle picked up the 3D API were i left it. Bach added many nice little things like a PolygonSpriteBatch. And since many of the contributors were hanging out on IRC, so we thought why not invite everyone.
In August we decided we’d be brave enough to explore more new worlds. We started discussing moving to GitHub and adding proper Maven support. The move to GitHub would allow users to more easily contribute. The move to Maven would allow easier consumption of our library by developers of all colors (Eclipse, IDEA, NetBeans, CLI). Only one of these assumptions turned out to be true. The migration to GitHub went better than excepted, though not without some sacrifices. The move to GitHub was one of the best decisions we’ve made. We saw an immense rise in contributions (over 1300 pull requests to date, 200 contributors), our wiki can now be edited by users and we grew to be the 4th biggest Java project on GitHub, constantly trending. Only a handful of people on the core team could be called Git experts, so it took a while for us to adjust to the new workflow. Eventually we all started to like it, even Nate.
In October i was invited to speak at Apps World 2012 in London. Had a blast, did some book promo, and meet the batman. It was there that i met a metric ton of libGDX users that would come up to me personally and thank me for starting the project. I never met a person in real-life before that used libGDX, so this was very new to me (apart from the few folks back in San Francisco in 2011). One of the coolest stories was that by Richard Woods of exobyte. He’s was able to make a living off of writing games via libGDX in a specific niche, something i kinda dreamed of doing myself for a long time.
Around that time, Xoppa joined the team, rewriting the previously contributed Bullet physics JNI wrapper. He’s been a force every since then, rewriting the 3D API, fixing up math classes and doing other busy work.
At the end of 2012, the first libGDX games were published to the iOS store. We also released libGDX 0.9.7. We also finished mavenization of libGDX, with mixed results.
2012 was the year of discovering new worlds: HTML5/WebGL, iOS, GitHub and Maven. And even Google was using libGDX now.
Shaping Up – 2013
2013 started off with an interview for a book, where i shared my motivation and opinions on all things game engines and frameworks. We also went live with our Ouya support, which required us to write a gamepad and controllers library. Sadly, Ouya turned out to be a bit of a duck. We also had our first annual ski day and showed people that libGDX 0.9.8 which finally included all supported backends: desktop, web, Android and iOS via MonoTouch. Nate and Shiu went live with their Kickstarter for Spine, a 2D skeletal animation application, written with libGDX. They exceeded their goal by over 500%, and subsequently had another successful Kickstarter.
In the first half of 2013 we cleaned up many parts of libGDX, from the build system to tile map supported. Many of these cleanup efforts have been lead by Nex (aka MobiDevelop, aka Justin). Nex’s been like a mother to libGDX over the years. While we others run off breaking things, Nex makes sure we eventually fix our shit. He’s also the glue holding together our community on IRC, the forums and the issue tracker. That the HTML backend is still working is also just because of Nex. Nex would also have made an excellent mentor for our Google Summer of Code 2013 effort. Sadly, we didn’t make it in that year (and didn’t try this year).
The iOS backend based on MonoTouch turned out to be very fragile, despite Michael Bayne’s excellent efforts to keep up with Xamarin. Every new update by Xamarin broke the backend (which was not a fault of Xamarin, they’ve been excellent to us!). After contemplating our general choice of platform, we were surprised by Niklas Thernig of RoboVM. He simply wrote a libGDX RoboVM backend and contributed it to us. It would take another few months for the backend to stabilize and become part of the regular libGDX release.
In the meantime, Xoppa and Bach were slaving away on the new 3D API. We solved the dreaded 3D model format issue by taking code form GamePlay3D, heavily rewrite it and add new features, so that you can just use FBX, Collada or any other format supported by the Autodesk FBX SDK. The end-result is a nice, mid-level 3D rendering API with a functioning import pipeline that works pretty well across devices.
In May, a libGDX game won Ludum Dare, which made us quite proud! In June we went live with our new and improved website, created by a lot of awesome volunteers (thanks XKalibur and Bitowl!). With the new site, we made it possible for people to submit their games to a gallery. To date, over 800 games have been submitted. I also made an idiot out of myself by sending 300k emails through Github. But at least all our issue tracking and wiki stuff is now on Github as well.
At the end of 2013 we started looking into Gradle as our new savior. Up until that point, libgdx was bound to Eclipse and dependency management had to be done manually (copy jar X into folder y). We originally wanted to use Maven to solve this issue, but that turned out to be harder than expected. We gave Gradle a chance, and alas, it worked very well for us. With the move towards Gradle we also had to up our Maven game, publishing libGDX to Maven Central. This required many changes in the background, especially concerning the build and build server. All this work is not particularly sexy to do or talk about, but it makes the end user’s live a lot easier.
In Novemeber 2013 we released libGDX 0.9.9, including the new 3D API, the RoboVM backend as a default, Android x86 support, Gradle and Maven support, and a metric ton of bug fixes and enhancements.
2013 came to a close and libGDX was in its best shape ever. A nice dedicated website, stable platform support, mature APIs, a huge community of users and contributors, extremely active development and many ideas for the future. libGDX has finally reached a point were we believe it is mature enough for a 1.0 release.
Up Next – 2014
With all pieces in place, Q1 2014 was used to polish up libGDX’s user experience and documentation for the 1.0 release. We now support all JVM development environments (Eclipse, IDEA, Netbeans, CLI) through our Gradle-based builds. Our build server has been upgraded so we can push out new releases much more easily (and hence regularly!). Our repository has been cleaned up, any clutter has been removed. The Wiki has been updated to reflect the latest state of APIs and setup procedures. We are ready to pull the trigger. After 4 years of development, libGDX has finally reached version 1.0.
Thanks
4 years is a long time in computing. When i started this in 2010, i never imagined libGDX would become what it is today. Thanks to all folks on the core team, all contributors, all users. It’s been a fun ride so far. Here’s to 4 more years